AI 에이전트 authorization은 “이 에이전트가 지금 이 도구로 이 리소스에 이 작업을 수행해도 되는가?”에 답한다. Authentication은 신원을 확인하지만 authorization은 목적, 범위, 데이터 민감도, 세션 상태, 각 tool call의 위험을 함께 평가해야 한다.

기존 애플리케이션 역할만으로 부족한 이유

일반 애플리케이션의 흐름은 미리 설계되어 있다. 에이전트는 스스로 도구를 선택하고 작업 순서를 만들며 중간 결과에 따라 계획을 바꾼다. “이메일 사용” 또는 “데이터베이스 접근” 같은 넓은 권한은 어떤 메일함, 수신자, 테이블, 필드, 레코드 수가 허용되는지 설명하지 못한다.

Authorization 경계는 도구 실행 직전에 있어야 한다. 에이전트는 작업을 제안할 수 있지만 별도의 policy enforcement point가 허용, 거부, 파라미터 축소, 승인 요청을 결정해야 한다.

정책 결정에 필요한 네 가지 입력

• Principal: 권한을 위임한 사용자, 서비스 계정 또는 워크로드.
• Action: 읽기, 생성, 전송, 변경, 삭제, 실행 같은 정확한 작업.
• Resource: 대상 tenant, project, repository, dataset, record 또는 수신자.
• Context: 세션 목적, 요청 출처, 민감도, 환경, 시간, 이전 단계의 결과.

에이전트 authorization 아키텍처

각 도구는 입력 스키마, 상태 변경 작업, 리소스 경계를 공개해야 한다. 실행 전에 에이전트는 표준화된 요청을 policy decision point로 보낸다. 응답은 단순 allow/deny 외에도 레코드 수 제한, 민감 필드 제거, 읽기 전용 전환, 사람의 확인 요청을 포함할 수 있다.

Credential을 모델 context에 직접 넣어서는 안 된다. Broker가 자격 증명을 보관하고 정책 승인 후 짧은 수명의 제한된 token만 발급하면 secret이 prompt, log, output에 나타날 가능성을 줄일 수 있다.

위험에 따른 승인 적용

모든 호출에 사람이 필요한 것은 아니다. 공개 문서 읽기는 자동 처리할 수 있고 내부 데이터는 scope 검사가 필요하다. 대량 메시지, production 변경, 금융 작업은 강화 인증과 명시적 승인이 필요하다. 정책은 잠재적 영향, 되돌릴 수 있는 정도, context의 신뢰도를 반영해야 한다.

감사와 설명 가능성

Principal, policy version, tool, 정제된 parameter, 대상 resource, 결정, 승인자, 결과, correlation ID를 기록한다. 원본 secret이나 불필요한 민감 데이터는 저장하지 않는다. 로그는 행동 체인을 재구성할 수 있어야 하지만 새로운 유출원이 되어서는 안 된다.

구현 체크리스트

1. 모든 도구를 조사하고 read, write, destructive 작업으로 분류한다.
2. 에이전트 권한은 사용자의 기존 권한에서 파생하며 암묵적 권한을 만들지 않는다.
3. 정책 집행을 모델과 조작 가능한 prompt 밖에 둔다.
4. Audience, scope, 시간에 묶인 단기 credential을 사용한다.
5. 고위험 행동은 승인받고 에이전트가 수행할 내용을 정확히 보여준다.
6. Prompt injection, confused deputy, replay, 다중 도구 권한 상승을 테스트한다.

좋은 설계는 에이전트의 의도가 선한지 추측하지 않는다. 실제 시스템에 도달하기 전에 모든 제안된 행동이 감사 가능한 정책 검사를 통과하도록 만든다.