모든 AI 에이전트 프로젝트에는 이런 순간이 있습니다: 데모가 완벽하게 작동하고, 에이전트가 자연어를 해석하고, 올바른 API를 호출하고, 올바른 데이터를 반환합니다. 그런 다음 실제 사용자에 대해 생각하기 시작합니다.
한 사용자의 에이전트 세션이 다른 사용자의 데이터를 보는 것을 무엇이 막을까요? 에이전트가 프롬프트 인젝션으로 속임을 당하면 어떻게 될까요? 예상치 못한 방법으로 도구를 호출하면 어떻게 될까요?
이것들은 엣지 케이스가 아닙니다. 이것들은 출시 전에 해야 할 설계 결정입니다.
Curity와 Microsoft의 새로운 azd 템플릿은 정확히 이 문제에 대한 작동하는 참조를 제공합니다.
핵심 문제: 인증 ≠ 인가
대부분의 에이전트 샘플은 사용자 인증을 잘 처리합니다. 인가는 잘 처리하지 못합니다. 사용자가 누구인지 아는 것이 그들이 봐야 할 데이터가 무엇인지 알려주지는 않습니다.
전통적인 클라이언트 앱은 예측 가능한 API 호출을 합니다. AI 에이전트는 비결정론적입니다 — 자연어를 해석하고 무엇을 호출할지 결정합니다. 창의적일 수 있습니다. 틀릴 수도 있습니다. 프롬프트 인젝션으로 조작되는 경우, AI가 잘 동작하는 것에 의존하지 않는 규칙이 필요합니다.
이 템플릿이 보여주는 해결책: 각 홉에 정확히 올바른 정보를 전달하는 단기 토큰.
토큰 체인 작동 방식
템플릿은 OAuth 2.0 액세스 토큰과 토큰 교환을 사용하여 각 단계에서 권한을 좁힙니다. 사용자 토큰은 MCP 서버에 도달하기 전에 두 번 교환됩니다:
- 첫 번째 교환 — 스코프를 좁히고 불투명한 토큰을 JWT로 변환
- 두 번째 교환 — 에이전트 신원과 MCP 서버 홉을 위한 새 오디언스 추가
MCP 서버 토큰이 어떻게 보이는지:
{
"scope": "stocks/read",
"sub": "62c839b8...",
"aud": "https://mcp.demo.example",
"customer_id": "178",
"region": "USA"
}
customer_id는 에이전트가 제어하는 매개변수로 전달되는 것이 아니라 인가 서버에 의해 토큰에 내장됩니다. API는 에이전트의 지시가 아닌 토큰을 확인합니다.
이것이 의미하는 것: 누군가가 에이전트를 속여 다른 고객의 데이터를 가져오려 해도, 토큰이 이를 인가하지 않습니다.
템플릿이 배포하는 것
몇 가지 azd 명령으로 다음을 얻습니다:
- Microsoft Foundry의 백엔드 에이전트 (C#, Microsoft A2A 및 MCP SDK)
- 샘플 포트폴리오 API를 노출하는 MCP 서버
- 인증을 위한 Entra ID와 함께 인가 서버로 Curity Identity Server
- 토큰 교환 및 감사 로깅을 처리하는 외부 및 내부 API 게이트웨이
- 모든 Azure 인프라를 위한 Bicep: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, 스토리지
전체 패턴은 검사 가능하고 사용자 정의 가능합니다.
빌려올 가치 있는 설계 원칙
Curity를 사용하지 않더라도 패턴은 이전 가능합니다: 에이전트는 절대 영구적인 API 액세스를 가져서는 안 됩니다. 모든 작업은 해당 특정 호출에 필요한 최소 스코프를 가진 단기 토큰을 사용하고, 특정 에이전트 신원에 발급되며, API가 인가 결정을 내리는 데 필요한 클레임을 전달해야 합니다.
이것은 “에이전트가 나쁜 일을 하지 않도록 그냥 확인하세요"가 절대 견딜 수 없는 방식으로 창의적인 에이전트, 실수, 프롬프트 인젝션에 대해 견딥니다.
결론
AI 에이전트를 위한 보안 패턴은 여전히 업계 전반에 걸쳐 정리되고 있습니다. 이 템플릿은 내가 본 가장 완전한 참조 구현 중 하나입니다 — 인증만이 아니라 실제 인가 흐름을 다룹니다.
원본 게시물: Least privilege AI agents: A new azd template from Curity and Microsoft
