1편에서는 Zero Trust의 기본 원칙인 신뢰를 권한의 근거로 사용하지 않는다는 내용을 살펴봤다.
2편에서는 이 원칙이 사람에게 어떻게 적용되어 왔는지 살펴봤다.
Authentication, MFA, RBAC, ABAC, JIT, JEA, Device Trust, Workload Identity를 거치면서 결국 하나의 구조로 수렴했다.
flowchart LR
Identity["Identity"]
Resource["Resource"]
Action["Action"]
Context["Context"]
Risk["Risk"]
Policy["Policy Engine"]
Identity --> Policy
Resource --> Policy
Action --> Policy
Context --> Policy
Risk --> Policy
Policy -->|"ALLOW"| Allow["ALLOW"]
Policy -->|"DENY"| Deny["DENY"]
그렇다면 AI Agent는 어떨까? AI Agent에게 Infrastructure를 관리할 수 있는 권한을 주기 시작하면 기존의 Human Authorization 모델만으로는 부족한 문제가 나타난다. Agent는 사람과 다르게 행동하기 때문이다.
1. AI Agent는 새로운 Security Principal이다
기존 Infrastructure에서는 주요 실행 주체가 사람이거나 Workload였다.
flowchart TD
Human["Human"]
Workload["Workload"]
Identity["Identity"]
Policy["Policy"]
Resource["Resource"]
Human --> Identity
Workload --> Identity
Identity --> Policy
Policy --> Resource
하지만 Agentic Architecture에서는 AI Agent가 직접 시스템을 변경할 수 있다.
flowchart TD
Human["Human"]
AI["AI Agent"]
Infrastructure["Infrastructure"]
Human -->|"Goal"| AI
AI -->|"Actions"| Infrastructure
이제 AI Agent 역시 하나의 Security Principal로 취급해야 한다.
flowchart TD
Human["Human"]
Workload["Workload"]
Agent["AI Agent"]
Identity["Identity"]
Policy["Policy"]
Resource["Resource"]
Human --> Identity
Workload --> Identity
Agent --> Identity
Identity --> Policy
Policy --> Resource
중요한 것은 AI라는 이유로 특별한 신뢰를 부여하지 않는 것이다. Agent도 Identity를 가져야 하고, Agent의 요청도 Policy를 통과해야 한다.
2. Agent에게 모든 권한을 주면 안 되는 이유
Agent에게 Kubernetes Administrator 권한을 부여한다고 생각해보자.
flowchart LR
Agent["AI Agent"]
Admin["Kubernetes Administrator"]
Cluster["Production Cluster"]
Agent --> Admin
Admin --> Cluster
Agent가 정상적으로 동작한다면 매우 편리하다. 하지만 Agent의 판단이 잘못되거나, Prompt Injection이 발생하거나, Tool이 오용되거나, Credential이 탈취된다면 결과가 달라진다.
flowchart TD
Agent["AI Agent"]
PromptInjection["Prompt Injection"]
ToolMisuse["Tool Misuse"]
CredentialLeak["Credential Compromise"]
ModelError["Model Error"]
Cluster["Production Cluster"]
Agent --> PromptInjection
Agent --> ToolMisuse
Agent --> CredentialLeak
Agent --> ModelError
PromptInjection --> Cluster
ToolMisuse --> Cluster
CredentialLeak --> Cluster
ModelError --> Cluster
문제는 단순히 AI Model이 틀릴 수 있다는 것이 아니다. Agent가 실제 시스템을 변경할 수 있는 권한을 가지고 있다는 것이 문제다. 따라서 Agent에게 필요한 것은 더 강한 권한이 아니라 더 정교하게 제한된 권한이다.
3. Agent Identity
첫 번째 질문은 Human과 동일하다. 이 Agent는 누구인가? Agent가 API를 호출할 때 단순히 토큰으로 접근하는게 아니라 Agent 자체를 식별할 수 있어야 한다.
flowchart LR
Agent["AI Agent"]
Identity["Agent Identity"]
Policy["Policy"]
Resource["Resource"]
Agent --> Identity
Identity --> Policy
Policy --> Resource
Agent Identity에는 최소한 다음과 같은 개념을 고려할 수 있다.
Agent
Agent Instance
Application
Human Principal
Workload
Environment
flowchart TD
Human["Human Principal"]
Application["Agent Application"]
Instance["Agent Instance"]
Environment["Production"]
Human --> Application
Application --> Instance
Instance --> Environment
중요한 것은 Agent를 단순히 “하나의 API Key”로 표현하지 않는 것이다. Agent의 Identity와 Credential은 분리되어야 한다.
4. Human Identity와 Agent Identity는 다르다
사람과 Agent는 조금 다른 정보를 갖는다. Agent는 조금 더 많은 정보를 필요로 한다.
flowchart LR
User["Human"]
Identity["User Identity"]
Device["Device"]
Context["Context"]
User --> Identity
User --> Device
User --> Context
flowchart LR
Human["Human Principal"]
Agent["Agent"]
Application["Application"]
Workload["Workload"]
Environment["Environment"]
Identity["Agent Identity"]
Human --> Identity
Agent --> Identity
Application --> Identity
Workload --> Identity
Environment --> Identity
특히 중요한 것이 위임(Delegation)인데, Agent가 사용자를 대신하여 작업하고 있다면 이 작업은 Agent의 권한인지, 사용자가 Agent에게 위임한 권한인지 구분해야 한다.
flowchart LR
User["Human Principal"]
Agent["AI Agent"]
Resource["Resource"]
User -->|"Delegate"| Agent
Agent -->|"Act on behalf of"| Resource
이 구분이 없다면 Audit을 해도 누군가 Database를 삭제했을 때 AI Agent라는 정보만 남는 문제가 발생한다.
하지만 실제로는 어떤 사용자가 Agent에게 권한을 위임했고, 어떤 Policy에 따라 무슨 Action을 했는지를 추적해야 한다.
5. Delegation과 Authorization
Agent Authorization에서는 Identity를 단순하게 생각하면 안 된다. 다음과 같은 관계를 고려해야 한다.
flowchart TD
Human["Human Principal"]
Delegation["Delegation"]
Agent["AI Agent"]
Tool["Tool"]
Resource["Resource"]
Action["Action"]
Human --> Delegation
Delegation --> Agent
Agent --> Tool
Tool --> Resource
Tool --> Action
Agent --> Policy["Policy Evaluation"]
Tool --> Policy
Resource --> Policy
Action --> Policy
Delegation --> Policy
예를 들어 사용자가 다음 요청을 했다고 하자.
Production payment-api의 최근 Error Log를 확인하고 문제가 있으면 Restart해줘.
이 요청을 하나의 권한으로 보면 안 된다. 실제로는 서로 다른 Action이 존재한다. 따라서 Agent에게 Production Administrator 권한을 주는 것보다 아래와 같이 필요한 Tool과 Action만 허용하는 것이 안전하다.
flowchart TD
Goal["User Goal"]
ReadLogs["Read Logs"]
Analyze["Analyze"]
Restart["Restart Deployment"]
Goal --> ReadLogs
Goal --> Analyze
Goal --> Restart
flowchart LR
Agent["AI Agent"]
Read["Read Logs"]
Restart["Restart payment-api"]
Agent --> Read
Agent --> Restart
6. Tool이 새로운 Authorization Boundary가 된다
Agent Architecture에서 중요한 개념이 Tool이다. Agent가 직접 Infrastructure API를 호출하는 대신 Tool을 통해 작업하도록 만들 수 있다.
flowchart LR
Agent["AI Agent"]
Tool["Tool"]
Resource["Resource"]
Agent --> Tool
Tool --> Resource
flowchart TD
Agent["AI Agent"]
GetLogs["Tool\nget_logs"]
Restart["Tool\nrestart_deployment"]
Scale["Tool\nscale_deployment"]
Delete["Tool\ndelete_namespace"]
Agent --> GetLogs
Agent --> Restart
Agent --> Scale
Agent --> Delete
그렇다고 Agent는 모든 Tool을 호출할 수 있는 것은 아니다. Tool을 호출하는 것 자체가 인증의 경계가 될 수 있다. 하지만 Tool 이름만 확인해서는 충분하지 않다.
flowchart TD
Agent["AI Agent"]
ReadLogs["get_logs"]
Restart["restart_deployment"]
Delete["delete_namespace"]
Agent --> ReadLogs --> Allow
Agent --> Restart --> Allow
Agent --> Delete --> Deny["DENY"]
7. Tool → Resource → Action
Agent Authorization을 좀 더 구체적으로 표현해보자.
flowchart LR
Agent["Agent"]
Tool["Tool"]
Resource["Resource"]
Action["Action"]
Policy["Policy Engine"]
Agent --> Tool
Tool --> Resource
Tool --> Action
Agent --> Policy
Tool --> Policy
Resource --> Policy
Action --> Policy
Policy -->|"ALLOW"| Execute["Execute"]
Policy -->|"DENY"| Reject["Reject"]
예를 들어 아래와 같은 요청이 들어올 수 있다. 이것을 Policy에서 판단한다.
Tool:
restart_deployment
Resource:
production/payment-api
Action:
restart
flowchart LR
Agent["Agent"]
Tool["restart_deployment"]
Resource["production/payment-api"]
Action["restart"]
Policy["Policy Engine"]
Agent --> Policy
Tool --> Policy
Resource --> Policy
Action --> Policy
Policy -->|"ALLOW"| Execute["Execute"]
Policy -->|"DENY"| Reject["Reject"]
여기서 중요한 것은 Tool을 사용할 수 있다는 것과 Tool이 모든 Resource에 모든 Action을 수행할 수 있다는 것은 다르다.
8. Context와 Risk
Agent의 Authorization에는 Human보다 더 많은 Context가 필요할 수 있다.
flowchart TD
Agent["AI Agent"]
Identity["Identity"]
Tool["Tool"]
Resource["Resource"]
Action["Action"]
Context["Context"]
Risk["Risk"]
Agent --> Identity
Agent --> Tool
Agent --> Resource
Agent --> Action
Agent --> Context
Agent --> Risk
Identity --> Policy["Policy Engine"]
Tool --> Policy
Resource --> Policy
Action --> Policy
Context --> Policy
Risk --> Policy
Policy --> Allow["ALLOW"]
Policy --> Deny["DENY"]
Context에는 다음과 같은 정보가 포함될 수 있다.
Human Principal
Agent Identity
Environment
Resource Owner
Request Source
Time
Previous Actions
Tool Chain
Approval State
Risk에는 다음과 같은 정보가 포함될 수 있다.
Action Sensitivity
Resource Sensitivity
Unusual Behavior
Repeated Failure
Privilege Escalation
Production Impact
동일한 Tool이라도 Resource와 Environment에 따라 다른 정책을 적용할 수 있다.
flowchart TD
Tool["restart_deployment"]
Dev["Development"]
Prod["Production"]
Tool --> Dev
Tool --> Prod
Dev --> Allow["ALLOW"]
Prod --> Review["Additional Approval"]
9. Human-in-the-loop
모든 Agent Action을 자동으로 허용할 필요는 없다. 특히 높은 위험을 가진 작업은 사람의 승인을 요구할 수 있다. 시스템의 로그를 읽는 것은 자동으로 허용하고, 배포된 서비스를 재시작 하는 것은 조건부로 허용하며 Production Database를 조작하는 것은 사용자의 승인을 요구할 수 있다.
flowchart LR
Agent["AI Agent"]
Policy["Policy Engine"]
Approval["Human Approval"]
Resource["Production Resource"]
Agent --> Policy
Policy -->|"Low Risk"| Resource
Policy -->|"High Risk"| Approval
Approval -->|"Approved"| Resource
Approval -->|"Rejected"| Deny["DENY"]
Risk에 따라 Authorization 수준을 다르게 가져갈 수 있는 것이다. 중요한 것은 모든 것에 대한 작업 파이프라인에 사람을 포함하도록 만드는 것이 아니다. 그렇게 하면 Agent Automation의 장점이 사라진다. 목표는 Risk가 높은 작업에만 사람의 판단을 요구하는 것이다.
10. JIT와 Agent
Agent에게도 JIT를 적용할 수 있다. 예를 들어 Agent가 Production Deployment를 수행해야 하는 순간에만 필요한 권한을 발급한다.
sequenceDiagram
participant Agent
participant Policy as Policy Engine
participant STS
participant Resource
Agent->>Policy: Request Deployment Permission
Policy->>Policy: Evaluate Context / Risk
Policy-->>Agent: ALLOW
Agent->>STS: Request Temporary Credential
STS-->>Agent: Short-lived Credential
Agent->>Resource: Deploy
Resource-->>Agent: Result
STS->>STS: Credential Expires
이 구조에서는 Agent가 영구적인 Production Administrator Credential을 가지고 있지 않다.
flowchart LR
Agent["AI Agent"]
Permanent["Permanent Admin Credential"]
JIT["JIT Permission"]
Resource["Production"]
Agent --> Permanent
Agent --> JIT
Permanent --> Resource
JIT --> Resource
두 모델 중 JIT 모델이 Blast Radius를 줄이는 데 유리하다.
11. MCP가 등장한다
Agent가 다양한 Tool을 사용하게 되면서 Tool과 Agent 사이의 표준화된 Interface가 중요해졌다. 여기서 MCP(Model Context Protocol)가 등장한다. MCP는 Agent가 외부 Tool과 Resource를 표준화된 방식으로 사용할 수 있도록 하는 Protocol이다. 기본적인 구조를 단순화하면 다음과 같다.
flowchart LR
Agent["AI Agent"]
Client["MCP Client"]
Server["MCP Server"]
Tool["Tool"]
Resource["Resource"]
Agent --> Client
Client --> Server
Server --> Tool
Server --> Resource
MCP Server는 Agent에게 Tool과 Resource를 제공한다.
flowchart TD
Server["MCP Server"]
GetLogs["get_logs"]
Restart["restart_deployment"]
Scale["scale_deployment"]
Logs["Logs"]
Kubernetes["Kubernetes"]
Server --> GetLogs
Server --> Restart
Server --> Scale
GetLogs --> Logs
Restart --> Kubernetes
Scale --> Kubernetes
하지만 여기서 매우 중요한 질문이 생긴다. MCP Server가 Tool을 제공한다고 해서 모든 Agent가 모든 Tool을 사용할 수 있어야 하는가? 당연히 그렇지 않다. MCP 역시 Authentication과 Authorization이 필요하다.
12. MCP Authorization
MCP를 사용하는 구조에서 Authorization을 명확하게 분리해야 한다.
flowchart LR
Agent["AI Agent"]
Client["MCP Client"]
Server["MCP Server"]
Policy["Policy Engine"]
Tool["Tool"]
Resource["Resource"]
Agent --> Client
Client --> Server
Server --> Policy
Policy -->|"ALLOW"| Tool
Policy -->|"DENY"| Deny["DENY"]
Tool --> Resource
MCP Server가 단순한 Proxy가 되어서는 안 된다는 것이다. MCP Server는 요청의 Identity와 Tool, Resource, Action 등을 바탕으로 Authorization을 수행하거나 적절한 Policy Enforcement Point와 연계해야 한다.
13. MCP Tool Authorization
예를 들어 Agent가 다음 restart_deployment Tool을 호출한다고 하자. MCP Server가 단순히 Tool 이름만 확인하면 안 된다. 실제 Authorization에서는 최소한 다음과 같은 요소를 고려할 수 있다.
flowchart TD
Identity["Agent Identity"]
Tool["Tool"]
Resource["Resource"]
Action["Action"]
Context["Context"]
Risk["Risk"]
Policy["Policy Engine"]
Identity --> Policy
Tool --> Policy
Resource --> Policy
Action --> Policy
Context --> Policy
Risk --> Policy
Policy --> Allow["ALLOW"]
Policy --> Deny["DENY"]
Agent:
deployment-agent
Tool:
restart_deployment
Resource:
production/payment-api
Action:
restart
Context:
approved-change = true
Risk:
medium
Agent:
database-agent
Tool:
dlm_database
Resource:
production/payment-database
Action:
delete
Risk:
critical
두 상황 중 과연 어떤 것을 허용하고 거부해야 할 지는 명확하다.
14. MCP와 OAuth
MCP를 사용하는 환경에서도 Authentication과 Authorization을 분리해서 생각해야 한다. OAuth는 Resource에 대한 접근 권한을 위임하기 위한 중요한 기반이 될 수 있고, OIDC는 Identity Provider를 통한 Authentication에 사용될 수 있다.
flowchart LR
Agent["AI Agent"]
IdP["Identity Provider"]
OAuth["OAuth Authorization"]
MCP["MCP Server"]
Policy["Policy Engine"]
Resource["Resource"]
Agent --> IdP
IdP -->|"Identity"| Agent
Agent --> OAuth
OAuth -->|"Access Token"| Agent
Agent --> MCP
MCP --> Policy
Policy --> Resource
여기서 중요한 것은 Access Token을 가지고 있다는 사실만으로 모든 Tool 사용을 허용하지 않는 것이다. Token이 제공하는 Scope와 MCP Server의 세밀한 Authorization Policy를 함께 사용할 수 있다.
flowchart LR
Token["Access Token"]
Scope["OAuth Scope"]
Identity["Agent Identity"]
Tool["Tool"]
Resource["Resource"]
Action["Action"]
Policy["Policy Engine"]
Token --> Scope
Scope --> Policy
Identity --> Policy
Tool --> Policy
Resource --> Policy
Action --> Policy
Policy --> Allow["ALLOW"]
Policy --> Deny["DENY"]
OAuth Scope는 중요한 Authorization 정보지만, 전체 Policy를 대체하는 것은 아니다.
15. Tool Chain을 고려해야 한다
Agent Authorization에서 Human과 가장 다른 부분 중 하나다. Agent는 하나의 요청을 여러 Tool 호출로 확장할 수 있다.
예를 들어 “Payment API에 문제가 있으면 해결해줘.” 라는 요청이 다음과 같이 실행될 수 있다.
flowchart TD
Goal["Fix Payment API"]
ReadLogs["get_logs"]
Analyze["analyze"]
Restart["restart_deployment"]
Scale["scale_deployment"]
Goal --> ReadLogs
ReadLogs --> Analyze
Analyze --> Restart
Restart --> Scale
각 단계가 다른 권한을 요구한다. 따라서 첫 번째 Tool에 대한 Authorization이 성공했다고 해서 전체 Tool Chain을 신뢰해서는 안 된다.
flowchart TD
Tool1["Tool 1"]
Decision1["Authorization"]
Tool2["Tool 2"]
Decision2["Authorization"]
Tool3["Tool 3"]
Decision3["Authorization"]
Tool1 --> Decision1
Decision1 --> Tool2
Tool2 --> Decision2
Decision2 --> Tool3
Tool3 --> Decision3
사람과 동일하게 각 Action마다 다시 Authorization을 수행하는 것이 기본 원칙이 되어야 한다.
16. Agent가 가진 권한과 User가 가진 권한
Agent가 사용자를 대신하여 동작하는 경우에는 두 개의 권한 집합이 존재할 수 있다.
flowchart LR
User["Human Principal"]
Agent["AI Agent"]
UserPermission["User Permissions"]
AgentPermission["Agent Permissions"]
Effective["Effective Permission"]
User --> UserPermission
Agent --> AgentPermission
UserPermission --> Effective
AgentPermission --> Effective
Effective Permission은 일반적으로 다음과 같이 생각할 수 있다.
Effective Permission =
User Delegation ∩ Agent Permission ∩ Resource Policy ∩ Context
Agent가 아무리 강한 권한을 가지고 있어도 사용자가 위임하지 않은 권한을 사용할 수 없어야 한다. 반대로 사용자가 높은 권한을 가지고 있다고 해서 Agent에게 모든 권한을 자동으로 위임해서도 안 된다.
17. Policy는 Static하지 않다
Agent의 행동은 Context에 따라 달라질 수 있다. 따라서 Policy도 단순한 형태만으로는 부족할 수 있다.
flowchart TD
Identity["Agent Identity"]
Tool["Tool"]
Resource["Resource"]
Action["Action"]
Context["Context"]
Risk["Risk"]
Policy["Dynamic Policy"]
Identity --> Policy
Tool --> Policy
Resource --> Policy
Action --> Policy
Context --> Policy
Risk --> Policy
Policy --> Allow["ALLOW"]
Policy --> StepUp["STEP-UP"]
Policy --> Deny["DENY"]
따라서 결과도 Allow, Step-Up / Approval, Deny 세 가지 이상이 될 수 있다. 이런 구조가 Agentic System에 더 적합하다.
18. Blast Radius를 제한한다
Agent가 침해되었다고 가정해보자. 중요한 것은 침해 이후의 영향 범위다.
- Zero Trust에서는 침해되지 않을 것이라고 가정하지 않는다.
flowchart TD
Agent["Compromised Agent"]
Tool["Allowed Tools"]
Resource["Allowed Resources"]
Agent --> Tool
Tool --> Resource
flowchart TD
Agent["Compromised Agent"]
Read["Read Logs"]
Restart["Restart Payment API"]
DeleteDB["Delete Database"]
IAM["Modify IAM"]
Agent --> Read
Agent --> Restart
Agent -.->|"DENY"| DeleteDB
Agent -.->|"DENY"| IAM
Agent에게 필요한 Tool과 Resource만 허용하면 침해되더라도 Blast Radius를 줄일 수 있다.
19. Agent Observability
Agent의 Audit은 사람보다 더 많은 정보가 필요할 수 있다. 단순히 Identity와 Action만 기록해서는 부족할 수 있다. 다음과 같은 Chain을 추적할 수 있어야 한다.
flowchart TD
User["Human Principal"]
Goal["User Goal"]
Agent["AI Agent"]
Tool["Tool"]
Resource["Resource"]
Action["Action"]
Policy["Policy Decision"]
Result["Result"]
User --> Goal
Goal --> Agent
Agent --> Tool
Tool --> Resource
Tool --> Action
Agent --> Policy
Tool --> Policy
Resource --> Policy
Action --> Policy
Policy --> Result
즉, 최소한 시간과 사용자, Agent, 그 둘의 관계, 작업의 목적과 사용된 도구, 컨텍스트, 정책 결정과 결과 등을 기록해야 사고가 발생했을 때 사용자가 Agent에게 무엇을 요청했고, Agent가 어떤 Tool을 선택했으며, 어떤 Policy를 통과하여 어떤 Resource를 변경했는가?를 추적할 수 있다.
20. Agent Zero Trust Architecture
지금까지의 내용을 하나로 합쳐보자.
flowchart TD
Human["Human Principal"]
Goal["Goal"]
Agent["AI Agent"]
Identity["Agent Identity"]
Client["MCP Client"]
Server["MCP Server"]
Tool["Tool"]
Resource["Resource"]
Action["Action"]
Context["Context"]
Risk["Risk"]
Policy["Policy Engine"]
Approval["Human Approval"]
Audit["Audit"]
Human --> Goal
Goal --> Agent
Agent --> Identity
Agent --> Client
Client --> Server
Server --> Tool
Tool --> Resource
Identity --> Policy
Tool --> Policy
Resource --> Policy
Action --> Policy
Context --> Policy
Risk --> Policy
Policy -->|"ALLOW"| Tool
Policy -->|"STEP-UP"| Approval
Policy -->|"DENY"| Deny["DENY"]
Approval -->|"Approved"| Tool
Human --> Audit
Agent --> Audit
Identity --> Audit
Tool --> Audit
Resource --> Audit
Action --> Audit
Policy --> Audit
이 구조에서 중요한 것은 Agent가 직접 Resource에 접근하지 않는다는 것이다. Agent의 요청은 아래와 같이 수행되어야 한다.
Identity
→ Tool
→ Resource
→ Action
→ Context
→ Risk
→ Policy
21. Policy의 실제 구현
이 구조를 실제 Infrastructure에 적용한다면 다양한 기술을 조합할 수 있다.
flowchart TD
Agent["AI Agent"]
Identity["Identity"]
OAuth["OAuth / OIDC"]
MCP["MCP"]
Policy["Policy Engine"]
Credential["Short-lived Credential"]
Audit["Observability"]
Infrastructure["Infrastructure"]
Agent --> Identity
Identity --> OAuth
Agent --> MCP
MCP --> Policy
Policy --> Credential
Credential --> Infrastructure
Agent --> Audit
MCP --> Audit
Policy --> Audit
Infrastructure --> Audit
중요한 것은 OIDC, Credentials, Observability 등 많은 서비스를 사용하는 것이 아닌 각 기술의 역할을 분리하는 것이다.
22. 모든 요청에 Policy를 적용하면 느려지지 않을까?
당연히 비용이 발생한다. Agent의 모든 Tool Call마다 Policy Evaluation을 수행한다면 추가적인 Latency가 발생할 수 있다.
flowchart LR
Agent["AI Agent"]
Request["Tool Request"]
Policy["Policy Evaluation"]
Tool["Tool"]
Agent --> Request
Request --> Policy
Policy --> Tool
Identity Infrastructure를 운영해야 하고, Policy를 작성하고 테스트해야 하며, 새로운 Tool을 추가할 때마다 Authorization Policy를 검토해야 한다. Agent의 행동이 복잡해질수록 Policy도 복잡해진다. 따라서 Zero Trust 역시 Trade-off가 있다.
flowchart LR
Security["Security"]
Latency["Latency"]
Complexity["Operational Complexity"]
Developer["Developer Productivity"]
Cost["Infrastructure Cost"]
Security --> Latency
Security --> Complexity
Security --> Developer
Security --> Cost
중요한 것은 모든 요청을 동일한 수준으로 검증하는 것이 아니다. Risk에 따라 Control을 다르게 적용할 수 있다.
flowchart TD
Request["Agent Request"]
Low["Low Risk"]
Medium["Medium Risk"]
High["High Risk"]
Allow["Automatic Allow"]
StepUp["Additional Verification"]
Approval["Human Approval"]
Deny["DENY"]
Request --> Low
Request --> Medium
Request --> High
Low --> Allow
Medium --> StepUp
High --> Approval
Approval --> Deny
이것이 Risk-based Authorization의 핵심이다.
23. Agent에게 필요한 것은 Trust가 아니라 Control이다
결국 Agentic Infrastructure에서 중요한 질문은 AI를 믿을수 있는가?가 아니다. AI를 신뢰할 필요가 없도록 시스템을 만들어야 한다.
flowchart LR
Agent["AI Agent"]
Trust["Trust"]
Control["Control"]
Agent -.-> Trust
Agent --> Control
Control --> Identity["Identity"]
Control --> Policy["Policy"]
Control --> Least["Least Privilege"]
Control --> JIT["JIT"]
Control --> Audit["Audit"]
Agent가 잘못된 판단을 하더라도,
Agent가 공격자의 영향을 받더라도,
Credential이 탈취되더라도,
Tool이 오용되더라도,
Policy가 최종적인 Security Boundary가 되어야 한다.
마치며
AI Agent가 Infrastructure를 관리하는 시대가 오면 기존의 질문은 바뀐다.
기존에는 이 사용자가 누구이고 무엇을 할 수 있는지를 물었다.
Agentic Infrastructure에서는 여기에 더 많은 질문이 필요하다.
- 어떤 Agent인가?
- 누구를 대신하고 있는가?
- 어떤 Tool을 호출하려는가?
- 어떤 Resource에 접근하려는가?
- 어떤 Action을 수행하려는가?
- 현재 Context와 Risk는 무엇인가?
그리고 최종적으로 다음을 판단해야 한다.
지금 이 Action을 허용해야 하는가?
이를 하나의 모델로 표현하면 다음과 같다.
flowchart LR
Identity["Identity"]
Tool["Tool"]
Resource["Resource"]
Action["Action"]
Context["Context"]
Risk["Risk"]
Policy["Policy Engine"]
Identity --> Policy
Tool --> Policy
Resource --> Policy
Action --> Policy
Context --> Policy
Risk --> Policy
Policy -->|"ALLOW"| Execute["Execute"]
Policy -->|"STEP-UP"| Approval["Approval"]
Policy -->|"DENY"| Reject["Reject"]
이것이 Agentic Infrastructure에서의 Zero Trust다. Agent를 믿는 것이 아니라, Agent가 무엇을 하더라도 안전하도록 권한과 실행 경계를 설계하는 것. AI 시대의 Platform Engineer에게 중요한 역할 역시 여기에 있다. Agent에게 더 많은 권한을 주는 것이 아니라, Agent가 가진 권한을 정확하게 정의하고, 최소화하고, 일시적으로 부여하고, 모든 Action을 검증하고, 추적할 수 있는 Infrastructure를 만드는 것. 결국 AI 시대의 Infrastructure Security는 다음 질문으로 수렴한다.
AI가 무엇을 할 수 있는가?
그리고 Platform Engineer는 그 답을 AI Model이 아니라 Infrastructure와 정책으로 정의해야 한다.