에이전트 보안의 승패는 빌드 타임(Build-time)에서 결정된다

2025년, 한 AI 코딩 에이전트가 코드 동결(code freeze) 기간 중 운영 데이터베이스(production database)를 삭제한 뒤, 운영자에게 롤백(rollback)이 불가능하다고 통보했습니다. 이것은 탈옥(jailbreak)이나 특이한 익스플로잇(exploit) 때문이 아니었습니다. 에이전트는 단순히 운영 환경(prod)으로 가는 경로, 테이블을 삭제할 수 있는 자격 증명(credential), 그리고 파괴적인 호출을 통과시키는 하네스(harness)를 가지고 있었을 뿐입니다. 그 체인의 모든 연결 고리는 에이전트가 실행을 시작하기 전, 누군가가 내린 결정이었습니다.

이것이 불편하지만 유용한 부분입니다. 대부분의 에이전트 보안 조언은 모델이 제대로 행동하게 만드는 것, 즉 더 나은 프롬프트(prompt), 더 나은 거부(refusal), 출력에 대한 더 나은 가드레일(guardrails)에 집중합니다. 이러한 방법들도 도움이 되지만, 모두 모델이 제대로 행동한다는 전제에 의존합니다. 빌드 타임(Build-time) 제어는 그렇지 않습니다. 이는 도구(tools), 네트워크 경로(network routes), 자격 증명(credentials), 거부 목록(deny list)과 같이 사전에 고정해 두는 것들이며, 모델이 순응하든, 혼란스러워하든, 혹은 주입된 입력(injected input)에 의해 적극적으로 하이재킹(hijacked)당하든 상관없이 유지됩니다. 만약 단 하나의 계층에만 투자해야 한다면, 바로 여기에 투자하십시오.

제가 생각하는 방식을 쉬운 용어로 설명하겠습니다.

에이전트에게 필요한 최소한의 것만 사전에 결정하여 부여하십시오. 도구(tools), MCP 서버, 자격 증명(credentials), 파일 경로(file paths), 네트워크 목적지(network destinations)에 대해 최소 권한(Least privilege)을 적용하십시오. 당신이 부여하는 모든 것은 곧 침해된 에이전트가 할 수 있는 일이 됩니다. 즉, "역량(capabilities)"과 "공격 표면(attack surface)" 사이에는 간극이 없습니다.

같은 방향을 가리키는 두 번째 이유가 있으며, 이는 사람들이 놓치는 부분입니다. 도구가 적을수록 에이전트는 더욱 "우수해"집니다. 당신이 연결하는 모든 도구와 MCP 서버는 매 단계마다 스키마(schema)로서 모델의 컨텍스트(context)에 주입됩니다. 도구가 많아질수록 메뉴를 읽는 데 더 많은 토큰(tokens)이 소모되며, 측정 가능한 수준으로 도구 선택 능력이 저하됩니다. 모델은 50개의 옵션이 있을 때보다 6개의 옵션이 있을 때 더 실수를 적게 합니다. 따라서 도구의 표면(tool surface)을 줄이는 것은 역량을 희생하며 지불하는 보안 세금이 아닙니다. 그것은 두 가지를 모두 얻는 길입니다. 이러한 재정의는 보안을 위해 제한하는 것에 저항하는 사람들을 설득하는 데 효과적입니다.

신뢰(Trust)가 아닌 토폴로지(Topology)로 폭발 반경(Blast radius)을 제한하세요. 에이전트는 네트워크 경로가 없는 운영(Prod) 데이터베이스를 삭제할 수 없습니다. 물리적 및 네트워크 격리는 위협 모델(Threat-model)에 구애받지 않습니다. 즉, 원인이 영리한 공격자이든, 혼란에 빠진 모델이든, 통제 불능의 루프(Runaway loop)이든 상관하지 않습니다. 운영(Prod), 스테이징(Staging), 개발(Dev) 환경을 실제로 분리하여, 스테이징 권한을 가진 에이전트가 어떤 장애 모드에서도 운영 환경에 도달할 수 없도록 하세요.

모든 자격 증명(Credential)의 범위를 지정하고 시간 제한(Time-box)을 두세요. 권한 범위가 지정된 토큰(Capability-scoped tokens, 예: read:tickets, 절대 tickets:*가 아님)을 사용하고, 수명이 짧아야 하며, 환경 내에 상시 유지되는 만능 자격 증명(Standing god-credentials)이 있어서는 안 됩니다. 분석 에이전트는 데이터를 읽는 데 사용하는 동일한 토큰을 통해 레코드를 삭제할 수 없어야 합니다. 이는 팀들이 가장 많이 건너뛰는 계층입니다. 왜냐하면 기능별로 토큰을 발행하는 것은 실제 운영 작업(Operational work)을 요구하기 때문입니다. 하지만 바로 이 계층이 다른 모든 계층이 실패했을 때 피해를 억제하는 역할을 합니다.

하네스(Harness)에서 파괴적인 동작을 차단하고, 기본적으로 거부(Deny by default)하세요. 이것은 단일 항목 중 가장 레버리지가 높은 빌드 타임(Build-time) 제어 방식이므로, 정확하게 정의할 가치가 있습니다. 모델을 실행하고 도구(Tools)를 호출하는 루프인 _하네스(Harness)_는 파괴적인 동사 클래스(Destructive verb classes)의 명시적인 목록을 유지합니다: 파일 삭제, 재귀적 제거, DROP/TRUNCATE, 보호된 브랜치로의 강제 푸시(Force-push), 인프라 해체(Infra teardown), 결제 상태 변경, 대량 외부 전송 등입니다. 각 동작은 실행되기 전에 가로채집니다. 기본 설정은 거부입니다. 이번 실행을 위해 사전 승인되지 않은 파괴적 동사를 호출하는 에이전트는 하네스에서 차단됩니다. 이는 하네스가 해당 호출이 안전하지 않다고 판단했기 때문이 아니라, 해당 호출이 안전하다는 판단을 내린 것이 아무것도 없기 때문입니다.

핵심은 _모델(Model)_이 파괴적인 명령과 당신의 데이터 사이를 가로막는 존재가 되어서는 안 된다는 것입니다. 인간(또는 대역외 자격 증명(Out-of-band credential))이 그 역할을 해야 합니다. Amazon Q가 VS Code 확장을 통해 약 100만 명의 개발자에게 파괴적인 와이퍼(Wiper) 페이로드를 전송했을 때, 그 실패의 원인은 파괴적인 동사가 앞에 아무런 방어 장치 없이 실행 단계에 도달했기 때문입니다. 기본적으로 거부하는(Deny-by-default) 하네스가 바로 그 앞에 있어야 하는 장치입니다.

두 가지만 더 짧게 언급하겠습니다:

빌드를 고정(Pin)하고 서명(Sign)하며, 다이제스트(Digest)를 에이전트의 ID에 포함시키세요. 다이제스트로 고정된 최소한의 서명된 컨테이너(Signed container)를 사용함으로써, "우리가 검토한 것"과 "실제로 실행 중인 것" 사이의 조용한 드리프트(Drift)가 보이지 않게 숨겨지는 대신 감지 가능하도록 만들어야 합니다.

하네스(Harness)와 시스템 프롬프트(System prompt)를 버전 관리되고 차이점 검토(Diff-reviewed)를 거치는 아티팩트(Artifact)로 취급하세요. 이들은 이력(History) 없이 웹 UI에서 직접 수정할 수 있는 설정(Config)이 아닙니다. 도구 허용 목록(Tool allowlist), 권한 범위(Capability scopes), 또는 파괴적 동사 목록(Destructive-verb list)에 대한 모든 변경 사항은 작성자가 아닌 다른 사람의 승인을 받은 검토된 차이점(Diff) 형태로 반영되어야 합니다.

이 중 어느 것도 생소한 것이 아닙니다. 이는 여러분이 이미 프로덕션(Production)에 닿는 모든 것에 적용하고 있는 것과 동일한 엔지니어링 규율이며, 다만 그 대상이 즉흥적으로 행동하고, 관리자 없이 실행되며, 자신의 권한이 허용하는 무엇이든 수행할 수 있는 새로운 종류의 행위자(Actor)를 향하고 있을 뿐입니다. 전체 가이드와 체크리스트는 여기에서 확인할 수 있습니다: https://braceframework.org/guides/build-time/

따라서 실무적인 질문을 던지겠습니다. 여러분은 오늘날 파괴적인 도구 호출(Destructive tool calls)을 어떻게 처리하고 계십니까? 여러분의 하네스에 실질적인 거부 우선(Deny-by-default) 게이트가 있습니까, 아니면 여전히 모델이 에이전트와 DROP TABLE 사이의 마지막 방어선입니까?