EPFL과 Swisscom의 공동 노력으로 탄생한 CAPMAS는 개발자가 macaroon을 통해 AI 자식 에이전트(child agents)에게 좁게 범위가 지정된 권한을 부여할 수 있게 합니다. 이는 토큰 처리 지연 시간을 30배 단축하며, 전체 사용자 JWT가 에이전트의 손에 들어가지 않도록 차단합니다.
변화가 중요한 이유
LLM이 다운스트림 도구를 오케스트레이션할 때, 팀들은 종종 생성된 "자식" 에이전트에 사용자가 로그인할 때 사용한 것과 동일한 JWT를 넘겨줍니다. JWT는 인사 데이터, 프로젝트 파일, 관리자 권한 등 사용자가 보유한 모든 권한을 나열하는 서명된 블롭(blob)입니다. 만약 모델이 파괴적인 명령을 환각(hallucinate)해낸다면, 자식 에이전트는 사용자의 모든 권한을 사용하여 이를 실행할 수 있습니다. 단 한 번의 실수가 조직 전체의 데이터를 노출시킬 수 있습니다.
현재 우회 방식의 단점
RFC 8693 토큰 교환(token-exchange) 흐름을 사용하여 필요할 때마다 좁은 범위의 토큰을 발행(minting)하면, IAM 시스템에 여러 번의 라운드 트립(round-trip)이 추가되고 네트워크 트래픽이 증가하며 눈에 띄는 지연 시간이 발생합니다. 수많은 단기 에이전트를 생성하는 팀은 이러한 오버헤드가 치명적이라는 것을 곧 깨닫게 됩니다.
CAPMAS 작동 방식
CAPMAS는 권한 부여를 두 단계로 나눕니다:
- IAM 측 인코딩 – IAM 서비스는 자연어 요청(예: "재무 폴더의 파일 목록 표시")을 일치하는 권한 세트로 변환하는 인코더를 실행합니다.
- Macaroon 생성 – 해당 권한은 macaroon 내부의 caveats(제약 조건)가 됩니다. macaroon은 다운스트림 에이전트가 추가적인 제한 사항을 더할 수는 있지만, 기존의 제한 사항을 제거할 수는 없게 만드는 유연한 토큰 형식입니다.
에이전트가 macaroon을 받으면 범위를 더 좁힐 수는 있지만(예: 파일 목록 요청을 특정 하위 디렉터리로 제한), 범위를 넓힐 수는 없습니다. 각 단계(hop)마다 IAM 서비스는 모든 caveats의 교집합을 검증하여, 어떤 에이전트도 원래 허용된 범위를 초과하지 않도록 보장합니다.
성능 수치로 증명되는 결과
- 속도 – CAPMAS는 권한 요청을 20ms 미만으로 처리하며, 이는 RFC 8693 교환 방식보다 약 30배 빠릅니다.
- 정확도 – 방대한 도구 카탈로그를 대상으로 한 벤치마크에서, 표준 LLM은 필요한 권한의 53%를 놓쳤습니다. 반면 CAPMAS는 단 2.1%의 누락률로 90.9%의 정확도를 달성했습니다.
- 대역폭 – macaroon은 최종적인 caveats 세트만 포함하므로, 교환되는 데이터 양은 전체 토큰 교환 흐름이 필요로 하는 양의 극히 일부에 불과합니다.
실용적인 도입 워크플로우
- 요청 사전 필터링 – 오케스트레이터가 도구 카탈로그에 접근하기 전에 사용자의 자연어 의도를 top-k 허용 목록(allowlist)으로 변환합니다.
- 허용 목록 봉인 – 해당 허용 목록을 자식 에이전트가 확장할 수 없는 macaroon으로 인코딩합니다.
- 서비스 단계에서 검증 – 대상 서비스가 요청을 수락하기 전에 IAM에 모든 caveats의 교집합을 계산하도록 요청하게 합니다.
이러한 단계들은 "자식에게 집 전체 열쇠를 주는" 패턴을 "일회용이며 범위가 제한된 열쇠를 건네주는" 모델로 대체합니다.
CAPMAS가 해결하지 못하는 것
이 프레임워크는 공격자가 LLM의 프롬프트를 조작하여 악성 명령을 주입하는 프롬프트 인젝션(prompt-injection) 공격을 막지는 못합니다. CAPMAS의 보호 기능은 정직하지만 호기심이 많은(honest-but-curious) 에이전트와, 그렇지 않으면 전체 JWT를 기반으로 동작할 수 있는 신뢰할 수 없는 LLM을 대상으로 합니다. 팀은 프롬프트 기반 위협에 대응하기 위해 입력값 정제(input sanitisation), 샌드박싱(sandboxing) 또는 모델 수준의 가드레일(guardrails)과 같은 별도의 방어책이 여전히 필요합니다.
수혜 대상
- 엔터프라이즈 개발자: 내부 API를 호출하는 AI 기반 어시스턴트를 구축하는 개발자.
- 보안 팀: 침해된 모델의 피해 범위(blast radius)를 줄이고자 하는 팀.
- 제품 소유자(Product owners): 빈번한 에이전트 생성에 대해 빠르고 신뢰할 수 있는 권한 확인이 필요한 담당자.
향후 계획
CAPMAS는 제안된 설계안입니다.
요약: 전체 사용자 JWT를 좁은 범위의 macaroon으로 교체하면, 개발자는 전통적인 토큰 교환 흐름의 지연 시간 페널티를 감수하지 않고도 AI 에이전트의 정직성을 유지할 수 있는 방법을 얻게 됩니다. 다만, 프롬프트 인젝션 방어책이 계속해서 필요하다는 점은 여전한 트레이드오프(trade-off)로 남습니다.