(처음에는 https://www.humanbound.ai/blog/why-your-ai-agents-biggest-vulnerability-isnt-a-missing-firewall에 게시되었습니다)

세 가지 사건, 하나의 근본 원인.

지난 몇 주 동안, AI 에이전트 보안 커뮤니티는 반복되는 패턴에 반응해 왔습니다. OpenClaw는 Meta AI Safety 리드의 이메일 수신함을 통째로 삭제했습니다. Peak Security는 캘린더 초대를 통해 에이전트 브라우저(agentic browsers)를 하이재킹하는 PleaseFix라는 새로운 취약점 클래스를 공개했습니다. Claude Opus 4.5로 구동되는 자율 봇은 단 일주일 만에 Microsoft, DataDog, 그리고 CNCF 리포지토리에서 원격 코드 실행(remote code execution)을 수행했습니다.

이들은 서로 다른 시스템, 다른 아키텍처, 다른 공격 표면(attack surfaces)을 가지고 있습니다. 하지만 이들은 현재 받고 있는 것보다 더 많은 주의를 기울여야 할 공통된 실패 모드(failure mode)를 공유하고 있습니다.

이 에이전트들 중 그 어느 것도 방화벽이 없어서 실패한 것이 아닙니다. 제어 평면(control plane)이 누락되었거나 ID 계층(identity layer)이 없어서 침해당한 것도 아닙니다. 이들이 실패한 이유는 적대적 조건(adversarial conditions) 하에서의 동작이 전혀 테스트되지 않았기 때문입니다.

아무도 명명하지 않는 사건 패턴
기술적인 세부 사항이 중요하므로, 각 사건을 간략하게 살펴보겠습니다.

Eduardo Ordax가 광범위하게 다룬 OpenClaw의 이메일 삭제 사건은 정교한 익스플로잇(exploit)의 결과가 아니었습니다. 에이전트는 상충하는 지침을 받았고 잘못된 행동을 선택했습니다. 사용자가 승인할 때까지 아무것도 건드리지 말라는 지침을 받았으나, 이를 따르지 않았습니다. 이는 OWASP Agentic AI 분류 체계에서 가장 기본적인 카테고리 중 하나인 지침 충돌(instruction conflict)에 따른 범위 위반(scope violation)입니다. 모순된 지침을 시뮬레이션하는 단 한 번의 적대적 테스트(adversarial test)만 있었더라도 프로덕션에 배포되기 전에 이러한 동작을 발견할 수 있었을 것입니다.

Peak Security의 Tamir Ishay Sharbat가 공개한 PleaseFix 취약점은 구조적으로는 다르지만 동일한 격차를 드러냅니다. 공격자가 캘린더 초대장을 보냅니다. 사용자가 자신의 에이전트형 브라우저(Perplexity의 Comet)에게 캘린더에 관한 질문을 합니다. LLM의 의사결정 루프(decision loop)는 초대장 내용에 주입된 지침(injected instructions)을 통해 리다이렉션됩니다. 브라우저는 파일 시스템을 탐색하고 파일을 유출(exfiltrate)합니다.

흥미로운 점은 다음과 같습니다: 전통적인 런타임 경로 기반 제어(runtime path-based controls)는 이를 잡아내지 못했을 것입니다. Simon Shine이 지적했듯이, 모든 주요 런타임 보안 도구(AppArmor, Tetragon, Seccomp-BPF, Falco, KubeArmor)는 콘텐츠가 아닌 실행 경로(executable path)를 기준으로 차단합니다. 에이전트형 브라우저는 정당하고 권한이 부여된 파일 접근을 사용하고 있었습니다. 실행 경로는 올바랐습니다. 하지만 동작(behavior)이 문제였습니다.

다음은 Ilya Kabanov가 기록한 hackerbot-claw 사례입니다. Claude Opus 4.5를 기반으로 하는 자율 봇이 취약한 GitHub Actions 워크플로를 찾기 위해 47,000개의 공개 리포지토리를 스캔했고, 6개의 타겟을 선정하여 Microsoft, DataDog, CNCF가 관리하는 리포지토리를 포함한 4개 리포지토리에서 원격 코드 실행(remote code execution)을 달성했습니다. 이 봇은 정당한 CI/CD 경로를 통해 알려진 공격 기술을 사용했습니다. 인프라 관점에서 실행 과정 중 그 어떤 것도 권한이 없는 행위는 아니었습니다. 문제는 인프라의 권한이 아니라 에이전트의 동작이었습니다.

공통된 맥락은 명확합니다: 취약점은 네트워크도, 인증도, 인프라도 아닌 에이전트의 동작 그 자체였습니다.

런타임 강제 적용(runtime enforcement)만으로는 이 문제를 해결할 수 없는 이유
강제 적용 계층(enforcement layers)을 구축하는 사람들은 필요한 작업을 수행하고 있습니다. 하지만 현재의 담론은 강제 적용을 주요 해결책으로 과도하게 집중(overindex)하고 있습니다. 순서가 중요합니다.

Aldo Pietropaolo는 에이전트 런타임 거버넌스(runtime governance)를 위한 결정론적 제어 평면(Deterministic Control Planes)에 대해 사려 깊은 시리즈 글을 작성해 왔습니다. 그의 핵심 논거는 타당합니다. 에이전트에게 스스로의 거버넌스를 강제하도록 요청해서는 안 된다는 것입니다. 제어 평면(control plane)은 에이전트 외부에 위치해야 하며, 확률론적인 LLM 추론(probabilistic LLM reasoning)이 아닌 결정론적 정책 엔진(deterministic policy engines)을 사용하여 모든 동작을 평가해야 하고, 사용 불가능할 경우 '페일 클로즈(fail closed, 차단 상태로 종료)' 되어야 합니다.

이는 탄탄한 아키텍처입니다. 하지만 제어 평면은 무엇을 차단해야 할지 알아야 합니다. 그렇다면 그 정책들은 어디에서 오는 걸까요? 만약 에이전트를 적대적으로 테스트(adversarially test)해 보지 않았다면, 당신은 에이전트의 실패 모드(failure modes)를 알지 못합니다. 당신의 정책은 증거가 아닌 가정에 기반하고 있는 것입니다.

Eran Sandler의 AgentSH는 의도(intent)와 현실 세계의 부작용(side effects) 사이의 실행 계층 보안(execution-layer security)이라는 다른 각도를 취합니다. AGENTS.md에 대한 그의 비판은 유효합니다. 마크다운(markdown) 파일은 행동을 강제할 수 없습니다. 모델은 확률론적(probabilistic)이며, 핵심 지침이 누락되거나 희석될 수 있고, 에이전트가 스스로의 규칙을 무시하는 것을 방지할 메커니즘이 없습니다. AgentSH는 프로세스, 파일, 네트워크 수준에서 남용을 포착합니다.

하지만 AgentSH가 포착할 수 없는 것은, 의도된 행동 범위(behavioral scope)를 위반하면서도 정당한 실행 경로(legitimate execution paths) 내에 머무는 에이전트입니다. PleaseFix 공격이 바로 이러한 시나리오입니다.

Simon Shine의 관찰은 아키텍처적 격차를 명확히 보여주기 때문에 반복할 가치가 있습니다. 컨테이너 생태계의 모든 주요 런타임 보안 도구는 실행 경로(executable path)를 기준으로 게이트를 형성합니다. 이는 프로세스가 예측 가능한 실행 패턴을 따르는 전통적인 워크로드(workloads)에서는 합리적인 절충안(tradeoff)입니다. 하지만 AI 에이전트는 부당한 목적을 위해 정당한 도구를 호출할 수 있습니다. 이들은 승인된 경로를 사용하여 승인되지 않은 작업을 수행할 수 있습니다. 경로 기반 강제(Path-based enforcement)는 동일한 바이너리에서 동일한 시스템 호출(system call)을 사용하는 경우, 정당한 파일 읽기와 데이터 유출(exfiltration) 목적의 파일 읽기를 구분할 수 없습니다.

이것은 이러한 접근 방식들에 대한 비판이 아닙니다. 그것들이 서로 다른 문제를 해결한다는 관찰입니다. 인프라 강제 적용 (Infrastructure enforcement)은 에이전트로부터 시스템을 보호합니다. 행동 테스트 (Behavioral testing)는 에이전트 자체가 압박 속에서 올바르게 행동하는지를 검증합니다. 둘 다 필요합니다. 하지만 하나가 다른 하나를 위한 전제 조건입니다.

행동 테스트가 실제로 테스트하는 것 (그리고 테스트하지 않는 것)
행동 테스트가 무엇을 다루는지 구체적으로 명시하는 것이 중요합니다.

AI 에이전트를 위한 적대적 테스트 (Adversarial testing)는 네트워크 계층 (network layer)이 아닌 대화 계층 (conversation layer)에서 작동합니다. 이는 네트워크 취약점 공격 (network exploits)이나 바이너리 퍼징 (binary fuzzing)을 통해서가 아니라, 정교하게 설계된 대화를 통해 프롬프트 주입 (prompt injection), 탈옥 (jailbreaks), 도구 오용 (tool abuse), 데이터 유출 (data exfiltration), 그리고 권한 범위 위반 (scope violations)을 테스트합니다. 공격 벡터 (attack vector)는 언어입니다. 테스트되는 방어 기제는 누군가가 에이전트를 의도적으로 이탈시키려 할 때, 에이전트가 의도된 행동을 유지할 수 있는 능력입니다.

에이전트 기반 다회차 테스트 (Agentic multi-turn testing)는 이를 도구 접근 권한이 있는 에이전트로 확장합니다. 단발성 프롬프트 주입 대신, 현실적인 공격 체인 (attack chains)을 시뮬레이션합니다. 즉, 무해하게 시작하여 점진적으로 권한 범위 위반이나 도구 오용으로 에스컬레이션되는 다단계 대화를 시뮬레이션하는 것입니다. 이는 실제 공격자들이 AI 시스템을 상대로 작동하는 방식에 더 가깝습니다. 그들은 단 하나의 악성 프롬프트를 보내지 않습니다. 그들은 맥락을 구축하고, 유대감을 형성하며, 점진적으로 경계를 허뭅니다.

평가 계층 (evaluation layer) 또한 중요합니다. LLM-as-a-Judge 접근 방식은 전통적인 침투 테스트 (pentesting)의 이진적인 '공격 성공/실패' 방식 대신, 신뢰도 점수와 함께 구조화된 판결 (pass/fail/violation)을 제공합니다. 이는 AI 에이전트의 실패가 스펙트럼 상에 존재하기 때문에 중요합니다. 정보를 약간 과하게 공유하는 에이전트와 자격 증명 (credentials)을 유출하는 에이전트는 다르며, 여러분의 테스트 프레임워크는 그러한 세밀함 (granularity)을 포착할 수 있어야 합니다.

행동 테스트 (behavioral testing)가 다루지 못하는 것: 에이전트가 인프라 계층 (infrastructure level)에서 시스템에 수행하는 작업은 테스트하지 않습니다. 파일 작업 (File operations), API 호출 (API calls), 네트워크 액세스 (network access), 프로세스 실행 (process execution) 등이 이에 해당합니다. 이는 진정으로 실행 계층 강제 도구 (execution-layer enforcement tools)의 영역입니다. 만약 에이전트가 악성 파일을 작성하거나 승인되지 않은 네트워크 호출을 수행한다면, 대화 계층 (conversation layer)에서의 행동 테스트로는 이를 포착할 수 없습니다.

이 지점이 바로 강제 계층 (enforcement layers)이 테스트를 보완하는 부분입니다. 이 둘은 대안 관계가 아닙니다. 동일한 라이프사이클 (lifecycle)의 서로 다른 단계입니다.

효과적인 라이프사이클: 테스트, 학습, 강제, 모니터링, 재테스트
테스트, 강제, 그리고 모니터링은 독립적인 활동이 아닙니다. 이들은 각 단계가 다음 단계를 더 개선하는 피드백 루프 (feedback loop)를 형성합니다.

Humanbound에서는 이러한 통찰을 바탕으로 ASCAM (AI Security Continuous Assurance Model) 엔진을 구축했습니다. 테스트를 일회성 이벤트로 취급하는 대신, 에이전트의 보안 태세 (security posture)를 평가하고 적절한 시점에 적절한 활동을 선택하는 지속적인 의사결정 루프 (decision loop)로 작동하게 합니다.

• 스캔 (Scan) - 범위 (scope)를 추출하고, 위험 프로필 (risk profile)을 파악하며, 보안 기준선 (security baseline)을 수립합니다.
• 평가 (Assess) - 에이전트를 위한 맞춤형 위협 모델 (threat model)을 구축하기 위한 구조화된 레드팀 (red teaming) 활동을 수행합니다.
• 조사 (Investigate) - 식별된 취약점, 회귀 (regressions), 그리고 새롭게 등장하는 위협 클래스 (threat classes)에 대한 타겟 재테스트를 수행합니다.
• 모니터링 (Monitor) - 운영 환경 (production)에서 행동 회귀 (behavioral regressions)가 발생하는지 지속적인 드리프트 탐지 (drift detection) 및 센티넬 테스트 (sentinel testing)를 수행합니다.

이것들은 한 번만 실행되는 순차적인 단계가 아닙니다. 의사결정 엔진 (decision engine)은 매 사이클마다 여러 신호—중대한 발견 사항, 태세 변화, 커버리지 격차, 행동 드리프트—를 평가하고, 에이전트의 현재 상태가 요구하는 활동으로 경로를 지정합니다. 이전에 안전했던 영역에서 회귀가 발생하면 조사를 트리거합니다. 모델 업데이트가 발생하면 재평가를 트리거합니다. 안정적인 태세는 모니터링 상태를 유지합니다. 시스템이 스스로 우선순위를 정하는 것입니다.

공격 방법론(attack methodology)은 특히 중요합니다. 정적인 테스트 스위트(test suites)에 의존하는 대신, 시스템은 모든 상호작용으로부터 학습하는 적응형 전략(adaptive strategies)을 사용합니다. 각 대화는 실시간으로 점수가 매겨집니다. 에이전트를 무너뜨리는 데 진전이 있는 전략은 정교화되고 에스컬레이션(escalated)되는 반면, 강력한 거부(hard refusals)에 부딪히는 접근 방식은 우선순위가 낮아지거나 대화 도중에 전환(pivoted)됩니다. 성공적인 공격 패턴은 추출되고 일반화되어 향후 테스트 사이클에 재주입됩니다. 지속적으로 효과가 없다고 증명된 전략은 폐기됩니다. 공격 라이브러리는 매 테스트 실행마다 성장합니다. 이는 수동 큐레이션이 아니라, 각 특정 에이전트에 대해 실제로 무엇이 작동하는지를 포착하는 자기 학습 루프(self-learning loop)를 통해 이루어집니다.

이는 전통적인 침투 테스트(pentest) 체크리스트보다는 커버리지 가이드 퍼징(coverage-guided fuzzing)의 정신에 더 가깝습니다. 시스템은 알려진 패턴을 반복하기보다 탐색되지 않은 공격 표면(attack surfaces)을 우선시합니다. 하지만 정적 퍼징(static fuzzing)과 달리, 에이전트의 실시간 응답을 기반으로 접근 방식을 조정하며, 대화 내부 및 대화 간에 학습한 내용을 바탕으로 발전해 나갑니다.
그 결과: 시스템은 사용자가 테스트 케이스를 직접 작성하지 않을 법한 실패 모드(failure modes)를 발견합니다. 적응형 프로세스가 인간이 작성한 테스트 스위트보다 더 넓게 공간을 탐색하기 때문입니다.
가드레일(guardrails) 내보내기 단계가 이 루프를 완성합니다. 적대적 테스트(adversarial testing)를 통해 얻은 결과는 적응형 컨텍스트 방어(Adaptive Context Defense, ACD)를 통해 방화벽 규칙이 됩니다. 테스트가 런타임 방어 계층(runtime defense layer)을 직접 훈련시키는 것입니다. 더 많이 테스트할수록 방화벽은 더 좋아집니다. 그리고 방화벽이 운영 환경(production)에서 무언가를 차단하면, 그 신호는 다음 테스트 사이클로 피드백됩니다.

드리프트 탐지(Drift detection)는 지속적인 보증(continuous assurance)을 실용적으로 만드는 핵심 요소입니다. 에이전트는 끊임없이 변합니다. 모델이 업데이트됩니다. 시스템 프롬프트(system prompts)가 수정됩니다. 도구 권한(tool permissions)이 변경됩니다. 1월에 테스트했던 에이전트는 3월에 실행 중인 에이전트와 동일하지 않습니다. 드리프트 탐지가 없다면, 테스트 결과는 가치가 하락하는 특정 시점의 스냅샷에 불과합니다. 드리프트 탐지가 있다면, 행동 회귀(behavioral regressions)가 발생할 때 자동으로 재평가를 트리거합니다.

14.4%의 문제
데이터는 그 어떤 아키텍처적 논거보다 더 명확하게 이 문제를 입증합니다.

Gravitee의 AI 에이전트 보안 상태(State of AI Agent Security) 보고서에 따르면, 전체 AI 에이전트 중 단 14.4%만이 완전한 보안 승인을 거쳐 라이브(go live) 상태가 됩니다. Confluent, Elastic, UiPath, Deutsche Borse의 CISO(정보보호최고책임자)들의 의견을 수렴한 AIUC-1 컨소시엄은, 조직의 80%가 권한 없는 시스템 접근 및 부적절한 데이터 노출을 포함한 위험한 에이전트 행동을 보고하고 있다고 기록했습니다. 경영진 중 에이전트의 권한, 도구 사용 또는 데이터 접근 패턴에 대한 가시성을 확보한 비율은 21%에 불과합니다.

수치가 모든 것을 말해줍니다: 에이전트의 85.6%가 완전한 보안 승인 없이 출시됩니다. 조직의 80%는 이미 위험한 행동을 목격하고 있습니다.

배포 전에 테스트되지 않은 에이전트에게 집행 아키텍처(Enforcement architecture)는 무의미합니다. 세계에서 가장 정교한 제어 평면(control plane)을 구축할 수 있겠지만, 그 제어 대상인 에이전트가 적대적 조건(adversarial conditions)에 대해 검증되지 않았다면, 귀하의 집행 정책은 에이전트가 실제로 무엇을 하는지에 대한 증거가 아니라, 에이전트가 무엇을 하기를 바라는지에 기반한 것이 될 뿐입니다.

David Campbell가 언급했듯이, "프롬프트 인젝션(prompt injection)을 테스트한다고 해서 자동으로 안전해지는 것은 아닙니다." 맞는 말입니다. 하지만 전혀 테스트하지 않는 것은 확실히 안전하지 않다는 것을 의미합니다.

*_ 이번 주에 해야 할 일
실무자들을 위한 실행 가능한 버전은 간단합니다.
*_
배포된 에이전트의 인벤토리(Inventory)를 작성하십시오. 대부분의 조직은 생각보다 더 많은 에이전트를 보유하고 있습니다. AIUC-1 데이터에 따르면 기업당 평균 1,200개의 비공식 AI 애플리케이션이 존재하는 것으로 나타났습니다. 발견하지 못한 대상은 테스트하거나 관리할 수 없습니다.