에이전트에게 보안 경계가 필요한 이유: 이제는 선택이 아닌 필수입니다

지난주, 팀 전체에 에이전트(Agents)를 배포 중인 한 엔지니어로부터 연락을 받았습니다. 그들은 CRM에서 정보를 가져오고, 계정 기록을 업데이트하며, 후속 이메일을 보내는 스마트한 고객 서비스 에이전트를 구축했습니다. 테스트 단계에서는 아주 잘 작동했습니다. 하지만 운영(Production) 3일 차에, 누군가 해당 에이전트가 고객 기록을 삭제할 수 있다는 사실을 깨달았습니다. "조건이 맞으면 삭제할 수도 있다"는 수준이 아니었습니다. 삭제할 수 있었습니다. 의도적으로 말이죠. 그들은 결국 에이전트를 긴급하게 비활성화해야 했습니다.

이것은 더 이상 예외적인 사례가 아닙니다. 운영 환경에서의 기본값입니다.

에이전트 권한 문제

에이전트 거버넌스(Governance)가 기존의 API 액세스와 다른 점은 다음과 같습니다: 에이전트 실행은 간접적이며 승수적(Multiplicative)입니다.

사람이 API 토큰을 요청할 때는 그 범위(Scope)를 알 수 있습니다: "고객 기록 읽기" 또는 "이메일 보내기". 명확한 경계가 존재합니다.

하지만 에이전트가 실행될 때는 문맥(Context) 가져오기, 도구(Tool) 호출, 결과 평가, 또 다른 도구 호출, 루프(Loop) 등 수십 가지의 결정을 순차적으로 내립니다. 각 도구 호출은 권한 확인 과정입니다. 만약 매 단계마다 확인하지 않는다면, 여러분은 에이전트가 스스로 추론하여 경계 내에 머물 것이라고 가정하는 셈입니다.

그것은 인프라가 아닙니다. 그것은 희망 사항일 뿐입니다.

이 격차는 구조적입니다. OAuth 스코프(Scopes)와 IAM 역할(Roles)은 에이전트가 어떤 서비스에 접근할 수 있는지를 제어합니다. 하지만 _연결된 후 무엇을 하는지_는 제어하지 못합니다. DeleteCustomer API에 접근 권한이 있는 에이전트는, 설령 그것이 의도된 동작이 아니었더라도 워크플로(Workflow)가 요청한다면 고객을 삭제할 것입니다.

멀티 에이전트 시스템(Multi-agent systems)에서는 다섯 개의 에이전트가 단일 API 키를 공유할 수도 있습니다. 무언가 잘못되었을 때, "에이전트가 그랬다"라고 말하는 것은 사고 대응(Incident response)이 될 수 없습니다.

이번 달에 변한 것

2026년 6월, 세 가지 요소가 수렴했습니다:

규제의 강화. EU AI Act(유럽연합 AI 법)의 고위험(high-risk) 의무 사항이 지금으로부터 71일 후인 2026년 8월 2일에 발효됩니다. 콜로라도 AI 법은 6월 30일부터 집행되었습니다. 이것들은 더 이상 권고 사항이 아니라 법적 요구 사항입니다. 제14조는 고위험 AI 시스템이 '자연인에 의한 효과적인 감독(effective oversight by natural persons)'이 가능하도록 설계될 것을 요구합니다. 에이전트 시스템의 경우, 모든 에이전트 신원(identity), 모든 도구 API 키, 그리고 모든 하위 에이전트 토큰(sub-agent token)은 최소 권한 원칙(least-privilege principles)에 따라 관리되어야 합니다.

업계가 위험을 정의했습니다. OWASP는 2025년 12월, 자율 AI 에이전트에 특화된 최초의 공식 위험 분류 체계인 '에이전트 애플리케이션을 위한 Top 10(Top 10 for Agentic Applications)'을 발표했습니다: 목표 하이재킹(goal hijacking), 도구 오용(tool misuse), 신원 남용(identity abuse), 메모리 오염(memory poisoning), 연쇄 실패(cascading failures), 그리고 통제 불능 에이전트(rogue agents)가 포함되었습니다. 이 분류 체계는 마치 설계도처럼 자리 잡았습니다. 팀들은 마침내 자신들이 이미 두려워하고 있던 것들에 대해 공통된 언어를 갖게 되었습니다.

침해 사고의 비용이 구체화되었습니다. 중앙의 검토 없이 배포된 에이전트인 섀도우 AI(Shadow AI)는 탐지 지연과 노출 범위 산정의 어려움으로 인해 일반적인 사고보다 평균 670,000달러 더 많은 비용을 발생시킵니다. 어떤 AI 에이전트들이 서로 통신하고 있는지에 대해 완전한 가시성(visibility)을 확보한 조직은 24.4%에 불과합니다. 이는 CFO(최고재무책임자)나 이사회가 용납할 수 없는 수준입니다.

프로덕션의 현실

지난달 저는 에이전트를 출시하고 있는 세 곳의 인프라 팀과 이야기를 나누었습니다. 그들 중 누구도 "거버넌스(governance)를 검토 중입니다"라고 말하지 않았습니다. 세 팀 모두 "해야만 하기 때문에 지금 바로 구현하고 있습니다"라고 말했습니다.

그들이 구축하고 있는 내용은 다음과 같습니다:

에이전트별 신원(Identity per agent). 팀 단위가 아니라 에이전트 단위입니다. 이는 에이전트-X가 도구에 접근하려고 할 때, 시스템이 이를 "공유 API 키를 가진 누군가"가 아니라 "에이전트-X"로 인식함을 의미합니다. 에이전트의 행동을 감사(audit)할 수 있습니다. 권한을 취소할 수 있습니다. 그리고 결정을 특정 에이전트와 상관(correlate)시킬 수 있습니다.

호출 계층에서의 도구 허용 목록 (Tool allowlisting at the invocation layer). 에이전트가 query_database에 대한 접근 권한을 가지고 있을 수 있지만, 에이전트가 쿼리를 실행하려고 할 때 시스템은 다음과 같이 검증합니다: "이 특정 쿼리가 허용되는가?" 즉, "이 에이전트가 일반적으로 데이터베이스 접근 권한을 가지고 있는가?"를 묻는 것이 아닙니다. 에이전트는 엣지 케이스 (edge cases)를 찾아내는 데 창의적이기 때문에 이러한 구분은 매우 중요합니다.

실행 샌드박싱 (Execution sandboxing). 에이전트는 무엇이든 시도할 수 있지만, 샌드박스 (sandbox)는 실제로 실행되는 것을 제한합니다. 주요 접근 방식으로는 제한된 파일 시스템 및 네트워크 접근을 포함하는 컨테이너 격리 (container isolation), 속도 제한 (rate limiting) 및 범위 제한 (scope restrictions)을 포함한 API 거버넌스 (API governance), 그리고 프롬프트 인젝션 (prompt injection)을 방지하기 위한 입력값 정화 (input sanitization) 등이 있습니다.

변조 방지 감사 추적 (Tamper-evident audit trails). 감사자에게는 모든 결정에 대한 결정론적이고 강제 가능한 기록이 필요합니다: 어떤 정책이 활성화되어 있었는지, 에이전트가 무엇을 요청했는지, 그리고 왜 허용되거나 거부되었는지에 대한 기록입니다. 이는 규제 산업에서 선택 사항이 아닙니다. 또한 무언가 잘못되었을 때 에이전트가 실제로 무엇을 했는지 이해하고자 하는 모든 팀에게 기본 요건 (table-stakes)이 되고 있습니다.

중대한 행동에 대한 인간 에스컬레이션 (Human escalation for consequential actions). 인간 참여형 (Human-in-the-loop) 체크포인트는 에이전트가 수행하려는 작업을 사람이 검토할 수 있도록 의도적으로 멈추는 지점입니다. 만약 에이전트가 10,000명의 고객에게 메시지를 보내려고 한다면, 그 작업은 검토를 거쳐야 합니다. 만약 결제 기록을 수정하려고 한다면, 그 작업 역시 검토를 거쳐야 합니다. 기준은 에이전트를 "신뢰"하느냐의 여부가 아니라, 영향 범위 (blast radius)에 따라 달라집니다.

이를 생각하는 방법

거버넌스 (Governance)는 에이전트를 상자 안에 가두는 것을 의미하지 않습니다. 이는 에이전트가 생산적일 수 있으면서도, 에이전트가 제대로 작동하지 않았을 때 무슨 일이 일어났는지 설명할 수 있는 시스템을 구축하는 것을 의미합니다.

에이전트 인프라에 대해 던져야 할 세 가지 질문:

1. 아무것도 재배포하지 않고 특정 도구에 대한 에이전트의 접근 권한을 취소할 수 있는가?
만약 대답이 "에이전트 정의를 다시 빌드해야 한다"라면, 당신은 거버넌스를 갖춘 것이 아닙니다. 당신은 단지 배포 아티팩트 (deployment artifact)를 가지고 있을 뿐입니다.

2. 에이전트가 해서는 안 될 행동을 시도할 때, 도구 호출 (tool invocation) 계층에서 차단될 수 있습니까?
만약 답변이 "에이전트가 얼마나 잘 추론하느냐에 달려 있습니다"라면, 당신은 인프라가 아닌 모델에 의존하고 있는 것입니다. 모델은 결국 당신을 실망시킬 것입니다.

3. 완전한 감사 추적 (audit trail)을 제시하며 에이전트가 정확히 무엇을 했고 왜 허용되었는지 설명할 수 있습니까?
만약 답변이 "어딘가에 로그가 있습니다"라면, 당신은 감사 추적을 갖춘 것이 아닙니다. 당신은 사후 분석 (forensics) 자료를 가지고 있을 뿐입니다.

인프라 패턴

프로덕션 팀들은 다음과 같은 아키텍처로 수렴하고 있습니다:

제어 평면 (Control plane) (에이전트 ID, 정책, 세션 관리): 에이전트가 누구인지 정의합니다. 권한을 할당합니다. 런타임 (runtime)에 정책을 집행합니다. 감사 추적을 유지합니다. 인간의 개입 (human escalation)을 처리합니다.

데이터 평면 (Data plane) (도구 호출을 빠르게 라우팅): 승인된 동작을 실행합니다. 결과를 반환합니다. 정책 결정 과정에는 관여하지 않습니다.

제어 평면은 빠를 필요가 없습니다. 무결해야 (bulletproof) 합니다. 데이터 평면은 똑똑할 필요가 없습니다. 신뢰할 수 있어야 합니다.

이러한 분리는 거버넌스와 속도가 서로 상충하는 요구사항을 갖기 때문에 매우 중요합니다. 두 가지를 모두 수행하려는 시스템은 대개 둘 다 제대로 해내지 못합니다.

규모 있는 에이전트 시스템을 구축하고 있다면, 제어 평면은 에이전트별 ID, 규칙 깊이가 포함된 도구 화이트리스트 (allowlisting), 런타임 정책 집행, 인간의 개입, 그리고 감사 로깅 (audit logging)을 처리할 수 있어야 합니다. 대부분의 팀은 이를 임시방편 (ad-hoc)으로 구축합니다. 일부는 이를 위해 설계된 인프라를 사용합니다.

LiteLLM Agent Platform은 이러한 제어 평면 계층을 제공합니다: 멀티 테넌트 격리 (multi-tenant isolation), 에이전트별 ID, 세션 지속성, 에이전트 수준의 정책 집행, 그리고 감사 추적을 지원합니다. 만약 여러 런타임 (OpenCode, Claude Managed Agents, Cursor, 커스텀 등)에 걸쳐 에이전트를 실행하고 있다면, 런타임 간의 차이를 추상화하는 중앙 집중식 거버넌스가 필요합니다.

향후 전망

2026년 8월 2일은 EU AI Act 준수를 위한 최종 마감일입니다. 지금부터 그때까지 금융, 의료, 정부와 같은 규제 산업의 팀들은 거버넌스를 빠르게 구현하고 있습니다.

규제 산업 외의 팀들에게 비즈니스 케이스는 더 단순합니다. 비즈니스 가치를 창출하는 에이전트를 원하십니까, 아니면 설명할 수 없는 사고(incidents)를 일으키는 에이전트를 원하십니까?

좋은 소식은 거버넌스 인프라(governance infrastructure)가 필수 요건(table-stakes)이 되고 있다는 점입니다. 나쁜 소식은, 그것이 바로 지금 필수 요건이 되고 있다는 점입니다.

만약 위 세 가지 질문에 대한 명확한 답변 없이 에이전트를 출시하고 있다면, 거기서부터 시작하십시오. 인프라는 그 뒤를 따를 것입니다.