코딩 에이전트가 코드 동결(code freeze) 기간 중에 운영 데이터베이스(production database)를 삭제한 뒤, 롤백(rollback)이 불가능하다고 보고했습니다(실제로는 가능했습니다). 또 다른 에이전트는 명령어를 잘못 읽은 후 사용자의 파일을 삭제했습니다. 파괴적인 페이로드(payload)가 널리 배포되는 개발자 확장 프로그램에 병합되어 약 100만 명에게 전달되었습니다. 제로 클릭 프롬프트 인젝션(zero-click prompt injection)은 주요 기업용 AI 어시스턴트로부터 데이터를 조용히 유출했습니다.

이것들은 더 이상 예외적인 사례(edge cases)가 아닙니다. 에이전트가 인간의 검토 없이 각 작업을 계획하고, 도구(tools)를 호출하며, 실제 시스템을 변경하고, 하위 에이전트(sub-agents)를 생성할 수 있게 되면, 질문은 "모델이 좋은가?"에서 "이것이 잘못되었을 때 실제로 무엇을 할 수 있는가?"로 바뀝니다.

나는 한동안 공개된 사고 사례들을 읽으며 공통된 실마리를 찾으려 노력했습니다. 나의 관점을 완전히 바꿔놓은 핵심은 다음과 같습니다.

에이전트는 배포된 코드가 아니라 — 하나의 설정(configuration)이다

전통적인 소프트웨어를 검토할 때는 코드를 검토합니다. 하지만 자율 에이전트(autonomous agent)의 경우 검토할 코드가 많지 않은 경우가 많습니다. 동작은 _런타임 설정(runtime configuration)_에서 비롯됩니다. 즉, 컨테이너(container), 하네스(harness, 모델을 실행하고 도구를 전달하는 래퍼), 시스템 프롬프트(system prompt), 사용 가능한 도구 세트, 메모리 저장소(memory store), 정체성(identity), 그리고 네트워크 경계(network boundary)가 그것입니다.

정확히 동일한 모델로 구축된 두 에이전트라도 이러한 구성 요소들이 어떻게 조립되느냐에 따라 완전히 다르게 동작할 수 있습니다. 따라서 보안 질문은 "코드가 안전한가"가 아니라 "설정이 제한(bounded)되어 있는가"가 되어야 합니다. 이러한 관점의 전환은 당신의 노력을 어디에 집중해야 하는지를 바꿔 놓습니다.

다섯 가지 우려 사항과 각 사항이 제한하는 것

나는 실제로 문제가 발생하는 지점들을 다섯 가지 설정 영역으로 정리했습니다:

다섯 가지 우려 사항과 각 사항이 제한하는 것

나는 실제로 문제가 발생하는 지점들을 다섯 가지 설정 영역으로 정리했습니다:

• Build-time (빌드 시간) — 아키텍처, API 접근, 컨테이너, 하네스(harness). 에이전트가 빌드되어 아티팩트에 고정될 때 결정됩니다. 이 단계에서 에이전트가 애초에 무엇에 도달할 수 있는지 결정합니다.
• Run-time (실행 시간) — 모든 실행마다 활성화되는 데이터, 메모리 및 행동 검사입니다. 여기서 실제로 작동하는 것을 관찰합니다.
• Agent (에이전트) — 에이전트 유형별 우려 사항: 범위가 지정된 토큰(scoped tokens), 정책 표면으로서의 시스템 프롬프트(system prompt), 그리고 에이전트가 실제로 필요로 하는 도구와 제공받은 도구 사이의 차이점입니다.
• Configuration (설정) — 드리프트(drift). 승인된 설정과 실행 중인 설정이 시간이 지남에 따라 달라지며, 강화된 배포 환경도 조용히 안전하지 않은 상태로 퇴보합니다.
• Ecosystem (생태계) — 모든 에이전트가 구동되는 공유 기반 구조: 신원 발급(identity issuance), 이그레스 제어(egress control), 그리고 MCP 서버 및 공급망입니다.

각 우려 사항은 서로 다른 실패 클래스를 경계합니다. 범위가 지정된 토큰은 피해 반경(blast radius)을 제한하고, 이그레스 제어는 유출(exfiltration)을 제한하며, 드리프트 감지(drift detection)는 느린 퇴보를 제한합니다. 이들 중 어느 것도 생소한 것은 아니며, 대부분 이미 사용하고 있는 도구들로 구축됩니다.

가장 높은 레버리지를 가진 단 하나의 제어 장치

만약 한 가지를 한다면: 하네스(harness)가 기본적으로 파괴적인 동사(destructive verbs)를 거부하도록 만드세요.

delete, drop, wipe, 강제 푸시(force-push), 대량 취소(mass-revoke)`와 같은 위험한 동작들은 해당 에이전트 유형에 명시적으로 허용되지 않는 한 하네스에서 차단됩니다.

제가 구축한 것은 BRACE — Build-time, Run-time, Agent, Configuration, Ecosystem(빌드 타임, 런타임, 에이전트, 설정, 생태계)라고 불리는 체계입니다. 이는 9가지 통제 항목(controls), 3가지 관측성 요구사항(observability requirements), 그리고 한 페이지 분량의 승인 체크리스트(sign-off checklist)로 구성되어 있으며, OWASP Agentic Top 10 및 MITRE ATLAS와 역매핑(reverse-maps)되어 있어, 여러분이 특정 통제 항목을 건너뛰기로 선택할 때마다 어떤 위협의 주요 완화책(mitigation)이 사라지는지 정확히 확인할 수 있습니다.

이것은 개방적이며 특정 벤더에 종속되지 않습니다(vendor-neutral). 가이드와 체크리스트는 여기에서 확인할 수 있습니다: https://braceframework.org/

무언가를 판매하기 위해 이 글을 올리는 것이 아닙니다 — 살 수 있는 것은 아무것도 없습니다. 제가 이 글을 올리는 이유는 누군가 이 체계를 기반으로 에이전트를 출시한 이후가 아니라, 지금 당장 허점(holes)을 찾아내고 싶기 때문입니다. 만약 "에이전트는 설정이다(agent is a configuration)"라는 프레임워크가 어디선가 무너지거나, 통제 항목이 누락되었거나, 혹은 실제 적용 시 실행 불가능한 항목이 있다면, 저는 그 의견을 듣고 싶습니다. 이 체계의 일부만 채택한다는 것은 남은 위험을 의도적으로 수용한다는 의미이며, 저는 그 위험이 정직하기를 바랍니다.

자, 그럼: 여러분이 개인적으로 목격했거나 수습했던 최악의 자율 에이전트(autonomous-agent) 실패 사례는 무엇인가요? 저는 뉴스에 보도되지 않는 사례들을 수집하고 있습니다.