자율 에이전트(Autonomous Agent)를 위한 검토할 Pull Request는 없습니다. 그렇다면 무엇을 검토해야 할까요?

일반적인 서비스를 배포할 때, 보안 검토(Security review)에는 기준점이 있습니다. 바로 디프(diff)입니다. 누군가 풀 리퀘스트(Pull Request, PR)를 열면, 누군가 그것을 읽고, 프로덕션(Production)에서 실행되는 것은 바로 검토를 거친 그 내용입니다.

이제 자율 에이전트(Autonomous agent)를 프로덕션에 배치한다고 가정해 봅시다. 에이전트는 계획을 세우고, 도구(Tools)를 호출하며, 상태(State)를 변경합니다. 이 과정은 종종 인간의 승인 없이 이루어집니다. 여기서 당연한 질문을 던져봅시다. "방금 수행한 작업에 대한 PR은 어디에 있나요?" — 답은 없습니다. 에이전트는 커밋(Commit)을 통해 작업을 배포한 것이 아닙니다. 런타임(Runtime)에 스스로 결정한 것입니다.

따라서 여러분이 익숙하게 해온 검토 방식은 잘못된 아티팩트(Artifact)를 겨냥하고 있습니다. 이제 올바른 대상을 가리킬 수 있도록 도와드리겠습니다.

에이전트는 배포된 코드가 아니라 설정(Configuration)입니다

여기 핵심적인 관찰 결과가 있습니다. 자율 에이전트는 코드가 아닙니다. 그것은 인프라의 런타임 _설정(Configuration)_입니다. 즉, 컨테이너(Container), 하네스(Harness, 모델을 실행하고 대신 도구를 호출하는 루프), 시스템 프롬프트(System prompt), 도구 인터페이스(Tool surface), 메모리(Memory), 정체성(Identity), 그리고 네트워크 이그레스 정책(Network egress policy)의 조합입니다.

모델은 대부분 고정되어 있습니다. 하지만 그 주변의 모든 것은 그렇지 않습니다. 동일한 모델과 동일한 작업 설명(Task description)을 바탕으로 구축된 두 에이전트라도, 이러한 구성 요소들이 어떻게 설정되었는지에 따라 완전히 다르게 행동할 수 있습니다. 어떤 도구에 접근할 수 있는지, 시스템 프롬프트가 무엇을 하라고 지시하는지, 어떤 메모리를 보유하는지, 네트워크가 무엇을 내보내도록 허용하는지에 따라 달라집니다. 보안과 관련된 아티팩트는 실행 중인 설정(Running configuration)이며, 애플리케이션 코드만을 겨냥한 검토는 이를 그대로 지나쳐 버립니다.

에이전트를 하나의 설정(Config)으로 바라보는 순간, "무엇을 검토해야 하는가?"라는 질문에 대한 답이 나옵니다. 바로 설정을 검토하는 것입니다.

시스템 프롬프트와 하네스를 버전 관리되고 디프(Diff) 검토가 가능한 아티팩트로 취급하세요

대부분의 팀은 시스템 프롬프트(system prompt)를 설정(settings)으로 취급합니다. 즉, 대시보드에서 편집 가능한 텍스트 박스이며, 접근 권한이 있는 누구라도 변경할 수 있는 것으로 여깁니다. 이것이 문제입니다. 시스템 프롬프트는 작업(task), 요청 거부 규칙, 그리고 출력의 형태를 인코딩(encode)합니다. 프롬프트의 단 한 줄 변경만으로도 가드레일(guardrail)을 조용히 제거할 수 있습니다. 운영 환경(prod)에서 편집 가능한 시스템 프롬프트는 _검토되지 않고, 작성자가 명시되지 않으며, 에이전트의 행동에 완전한 영향력을 행사하는 코드 경로(code path)_입니다.

실제 사고 사례들이 이를 증명합니다. "Rules File Backdoor" 사례는 Cursor와 GitHub Copilot에서 보이지 않는 유니코드(Unicode)를 사용하여 편집 가능한 규칙 파일(rules files)을 무기화했습니다. DPD의 지원 봇은 가드레일을 제거하는 시스템 업데이트 이후 고객에게 욕설을 하기 시작했습니다. 뉴욕시의 MyCity 봇은 집주인들에게 Section 8 세입자를 거부할 수 있다고 안내했는데, 이는 불법적인 조언이었으며 몇 주 동안 지속되었습니다. 이 중 어느 것도 모델의 실패가 아니었습니다. 이것들은 구성(configuration) 변경이었으나, 아무도 구성을 검토해야 할 대상으로 취급하지 않았기 때문에 아무도 검토하지 않았던 것입니다.

따라서 이를 코드처럼 취급하십시오. 시스템 프롬프트, 하네스 설정(harness config), 훅(hooks), 그리고 MCP 서버 목록을 버전 관리(version control) 시스템에 넣으십시오. 오직 검토를 통해서만 변경하십시오. 디프(Diff)를 확인하십시오. 이제 가드레일 제거는 운영 콘솔에서의 조용한 편집이 아니라, 작성자가 명시된 검토 가능한 변경 사항으로 나타나게 됩니다.

릴리스별로 구성을 동결하고, 이를 정체성(identity)에 고정하세요

만약 구성이 아티팩트(artifact)라면, 구성의 변경은 새로운 빌드(build)를 의미하며, 이는 _가시적(visible)_이어야 합니다. 실질적인 방법은 배포된 구성(컨테이너 다이제스트(container digest), 하네스 버전, 시스템 프롬프트 버전, 모델 식별자, 설정 등)에 대한 콘텐츠 해시(content hash)를 생성하고, 그 해시를 에이전트의 유형 정체성(type identity, BRACE에서는 agent-type-id라고 부름)으로 만드는 것입니다. 이제 이러한 구성 요소 중 어느 하나라도 변경되면 다른 정체성이 생성됩니다. 프롬프트를 몰래 바꾸면서 동일한 이름을 유지할 수는 없습니다. 새로운 구성은 새로운 빌드이며, 로그에 그 사실이 기록됩니다.

에이전트 단위로 드리프트(drift)를 감지하세요

Infrastructure-as-code (IaC) 드리프트 감지(drift detection)는 플랫폼 팀이 아마 이미 실행하고 있을 제어 항목일 것입니다. 문제는 이것이 보통 호스트(host) 수준에서 실행된다는 점이며, 에이전트에게 중요한 변경 사항은 그보다 한 단계 아래에 숨겨져 있다는 것입니다.

따라서 이를 에이전트의 표면(surface)에 구체적으로 지정하십시오. 단순히 호스트뿐만 아니라 컨테이너 이미지, 하네스(harness) 구성, MCP 서버 목록, 시스템 프롬프트(system prompts), 그리고 에이전트별(per-agent) 네트워크 송신(egress) 정책을 대상으로 삼아야 합니다. 한 에이전트의 목록에 조용히 추가된 MCP 서버(Postmark-MCP 악성 패키지 사고 참조)는 호스트 수준의 점검에서는 걸러지지 않습니다. 하지만 해당 에이전트의 구성에 범위를 맞춘 드리프트 점검(drift check)은 이를 잡아낼 것입니다.

구성 인접 관찰 가능 항목(config-adjacent observables)을 캡처하세요

실제로 어떤 구성이 실행되었는지 알려주는 두 가지 요소가 있으며, 두 가지 모두 놓치기 쉽습니다.

• 의사결정 시점의 컨텍스트 크기 (Decision-time context size) — 모델이 행동할 때 앞에 두고 있었던 컨텍스트의 양입니다. 동일한 에이전트라도 컨텍스트가 거의 비어 있을 때와 거의 가득 차 있을 때 다르게 행동합니다.
• 부모가 전달한 프롬프트 (The parent-passed prompt) — 멀티 에이전트(multi-agent) 설정에서 호출하는 에이전트가 실제로 하위 에이전트에게 전달한 내용입니다. 이는 자식 에이전트의 실질적인 구성의 일부이며, 자식의 자체 프롬프트만 기록한다면 이는 보이지 않게 됩니다.

만약 어떤 동작이 잘못되었다면, 이 요소들은 "어떤 구성이 작동 중이었는지 정확히 알 수 있는 상태"와 "추측만 하는 상태"를 가르는 결정적인 차이가 됩니다.

이 중 어느 것도 새로운 인프라를 요구하지 않습니다. 버전 관리(version control), 콘텐츠 해싱(content hashing), IaC 드리프트 감지, 그리고 구조화된 로깅(structured logging)은 여러분이 이미 실행하고 있는 것들입니다. 변하는 것은 그것들을 _어디로 향하게 하느냐_입니다. 즉, 에이전트가 무엇을 할지 실제로 결정하는 산출물(artifact)인 에이전트의 구성으로 향하게 하는 것입니다.

이는 에이전트 보안을 위한 오픈 프레임워크인 BRACE의 구성(Configuration) 관련 관심사이며, 가이드에서는 각 제어 항목에 대해 더 자세히 다룹니다.

마지막으로 던지고 싶은 솔직한 질문이 하나 있습니다: 여러분은 에이전트의 시스템 프롬프트를 버전 관리하고 차이점 검토(diff-review)를 수행하고 있습니까? 아니면 콘솔 접근 권한이 있는 누구나 흔적 없이 변경할 수 있는, 편집 가능한 런타임 구성(runtime config)입니까? 그 답변이 바로 검토할 내용이 실제로 존재하는지 여부를 알려줄 것입니다.