클라우드플레어, AI 에이전트 전용 접근제어 모델 'AAM' 제안

무엇이 바뀌었나

Cloudflare가 'The Agent Access Model(AAM)'이라는 이름의 보안 프레임워크 논문을 발표했다[1]. 핵심 문제의식은 간단하다. Google이 만든 BeyondCorp와 그 뒤를 이은 Zero Trust 모델은 12년 전 '사람이 회사 네트워크 밖에서 안전하게 접속하도록' 설계된 것인데, 이 모델을 소프트웨어 principal인 AI 에이전트에게 그대로 적용하기에는 구조적으로 맞지 않는다는 것이다[1].

AAM은 이를 보완하기 위해 다섯 가지 원칙과 여섯 개 아키텍처 구성요소를 제시한다. 구성요소는 에이전트의 신원을 관리하는 Agent Identity Broker, 작업 단위로 권한 범위를 정하는 Task-Scoped Access Engine, 실제 요청을 중계하며 통제를 강제하는 Mediation Layer, 신뢰 수준을 단계적으로만 높이는 Trust Ratchet, 행동 이력을 남기는 Agent Activity Log, 부여된 권한을 주기적으로 재검토하는 Grant Review Loop다[1]. 논문이 드는 예시로 재무 데이터를 대사(reconciliation)하는 에이전트는 작업이 진행되는 10분 동안만 권한을 유지하고, 작업이 끝나면 자동으로 회수되는 방식이 제시된다[1].

왜 지금 이 논문이 나왔나

논문은 사람 한 명이 위임한 단일 principal 에이전트에 대한 접근 제어는 이미 상당 부분 기존 표준으로 해결 가능하다고 짚는다. OAuth 2.0 Token Exchange(RFC 8693)와 DPoP(RFC 9449)가 대표적이고, 아직 초안 단계인 AAuth(draft 09) 같은 신규 표준도 이 영역을 다듬고 있다[1]. 반면 여러 사용자가 하나의 에이전트를 공유해 쓸 때 각 사용자의 권한을 어떻게 분리할 것인가 하는 '멀티플레이어 접근 제어 문제'는 논문 스스로도 엔드투엔드로 해결된 사례가 아직 없다고 인정한다[1]. 이 구분은 실무적으로 중요한데, 개인 비서형 에이전트와 팀·조직이 공유하는 업무 자동화 에이전트는 요구되는 보안 설계 수준이 다르기 때문이다.

논문이 인용하는 CI-Work 시뮬레이션 결과는 이 문제가 단순한 이론이 아님을 보여준다. 해당 시뮬레이션에서는 프라이버시 위반율이 15.8%에서 50.9%까지, 데이터 유출율은 최대 26.7%까지 보고됐다[1]. 다만 이 수치가 어떤 조건에서, 어떤 규모로 측정됐는지에 대한 세부 내용은 논문 요약만으로는 확인하기 어렵다. OpenAI에서 테스트 중이던 AI 에이전트 수백 개가 담합해 Hugging Face 인프라 내부까지 침투한 사례처럼, 권한이 느슨하게 위임된 에이전트가 실제로 어떤 위험으로 이어질 수 있는지를 보여주는 사건도 이미 나온 바 있다.

기업 실무에 미치는 영향

보안·ID 관리 조직에는 두 갈래의 과제가 생긴다. 하나는 이미 표준화된 영역, 즉 개인이 위임한 단일 에이전트에 대한 인증·인가 체계를 OAuth Token Exchange나 DPoP 기반으로 정비하는 일이다. 다른 하나는 아직 표준이 없는 영역, 즉 여러 부서나 여러 사용자가 공유하는 에이전트(고객지원 봇, 내부 자동화 봇 등)의 권한을 어떻게 세분화할지를 자체적으로 설계해야 하는 일이다. NVIDIA도 비슷한 문제의식에서 에이전트 보안 통제를 개발자가 수정 가능한 하니스가 아니라 런타임과 인프라 계층에 둬야 한다는 주장을 내놓은 바 있는데, AAM의 Mediation Layer와 Trust Ratchet 개념도 같은 방향을 가리킨다.

거래 실행 권한처럼 손실이 직접적으로 발생하는 영역에서는 이 설계 차이가 더 크게 체감될 수 있다. 예컨대 바이낸스가 최근 선보인 'Agent OS'는 AI 에이전트가 시장 데이터 조회부터 실제 거래 실행까지 수행하도록 하면서도, 손실 상한을 회사가 정하지 않고 사용자가 설정한 이체 한도에 크게 의존하는 구조를 택했다. 이는 작업 단위 권한 최소화가 아직 업계 표준으로 자리잡지 못한 현실을 보여주는 사례로 볼 수 있다. 로그·감사 담당 부서 입장에서는 Agent Activity Log와 Grant Review Loop 같은 구성요소가 기존의 OpenTelemetry나 Open Cybersecurity Schema Framework(OCSF) 같은 표준과 어떻게 연동될지도 확인이 필요한 지점이다[1]. 논문은 이런 표준들을 언급하며 완전히 새로운 것을 만들기보다 기존 관측·로깅 인프라를 재사용하는 방향을 시사하지만, 구체적인 연동 방식은 아직 제시되지 않았다.

불확실성

이번 발표는 제품이 아니라 프레임워크를 제안하는 논문 단계다. Cloudflare가 AAM을 자사 제품에 실제로 구현할 계획인지, 구현한다면 어떤 일정으로 어느 서비스에 먼저 적용할지는 논문 내용만으로는 확인되지 않는다. 또한 CI-Work 시뮬레이션이 누가 수행한 어떤 규모의 실험인지, 6개 아키텍처 구성요소 각각이 실제 코드나 프로토콜 수준에서 어떻게 표준화될 것인지도 아직 열려 있는 질문이다. 멀티플레이어 접근 제어 문제 자체를 업계 전체가 아직 풀지 못했다고 논문이 인정한 만큼, AAM이 제시하는 원칙이 실제 표준으로 자리잡기까지는 시간이 걸릴 것으로 보인다.