Your Agent Is a Lethal Trifecta (And What to Do About It) — Kim Maida, Keycard

한 줄 핵심

에이전트가 유용하려면 광범위한 데이터·도구 접근이 필요하지만, 그 조합은 치명적인 보안 위험을 만들므로 토큰 교환과 정책 기반 위임으로 작업 단위 접근을 강제해야 한다.

시간별 요약

1. 0:00
   과도한 권한을 가진 온콜 에이전트 사고 분류 에이전트가 티켓, 고객 데이터 웨어하우스, 청구 DB, 클라우드 호스팅 API에 모두 접근하면서 개인정보 유출, 무분별한 복구 작업, 인증서 갱신까지 수행하는 데모를 보여준다. 유용한 에이전트가 실제로 얼마나 쉽게 과권한 상태가 되는지 드러낸다.
2. 2:32
   데이터베이스 삭제, 재시작과 스케일링 장애 복구 절차를 이유로 프로덕션 DB를 drop and restore 하거나, 메인 서버를 재시작하거나, 4개 pod를 40개로 스케일링하는 시나리오를 통해 과권한 에이전트의 파괴력을 강조한다. 잘못된 자동화는 서비스 중단과 높은 비용 청구로 바로 이어진다.
3. 4:16
   치명적인 삼중 조건 에이전트의 유용성은 사적 데이터 읽기, 신뢰할 수 없는 콘텐츠 처리, 외부 시스템과의 통신이라는 세 가지 능력에서 나오지만, 이 조합이 바로 공격 표면을 크게 넓힌다. 인간 승인에만 의존하면 권한 문제를 사용자에게 떠넘길 뿐이라 근본 해결이 되지 않는다.
4. 6:21
   접근 제어와 상시 자격 증명 기능을 빼는 대신 접근을 제어해야 하지만, OOTH, MCP gateway, sandbox만으로는 작업별로 좁혀진 런타임 자격 증명을 만들지 못한다. 각 방식은 권한 범위나 실행 범위를 일부 줄이지만, 결국 작업 하나에만 묶인 임시 권한까지는 보장하지 못한다.
5. 8:43
   누락된 신원과 토큰 교환 데모의 핵심 문제는 누가 어떤 API key를 썼는지 감사 추적이 안 되고, 권한이 사용자나 에이전트 신원에 연결되지 않았다는 점이다. token exchange와 OAuth 2 기반 권한 위임을 통해 먼저 사용자 신원을 확인하고, 일부 scope만 에이전트에 위임하는 흐름이 필요하다.
6. 10:25
   에이전트와 MCP 실행 경로 따라가기 사용자 인증, agent runtime, LLM, MCP client/server, downstream resource API로 이어지는 실행 경로를 분해해, 정적 API key로 직접 호출하던 구조를 중간 MCP server가 중계하는 구조로 바꾼다. 이 구조에서는 모델의 tool call이 각 단계에서 다시 검증되고, 한 요청이 여러 번 반복되는 에이전트 루프가 명확해진다.
7. 12:18
   주체 토큰과 보안 토큰 서비스 인증된 사용자의 토큰은 subject token이 되어 에이전트가 누구를 대신하는지 표현하고, runtime은 security token service(STS)와 token exchange를 통해 작업별 접근 권한을 요청한다. 정책은 사용자, 에이전트, 요청 자원과 권한의 관계를 평가하지만, 허용된 범위 안에서도 의도치 않은 행동은 여전히 남을 수 있다.
8. 14:11
   의도 기반 인가 제안 Intent-based authorization(IBA)은 에이전트가 행동하기 전에 목표와 허용 행동, 제한을 먼저 명시하게 만드는 접근이다. 미션 ID를 도구 호출에 붙이고 gateway와 STS가 그 미션과 실제 호출이 일치하는지 확인하면, 작업 범위 밖 행동을 더 강하게 막을 수 있다.
9. 16:05
   임시 자격 증명과 위임 체인 STS가 발급하는 토큰은 몇 분 안에 만료되는 ephemeral credential이어야 하며 저장해서는 안 된다. MCP server가 downstream resource용 토큰을 다시 교환받아 사용하고 즉시 폐기하는 방식으로, 사용자부터 리소스까지 이어지는 delegation chain 전체를 추적 가능하게 만든다.
10. 17:37
    작업 기반 정책으로 데모 다시 보기 같은 온콜 데모를 다시 실행하되, 이제는 로그인·동의·정책 평가·STS 발급을 거치는 구조로 바뀐다. 감사 로그는 누구가 어떤 권한으로 어떤 요청을 했는지 보여주며, 에이전트의 행동은 더 이상 정적 키가 아니라 위임된 작업 단위 권한에 의해 결정된다.
11. 20:01
    데이터 접근, 갱신과 삭제 결정 고객 PII가 포함된 웨어하우스 조회는 정책상 거부되어 에이전트가 고객 데이터를 보지 못한 채 티켓을 에스컬레이션한다. 반면 인증서 갱신은 허용되고, 프로덕션 DB 삭제는 인간이 직접 해야 하므로 STS가 토큰 발급을 거절한다.
12. 22:28
    사용자 권한에 묶인 승인 서버 재시작처럼 사용자가 승인 버튼을 눌러도, 그 사용자의 역할이 부족하면 정책이 최종적으로 차단한다. 반대로 스케일 아웃처럼 역할이 허용하는 작업은 승인 후 수행되며, 에이전트·사용자·정책이 모두 일치할 때만 작업이 실행된다.

실무 인사이트

• 에이전트 보안은 프롬프트를 잘 쓰는 문제가 아니라, 작업별로 최소 권한을 발급하고 즉시 폐기하는 자격 증명 설계 문제로 봐야 한다.
• 감사 로그에 사용자·에이전트·미션·토큰 교환 경로가 모두 남아야 사고 대응과 책임 추적이 가능하다.
• 인간 승인만으로는 충분하지 않으므로, 승인 UI는 반드시 정책 엔진과 연결되어 실제 권한이 없으면 실행되지 않게 해야 한다.