AI 에이전트를 위한 플랫폼 API: 신원(Identity), 권한(Permissions) 및 정책 경계(Policy Boundaries)

AI 에이전트에게 내부 API에 대한 접근을 허용하는 것은 그리 어렵지 않습니다. 어려운 부분은 그 에이전트가 그 접근을 이용해 어떤 중대한 행동을 할 수 있느냐부터 시작됩니다. 전통적인 서비스는 명확하게 정의된 워크플로우, 고정된 입력값, 그리고 비교적 예측 가능한 일련의 작업을 가집니다. 하지만 AI 에이전트는 다릅니다. 에이전트는 도구를 동적으로 선택하고, 이전 단계의 정보를 해석하며, 하나의 작업 동안 여러 시스템을 호출할 수 있고, 심지어 인간이 개별적인 모든 작업을 승인하지 않아도 계속 행동을 이어갈 잠재력이 있습니다. 이는 접근 제어(access-control) 문제를 변화시킵니다.

중요한 질문은 더 이상 에이전트가 API를 호출할 권한이 있는지 여부만 아닙니다. 플랫폼은 또한 누가 행동하고 있는지, 에이전트가 무엇을 할 수 있도록 허용되었는지, 왜 그 행동이 수행되는지, 그리고 현재의 상황(context)이 그 행동을 허용하는지를 확립해야 합니다.

NIST의 소프트웨어 및 AI 에이전트 신원(identity)과 권한 부여(authorization)에 대한 현재 작업도 같은 방향으로 나아가고 있습니다. 2026년 9월 업데이트에서는 에이전트에 대한 신원 및 권한 부여를 능동적인 구현 문제로 설명하며, 첫 번째 구현 사용 사례는 소프트웨어 개발에서 AI 에이전트를 식별(identifying), 인증(authenticating), 그리고 권한을 부여하는 데 초점을 맞추고 있습니다. 플랫폼 팀에게 이것은 AI 에이전트가 성공적으로 인증할 수 있다는 이유만으로 프로덕션 시스템에 직접적이고 무제한적인 접근을 받아야 한다는 의미는 아닙니다.

인증(Authentication)은 문제의 일부만을 해결한다

인증은 신원(identity)을 확립합니다. 하지만 권한(authority)을 확립하지는 않습니다. 예를 들어, 에이전트가 Kubernetes에서 워크로드로 실행되며 서비스 신원(service identity)을 받는다고 가정해 봅시다. 그 신원은 어떤 워크로드가 API 요청을 하는지 확인하는 데 유용할 수 있지만, 그 워크로드가 할 수 있는 모든 것을 자동으로 결정해서는 안 됩니다.

이러한 구분은 기존의 인프라에서도 이미 존재합니다. Kubernetes는 인증(authentication)과 권한 부여(authorization)를 분리하며, 그 권한 부여 계층은 RBAC와 같은 정책에 따라 요청을 평가할 수 있습니다. Role 또는 ClusterRole은 권한을 정의하고, Binding이 그 권한을 주체(subject)에 연결합니다. 이러한 기본적인 분리는 주체가 AI 에이전트인 경우에도 중요해집니다.

에이전트의 경우, 신원 모델은 정적인 서비스 계정보다 더 많은 컨텍스트가 필요할 수 있습니다:

• 어떤 에이전트 또는 워크로드가 실행되는지
• 어떤 조직 또는 애플리케이션이 이를 소유하는지
• 어떤 사용자가 작업을 시작했는지
• 현재 어떤 작업이 수행되고 있는지
• 에이전트에게 어떤 권한이 위임되었는지
• 그 권한이 얼마나 오랫동안 유효한지

NIST의 에이전트 신원(agent-identity) 관련 연구는 특히 일시적 신원(ephemeral identity), 위임된 권한(delegated authority), 에이전트 신원을 인간의 신원에 바인딩하는 것, 그리고 에이전트가 특정 작업을 수행할 권한이 있음을 증명하는 것에 대한 질문을 제기합니다. 이는 유용한 설계 시그널입니다: 에이전트 신원을 영구적인 권한 집합으로 취급하기보다 실행 컨텍스트의 일부로 다루어야 합니다.

무제한 접근이 아닌, 기능(capabilities)을 중심으로 API를 설계하라

흔히 저지르는 실수는 기존 내부 API를 수정 없이 에이전트에게 노출하는 것입니다.

예를 들어, 내부 시스템이 다음 기능을 노출한다고 가정해 봅시다:
GET /customers/{id}
POST /customers/{id}/notes
PATCH /customers/{id}
DELETE /customers/{id}

고객 정보를 조회할 필요만 있는 에이전트가 네 가지 작업 모두를 수행할 수 있는 자격 증명을 자동으로 받아서는 안 됩니다. 이는 보안 분야에서 사용되는 최소 권한 원칙(least-privilege principle)과 동일하지만, 에이전트는 소프트웨어가 실행 중 어떤 도구를 호출할지 결정할 수 있기 때문에 그 결과가 더 눈에 띄게 나타납니다.

OWASP의 과도한 대리권(excessive agency) 관련 지침은 과도한 권한, 과도한 기능, 그리고 과도한 자율성을 중요한 위험 요소로 식별합니다. 한 가지 예는 애플리케이션이 읽기 전용 접근만 필요할 때 수정 또는 삭제 기능을 노출하는 것입니다.

플랫폼 API는 따라서 작업에 맞는 수준에서 기능을 노출해야 합니다. 에이전트에게 고객 관리 시스템에 대한 광범위한 접근 권한을 부여하는 대신, 플랫폼은 다음과 같이 의도적으로 제한된 기능(capability)을 노출할 수 있습니다.
{
"operation": "read_customer",
"customer_id": "12345"
}

중요한 부분은 JSON 자체가 아닙니다. 중요한 것은 그 경계(boundary)를 플랫폼이 소유한다는 점입니다. 에이전트는 작업을 요청할 수 있지만, 기반 시스템이 모든 가능한 작업을 에이전트에게 노출해야 하는 것은 아닙니다.

권한은 엔드포인트뿐만 아니라 컨텍스트를 설명해야 한다

에이전트가 다단계 작업(multi-step work)을 수행할 때 정적 권한(Static permissions)은 덜 유용해집니다. 프로덕션 인시던트를 조사하도록 요청받은 에이전트를 생각해 보세요. 이 에이전트는 로그를 읽고, 배포 메타데이터를 검사하고, 메트릭을 조회하며, 최근 구성 변경 사항을 검색해야 할 수 있습니다. 이러한 작업들은 배포 재시작, 구성 변경 또는 리소스 삭제와는 다릅니다.

따라서 유용한 권한 부여 모델(authorization model)은 읽기 접근(read access), 진단 작업(diagnostic actions), 그리고 상태 변경 작업(state-changing operations)을 구분할 수 있어야 합니다.

예를 들어:
인시던트 조사
로그 읽기 허용
메트릭 읽기 허용
배포 상태 읽기 허용
배포 재시작은 승인 필요
구성 변경 거부
리소스 삭제 거부

정확한 구현 방식은 조직마다 다를 것이지만, 원칙은 간단합니다. 권한 부여는 에이전트 자격 증명(credential)을 무차별적인 권한으로 취급하는 대신, 작업과 그 컨텍스트를 고려해야 합니다. NIST의 현재 에이전트 권한 부여 작업(agent-authorization work)은 동적으로 업데이트되는 권한 정책(dynamically updated authorization policies), 최소 권한 원칙(least privilege), 작업 의존적 권한(task-dependent authority), 그리고 위임된 권한 부여(delegated authorization)를 명시적으로 고려합니다.

이는 또한 에이전트의 행동이 실행 중에 변경될 때도 도움이 됩니다. 문제를 조사하기 시작한 에이전트가 단순히 수정이 문제를 해결할 수 있다는 것을 발견했다는 이유만으로 시스템을 수정할 권한을 자동으로 상속받아서는 안 됩니다.

위험도가 낮은 작업과 영향력이 큰 변경을 분리하기

모든 에이전트의 행동이 동일한 제어 경로를 가질 필요는 없습니다. 원격 측정(telemetry) 데이터를 읽는 것과 프로덕션 구성을 변경하는 것은 다릅니다. 초안을 작성하는 것과 외부 메시지를 보내는 것은 다릅니다. 데이터베이스 마이그레이션을 준비하는 것과 실행하는 것은 다릅니다.

이러한 모든 작업에 하나의 권한 모델을 적용하려고 하면 보통 두 가지 문제 중 하나가 발생합니다. 에이전트에게 너무 많은 권한을 부여하거나, 워크플로우가 너무 제한적이어서 자동화의 효용성이 거의 없는 경우입니다.

더 나은 접근 방식은 작업을 그 결과에 따라 분류하는 것입니다. 읽기 작업(Read operations)은 종종 일반적인 승인(authorization)을 통해 처리할 수 있습니다. 위험도가 낮은 변경(Low-risk mutations)은 좁게 범위가 지정된 권한을 사용할 수 있습니다. 영향력이 큰 변경(High-impact mutations)은 추가적인 승인 단계나 더 강력한 승인 컨텍스트를 요구할 수 있습니다.

예를 들어, 에이전트는 배포 변경을 준비하는 것은 허용되지만 실행하는 것은 허용되지 않을 수 있습니다:

{
"action": "production_deployment",
"prepare": true,
"execute": false,
"approval_required": true
}

플랫폼은 모델이 승인이 필요한지 여부를 결정할 것이라고 신뢰할 필요가 없습니다. 정책 계층(policy layer)은 모델의 추론과 독립적으로 그 결정을 내릴 수 있습니다.

이러한 구분이 중요한 이유는 모델의 출력이 승인 메커니즘이 아니기 때문입니다. 에이전트는 프로덕션 변경이 왜 이루어져야 하는지에 대해 완벽하게 합리적인 설명을 생성할 수 있지만, 여전히 해당 변경을 수행할 권한이 없을 수도 있습니다.

사람의 승인은 모든 것의 기본(fallback)이 아니라 제어 지점(control point)이어야 합니다

모든 에이전트 작업에 사람의 승인 단계를 추가하는 것은 안전하게 들리지만, 자동화의 가치를 빠르게 많이 제거합니다.

더 나은 질문은 실제로 인간의 권한이 필요한 작업이 무엇인가 하는 것입니다. 유용한 승인 시스템은 검토자가 무엇을 승인하고 있는지 이해할 수 있을 만큼 충분한 컨텍스트를 보존해야 합니다.

승인 요청은 대신 다음과 같은 정보(information)를 포함해야 합니다:
{
"requested_action": "update_deployment",
"target": "payments-api",
"environment": "production",
"reason": "지속적인 요청 포화 상태 이후 복제본 증가",
"proposed_change": {
"replicas": 8
}
}
이 경우 검토자(reviewer)는 에이전트에게 무제한의 권한을 부여하는 대신 특정 대상을 향한 구체적인 작업(operation)을 승인하게 됩니다.

이는 또한 더 깔끔한 감사 추적(audit trail)을 만듭니다. 시스템은 어떤 신원(identity)이 작업을 요청했고, 어떤 사람이 이를 승인했으며, 어떤 정책이 평가되었고, 궁극적으로 어떤 작업이 발생했는지 기록할 수 있습니다. NIST의 현재 작업은 신원 및 권한 문제(identity and authorization problem)의 일부로 감사(auditing), 부인 방지(non-repudiation), 그리고 에이전트 작업을 인간의 승인에 연결하는 것을 명시적으로 포함합니다.

토큰은 제한된 권한을 가져야 한다

에이전트에게 발급되는 자격 증명(credential)은 영구적인 접근(permanent access)이라기보다는 임시적인 권한으로 취급되어야 합니다. OAuth는 여기서 유용한 개념적 모델을 제공합니다. 액세스 토큰(Access token)은 범위(scope)와 수명 기간(lifetime)에 대한 정보를 포함할 수 있어, 리소스 서버(resource server)가 해당 토큰이 요청된 작업을 승인하는지 여부를 판단할 수 있게 합니다. OAuth 사양은 또한 요청된 작업에 필요한 최소한의 범위로 접근을 제한하는 것을 설명합니다. 에이전트 시스템의 경우에도 동일한 원칙을 작업 실행(task execution)에 적용할 수 있습니다.

내부 플랫폼 전체에 접근할 수 있는 장기 지속형 자격 증명(long-lived credential)을 발급하는 대신, 권한 부여 서비스(authorization service)는 특정 기능(capability)에 제한된 단기 토큰(short-lived token)을 발급할 수 있습니다.
개념적으로:

에이전트 작업 (Agent task)
↓
권한 부여 결정 (Authorization decision)
↓
단기 범위 지정 자격 증명 (Short-lived scoped credential)
↓
특정 플랫폼 기능 (Specific platform capability)

이는 플랫폼 API가 가치 있는 곳 중 하나입니다. 에이전트는 조직의 전체 권한 모델을 이해할 필요가 없습니다. 플랫폼은 에이전트가 요청한 작업을 권한 부여 결정으로 번역하고, 해당 작업에 필요한 권한만을 발급하면 됩니다.

NIST의 토큰 및 어설션(assertions) 보호에 관한 최근 지침은 또한 API 접근 시나리오를 위한 안전한 토큰 검증, 키 관리, 생명주기 제어(lifecycle controls), 그리고 지속적인 모니터링을 강조합니다.

API 호출뿐만 아니라 결정 과정도 감사해야 한다 (Audit the decision, not just the API call)

전통적인 애플리케이션 로그는 종종 다음과 같은 내용을 기록합니다:
POST /deployments/payments-api
user=service-account
status=200

이는 에이전트 기반 시스템에게는 충분하지 않습니다. 에이전트가 여러 입력에 대해 추론하고 동적으로 행동을 선택할 수 있을 때, 플랫폼은 권한 부여 컨텍스트(authorization context)를 재구성하기에 충분한 정보가 필요합니다.

유용한 감사 기록에는 다음과 같은 내용이 포함될 수 있습니다:
{
"agent_id": "incident-agent",
"initiated_by": "user-4821",
"task_id": "incident-9182",
"action": "update_deployment",
"target": "payments-api",
"policy": "production-scaling-v2",
"decision": "approved",
"approved_by": "user-4821",
"timestamp": "..."
}

정확한 스키마는 플랫폼에 따라 달라지겠지만, 원칙은 중요합니다. 단순히 API가 HTTP 200을 반환했다는 사실이 아니라, 왜 해당 행동이 허용되었는지 기록해야 합니다.

이는 무언가 잘못되었을 때 특히 가치가 높아집니다. 만약 에이전트가 예상치 못한 프로덕션 변경을 수행한다면, 조사는 다음 질문에 답할 수 있어야 합니다:

• 어떤 에이전트가 요청을 했는가?
• 어떤 사용자 또는 시스템이 작업을 시작했는가?
• 어떤 기능(capability)이 요청되었는가?
• 요청을 평가한 정책은 무엇인가?
• 당시 활성화된 권한은 무엇이었는가?
• 인간의 승인이 필요한가?
• 승인이 필요했다면, 누가 제공했는가?
• 궁극적으로 어떤 시스템이 작업을 실행했는가?

그러한 컨텍스트 없이는, 에이전트 실패를 디버깅하는 것이 관련 없는 애플리케이션 로그에서 이벤트를 재구성하는 작업이 될 수 있습니다.

플랫폼이 경계(boundary)를 소유해야 한다

가장 중요한 아키텍처 결정은 권한 부여가 어디에 위치하느냐입니다. 만약 모델이 어떤 행동이 안전한지 결정하도록 기대된다면, 제어는 이미 예측 불가능한 동작을 하는 컴포넌트에 너무 가깝습니다.

모델은 행동을 제안할 수 있습니다. 플랫폼은 그 행동이 허용되는지 여부를 결정해야 합니다. 이 플랫폼 계층은 모든 에이전트 구현체가 이러한 메커니즘을 독립적으로 재구축할 필요 없이 신원(identity), 권한 부여(authorization), 정책 평가(policy evaluation), 승인 워크플로우(approval workflows), 속도 제한(rate limits), 감사 로깅(audit logging), 그리고 리소스별 제어(resource-specific controls)를 결합할 수 있습니다.

이것이 에이전트가 정보 생성에서 행동 수행으로 이동함에 따라 플랫폼 엔지니어링이 점점 더 중요해지는 이유이기도 합니다. NIST의 현재 에이전트 신원 프로젝트는 에이전트 보안을 완전히 별개의 분야로 취급하기보다는, 확립된 신원 및 권한 부여 관행을 에이전트에 적용하는 데 명시적으로 초점을 맞추고 있습니다.

따라서 실제 아키텍처는 또 다른 AI 전용 보안 제품을 추가하는 것보다 기존 시스템 주변에 신뢰할 수 있는 제어 경계(control boundary)를 확립하는 것에 가깝습니다. 에이전트는 유용한 작업을 수행하기에 충분한 접근 권한을 가져야 하지만, 자신의 권한을 재정의할 만큼 충분한 권한은 가져서는 안 됩니다.

무엇부터 구현해야 할까요