배경 및 맥락
엔터프라이즈 환경에서 agent가 실제 업무를 수행하려면 사용자를 대신해 외부 SaaS나 내부 시스템에 접근해야 한다. 문제는 대부분의 초기 구현이 장기 API 키나 공유 서비스 계정을 중심으로 설계돼, 사용자의 실제 동의 범위와 agent 행동 사이의 연결이 약하다는 점이다. 이 구조에서는 누가 어떤 권한으로 어떤 행동을 유발했는지 추적하기 어렵고, 사고가 나면 과도한 권한이 그대로 노출된다.
AWS의 이번 글은 agent 보안을 단순 비밀정보 저장 문제가 아니라 사용자 위임 흐름 전체의 설계 문제로 다룬다. 특히 self-hosted ECS 환경에서도 session binding과 scoped token을 조합해 사용자 인증, 동의, agent action 사이의 체인을 보존하는 방법을 구체화했다.
핵심 내용
이 참조 구현은 Authorization Code Grant를 기반으로 Agentic Workload와 Session Binding Service를 분리하고, Application Load Balancer의 OIDC 인증과 x-amzn-oidc-data 헤더를 사용해 사용자 identity를 연결한다. AgentCore Identity는 workload access token과 token vault를 통해 OAuth access token을 보관하고, 세션마다 사용자 동의를 반영한 scoped token을 agent에 전달한다. AWS는 이 구조가 CSRF와 browser-swapping attack을 막고, user session별 least privilege를 유지하며, GitHub 같은 외부 서비스 접근을 감사 가능하게 만든다고 설명한다.
경쟁 구도 / 비교
기존 agent 연동은 "도구를 빨리 붙이는 것"에 초점이 있어 공용 credential이나 광범위한 app token으로 우회하는 경우가 많았다. 반면 이번 접근은 agent가 사람을 대신할수록 identity boundary를 더 엄격하게 설계해야 한다는 방향이다. 즉 경쟁 포인트가 tool calling 지원 여부에서 delegated authorization 품질과 감사 체계로 이동하고 있다.
의미
산업적으로는 enterprise agent 도입이 프롬프트 엔지니어링 단계를 지나 IAM과 OAuth 아키텍처 문제로 진입하고 있다는 신호다. 실무적으로는 agent 플랫폼 팀이 session binding endpoint, callback 분리, token scope, 사용자별 action trace를 표준 설계 항목으로 가져가야 한다. 앞으로 안전한 agent는 많이 할 수 있는 agent가 아니라, 정확한 사용자 위임 안에서만 행동하는 agent가 될 가능성이 높다.