콤퓨타지식 AI Agent는 회사 시스템에 어떻게 접근할까? Identity·Authentication·Authorization의 원리
페이지 정보
본문
작성일
AI Agent가 이메일을 확인하고, 캘린더에 일정을 등록하고, 회사 문서를 읽고, API를 호출하는 상황을 생각해보겠습니다.
이때 한 가지 질문이 생깁니다.
AI Agent는 어떤 권한으로 회사 시스템에 들어가는 걸까요?
가장 단순한 방법은 사람의 아이디와 비밀번호를 AI에게 알려주는 것입니다.
하지만 실제 기업 시스템에서는 이런 방식보다 훨씬 세분화된 접근관리 구조를 사용합니다.
누가 요청했는지,
어떤 Agent가 행동하는지,
어떤 시스템에 접근하는지,
어떤 행동까지 허용할지,
그 권한을 언제까지 유지할지를 각각 구분할 수 있어야 하기 때문입니다.
이 구조를 이해하려면 먼저 신원(Identity), 인증(Authentication), 권한부여(Authorization)의 차이부터 알아야 합니다.
■ AI Agent가 시스템을 사용한다는 것은 무엇을 의미할까?
컴퓨터 시스템에서 Resource를 사용하는 주체가 반드시 사람일 필요는 없습니다.
사람
↓
Human Identity
애플리케이션·서비스
↓
Application / Workload Identity
AI Agent
↓
Agent Identity
처럼 사람이 아닌 프로그램에도 별도의 Identity를 부여할 수 있습니다.
여기서 Identity란 시스템 안에서 “이 주체가 누구인가”를 다른 주체와 구분하기 위한 디지털 정체성입니다.
AI Agent에 별도의 Identity가 있다면 사용자의 계정을 그대로 공유하지 않고 Agent 자체를 하나의 작업 주체로 식별할 수 있습니다.
AWS 역시 Agent Identity를 사람이 아닌 Application이나 Service 등에 사용하는 작업 신원(Workload Identity)의 특수한 형태로 설명합니다.
중요한 것은 AI에게 새로운 이름을 하나 붙이는 것이 아닙니다.
사용자와 AI Agent를 서로 다른 주체로 구분할 수 있다는 것이 핵심입니다.
■ Identity와 Credential은 무엇이 다를까?
Identity와 함께 자주 등장하는 개념이 인증정보(Credential)입니다.
둘은 같은 의미가 아닙니다.
Identity
↓
누구인가?
Credential
↓
그것을 증명하거나 Resource에 접근하기 위해 무엇을 사용하는가?
예를 들어 회사 시스템에 maintenance-agent-01이라는 Agent Identity가 있다고 가정해보겠습니다.
이 이름 자체는 Agent를 구분하는 Identity입니다.
하지만 실제 시스템에서 해당 Agent를 인증하거나 다른 Resource에 접근하려면 Password, Certificate, Client Secret, API Key, Token 등의 Credential이 사용될 수 있습니다.
즉 Identity는 주체를 나타내고, Credential은 인증 또는 접근 과정에서 사용하는 증명정보입니다.
■ Authentication과 Authorization은 무엇이 다를까?
AI Agent의 접근 구조에서 특히 혼동하기 쉬운 것이 인증(Authentication)과 권한부여(Authorization)입니다.
Authentication
↓
“당신이 누구인지 확인했습니다.”
Authorization
↓
“그래서 당신은 이것을 할 수 있습니다.”
예를 들어 회사 출입구에서 사원증을 확인해 정환이라는 직원이 맞다는 사실을 확인했다고 생각해보겠습니다.
이것이 인증에 가깝습니다.
하지만 회사 직원이라고 해서 모든 직원이 서버실에 들어갈 수 있는 것은 아닙니다.
정환이라는 사람이 서버실에 들어갈 권한이 있는지를 별도로 판단해야 합니다.
이것이 권한부여입니다.
AI Agent도 마찬가지입니다.
Agent의 Identity가 정상적으로 인증됐다는 사실과 Agent가 고객 데이터베이스를 수정할 권한이 있다는 것은 전혀 다른 문제입니다.
따라서 실제 접근관리에서는 Identity를 확인하는 과정과 해당 Identity가 무엇을 할 수 있는지를 결정하는 과정이 분리됩니다.
■ Access Token은 어떻게 제한된 권한을 전달할까?
AI Agent가 다른 서비스에 접근할 때 자주 등장하는 것이 접근 토큰(Access Token)입니다.
이 개념을 이해하려면 OAuth 2.0을 알아야 합니다.
OAuth 2.0은 제3자 Application이 사용자의 비밀번호를 직접 전달받지 않고도 보호된 Resource에 제한적으로 접근할 수 있도록 설계된 권한부여 프레임워크(Authorization Framework)입니다.
여기서 중요한 것이 Access Token입니다.
Access Token은 단순히 비밀번호를 대신하는 문자열이라기보다 보호된 Resource에 일정한 범위로 접근할 수 있도록 발급되는 Credential로 이해하는 것이 좋습니다.
예를 들어 하나의 Agent에게 개념적으로 다음과 같은 권한을 줄 수 있습니다.
Calendar 읽기 ✓
Calendar 수정 ✕
Drive 읽기 ✓
Drive 삭제 ✕
이때 접근 범위를 표현하는 데 사용되는 개념 중 하나가 접근 범위(Scope)입니다.
즉 Agent가 어떤 서비스에 접근할 수 있다는 사실만으로 모든 기능을 사용할 수 있는 것은 아닙니다.
어떤 Resource에서 어떤 작업까지 허용할 것인지 범위를 나눌 수 있습니다.
■ Agent는 자신의 권한으로 시스템에 접근할 수 있다
AI Agent가 다른 시스템에 접근하는 방법은 하나가 아닙니다.
첫 번째는 Agent 또는 Application 자체의 Identity를 사용하는 방식입니다.
이를 대표적으로 기계 간 접근(Machine-to-machine)이라고 볼 수 있습니다.
Agent
↓
Agent Identity
↓
Credential
↓
Access Token
↓
API / Resource
예를 들어 특정 시스템의 상태를 정기적으로 확인하는 자동화 Agent가 있다고 생각해보겠습니다.
이 작업에 특정 직원의 개인 데이터가 필요하지 않다면 굳이 직원 계정으로 접근할 이유가 없습니다.
Agent 자체에 업무에 필요한 Identity와 권한을 부여할 수 있습니다.
OAuth 2.0 환경에서는 Client Credentials 방식이 이러한 Machine-to-machine 접근에 사용될 수 있습니다.
핵심은 간단합니다.
“누군가를 대신해 행동하는 것”과 “Agent 자신에게 허용된 업무를 수행하는 것”을 구분하는 것입니다.
■ 사용자가 Agent에게 자신의 권한을 위임할 수도 있다
반대로 Agent가 사용자의 개인 Resource에 접근해야 하는 경우도 있습니다.
예를 들어 사용자가 AI Agent에게 이렇게 요청했다고 가정해보겠습니다.
“내 Google Drive에서 지난달 계약서를 찾아줘.”
이때 Agent에게 사용자의 Google 비밀번호 전체를 알려줄 필요는 없습니다.
사용자
↓
서비스 로그인
↓
Agent 접근에 대한 동의(Consent)
↓
Authorization Server
↓
제한된 Access Token 발급
↓
Agent
↓
Resource 접근
같은 구조를 사용할 수 있습니다.
이것이 사용자 위임 접근(User-delegated Access)입니다.
사용자가 Agent에게 모든 권한을 넘기는 것이 아니라 특정한 목적과 범위의 권한을 위임하는 것입니다.
따라서
Consent = 모든 권한 허용
이 아닙니다.
어떤 Scope에 동의했는지에 따라 Agent가 사용할 수 있는 Resource와 행동이 달라질 수 있습니다.
■ 사용자와 Agent의 Identity를 함께 전달할 수도 있다
Agent 시스템이 복잡해지면 조금 더 어려운 문제가 발생합니다.
예를 들어 다음과 같은 구조를 생각해보겠습니다.
사용자
↓
AI Agent
↓
사내 업무 시스템
↓
외부 API
AI Agent가 다른 시스템에 접근할 때 Agent의 Identity만 전달하면 Downstream System은 이런 질문을 할 수 있습니다.
“어떤 Agent가 요청한 것인지는 알겠는데, 누구를 대신해서 하는 요청이지?”
반대로 사용자 Identity만 전달한다면 이런 문제가 생깁니다.
“어떤 사용자의 요청인지는 알겠는데, 실제로 어떤 Agent가 행동하고 있지?”
이때 사용되는 접근 패턴 중 하나가 대리 접근(On-Behalf-Of, OBO)입니다.
사용자를 대신해 Agent나 Application이 다른 Resource에 접근하면서 사용자와 실제 작업 주체에 대한 Identity Context를 함께 전달하는 방식입니다.
개념적으로 보면,
User Identity
Agent Identity
↓
제한된 Token
↓
Downstream Resource
구조입니다.
AWS AgentCore Identity의 OBO Token Exchange 역시 Agent가 인증된 사용자를 대신해 다른 Resource에 접근할 때 사용자와 Agent의 Identity 맥락을 유지하면서 대상 Resource에 맞게 제한된 Token을 사용할 수 있도록 설계되어 있습니다.
■ Delegation과 Impersonation은 무엇이 다를까?
여기서 한 단계 더 알아두면 좋은 개념이 권한 위임(Delegation)과 대리 행위(Impersonation)의 차이입니다.
둘 다 한 주체가 다른 주체와 관련된 권한으로 행동하기 때문에 비슷해 보입니다.
하지만 Identity를 바라보는 방식에는 차이가 있습니다.
Impersonation
↓
A가 B의 권한으로 B처럼 행동
Delegation
↓
B가 A에게 일부 권한을 위임하되 실제 행동 주체 A도 구분
OAuth 2.0 Token Exchange 표준인 RFC 8693에서도 Impersonation과 Delegation을 구분합니다.
Delegation에서는 누구의 권한을 바탕으로 한 요청인지와 실제로 행동하는 주체가 누구인지를 함께 표현할 수 있습니다.
AI Agent에서는 이 구분이 특히 중요해질 수 있습니다.
사람이 Agent에게 일을 맡겼다고 해서 사람과 Agent가 동일한 Identity가 되는 것은 아니기 때문입니다.
■ 왜 사용자와 Agent의 행동을 함께 기록해야 할까?
예를 들어 회사의 고객 데이터 하나가 삭제됐다고 가정해보겠습니다.
로그에 이렇게만 기록되어 있습니다.
“정환 계정으로 삭제되었습니다.”
하지만 실제로는 여러 가능성이 있습니다.
정환이 직접 삭제했을 수도 있고,
정환이 실행한 Agent가 삭제했을 수도 있고,
정환이 허용한 범위를 넘어 Agent가 잘못된 작업을 수행했을 수도 있습니다.
따라서 Agent 환경에서는 두 가지 질문이 중요해집니다.
누구를 위한 작업이었는가?
그리고
실제로 행동한 주체는 누구인가?
Microsoft Entra Agent ID에서도 Agent Identity를 별도의 Service Principal로 관리하고 로그인 기록과 감사 기록(Audit Log)을 통해 Agent 관련 활동을 추적할 수 있는 구조를 제공합니다.
이러한 기록은 문제가 발생했을 때 사용자와 Agent의 행동을 구분하고 어떤 Identity와 권한을 통해 작업이 수행됐는지 추적하는 데 사용될 수 있습니다.
■ Agent에게는 어느 정도의 권한을 줘야 할까?
접근관리에서 오래전부터 사용되어 온 중요한 원칙이 있습니다.
최소 권한(Least Privilege)입니다.
업무를 수행하는 데 필요한 최소한의 권한만 부여하는 원칙입니다.
예를 들어 어떤 Agent가 특정 Repository의 코드를 읽기만 하면 되는 업무를 수행한다고 생각해보겠습니다.
그 Agent에게 서버 전체 관리자 권한까지 부여할 필요는 없습니다.
특정 Repository
↓
필요한 작업
↓
필요한 API
↓
필요한 기간
처럼 접근 범위를 제한할 수 있습니다.
즉 Agent의 권한관리는 단순히
허용 / 차단
의 문제가 아닙니다.
누가
↓
어떤 Resource에
↓
어떤 행동을
↓
어떤 조건에서
↓
어느 범위까지
접근할 수 있는지를 결정하는 문제입니다.
AI Agent라고 해서 기존 보안의 최소 권한 원칙이 사라지는 것이 아니라, 새로운 작업 주체인 Agent에도 같은 원리가 적용되는 것입니다.
■ Token과 Credential은 어디에 보관할까?
Agent가 여러 서비스를 이용하려면 API Key, OAuth Token, Client Secret 등의 Credential이 필요할 수 있습니다.
그렇다고 Credential을 Agent의 Prompt나 Source Code에 그대로 기록하는 것이 반드시 필요한 것은 아닙니다.
Credential을 별도의 보안 저장소에서 관리하고 Agent가 필요할 때 허용된 Credential에 접근하도록 구성할 수 있습니다.
예를 들어 AWS AgentCore Identity에는 OAuth Token이나 API Key 등의 Credential을 관리하기 위한 Token Vault 구조가 있습니다.
개념적으로 보면,
Agent
↓
Resource 접근 요청
↓
Agent / User Identity 확인
↓
Credential Vault
↓
권한 확인
↓
필요한 Credential 사용
↓
Resource 접근
으로 이해할 수 있습니다.
중요한 것은 Agent가 어떤 Credential을 알고 있느냐보다 어떤 조건에서 어떤 Credential을 사용할 수 있느냐를 관리하는 것입니다.
■ Agent의 권한에도 수명주기가 있다
한 번 권한을 부여했다고 해서 그 권한이 영원히 유지되는 것도 아닙니다.
Access Token에는 유효기간이 존재할 수 있고, 필요하면 새로운 Token을 발급받거나 기존 Token의 권한을 더 이상 사용할 수 없도록 처리할 수 있습니다.
Agent의 역할이 바뀌거나 더 이상 사용되지 않는다면 Agent Identity 자체를 비활성화하거나 삭제하는 것도 가능합니다.
따라서 Agent의 접근관리는 하나의 Lifecycle로 볼 수 있습니다.
Agent Identity 생성
↓
Authentication
↓
Authorization
↓
Credential / Token 발급
↓
Resource 접근
↓
행동 기록
↓
Token 만료·갱신
↓
권한 변경·회수
↓
Agent 비활성화·삭제
이러한 Lifecycle 관리 역시 기존 IAM에서 사용하던 원리가 AI Agent라는 새로운 작업 주체로 확장되는 과정입니다.
■ Agent Identity는 완전히 새로운 보안 기술일까?
Agent Identity라는 표현은 새롭게 느껴질 수 있지만, 그 아래에서 작동하는 기술의 상당 부분은 AI 때문에 처음 등장한 것이 아닙니다.
Identity and Access Management(IAM),
Authentication,
Authorization,
OAuth,
Access Token,
Scope,
Delegation,
Least Privilege,
Audit,
Credential Management
등은 기존 웹과 클라우드 환경에서도 사용되어 온 개념입니다.
달라진 것은 이 원리를 적용해야 하는 새로운 작업 주체로 AI Agent가 등장했다는 점입니다.
기존에는 주로
사람
↓
Application
↓
Service
의 Identity와 권한을 관리했다면,
이제는
사람
↓
AI Agent
↓
Application / Tool
↓
Service / API / Data
처럼 Agent가 사람과 시스템 사이에서 실제 행동을 수행하는 구조가 만들어지고 있습니다.
따라서 AI Agent의 접근관리를 이해하는 핵심은 AI에게 사람의 계정을 그대로 넘겨주는 데 있지 않습니다.
누가 요청했는지, 어떤 Agent가 행동하는지, 어떤 Resource에 어떤 권한으로 접근하는지를 서로 분리해 관리하는 것에 있습니다.
전체 구조를 정리하면 다음과 같습니다.
User / Agent
↓
Identity
↓
Authentication
↓
Authorization
↓
Credential / Access Token
↓
Scope / Policy
↓
Delegation / On-Behalf-Of
↓
Resource
↓
Audit
↓
Revocation / Lifecycle
Agent Identity는 완전히 새로운 인증 기술이라기보다, 기존 IAM·OAuth·권한 위임 구조가 AI Agent라는 새로운 작업 주체까지 확장되는 과정으로 이해하는 것이 정확합니다.
────────────────────
용어 정리
신원(Identity)
시스템에서 사람, Application, Service, Agent 등의 주체를 다른 주체와 구분하기 위한 디지털 정체성.
인증(Authentication)
접근을 요청한 주체가 주장한 Identity와 일치하는지 확인하는 과정.
권한부여(Authorization)
인증된 주체가 어떤 Resource에서 어떤 행동을 수행할 수 있는지 결정하는 과정.
인증정보(Credential)
Identity를 인증하거나 Resource에 접근하는 과정에서 사용하는 증명정보. Password, Certificate, Client Secret, API Key, Token 등이 문맥에 따라 포함될 수 있습니다.
접근 토큰(Access Token)
보호된 Resource에 접근하기 위해 사용되는 Credential. 특정한 Scope와 유효기간 등을 가질 수 있습니다.
접근 범위(Scope)
Token 등에 허용된 Resource 또는 작업의 범위를 표현하는 값.
권한 위임(Delegation)
한 주체가 자신의 권한 일부를 다른 주체가 사용할 수 있도록 위임하면서 실제 행동 주체를 구분할 수 있도록 하는 구조.
대리 행위(Impersonation)
한 주체가 다른 주체의 권한으로 행동하는 방식. Delegation과는 Identity Context를 표현하는 방식에 차이가 있습니다.
대리 접근(On-Behalf-Of, OBO)
Agent나 Application이 인증된 사용자를 대신해 다른 Resource에 접근하면서 사용자와 작업 주체의 Identity Context를 전달하는 접근 패턴.
작업 신원(Workload Identity)
Application, Service, Agent처럼 사람이 아닌 실행 주체에 부여되는 Identity.
최소 권한(Least Privilege)
업무 수행에 필요한 최소한의 접근권한만 부여하는 보안 원칙.
권한 회수(Revocation)
기존에 부여된 Token이나 접근권한을 더 이상 사용할 수 없도록 하는 과정.
────────────────────
참고자료
IETF — RFC 6749: The OAuth 2.0 Authorization Framework
https://datatracker.ietf.org/doc/html/rfc6749
IETF — RFC 8693: OAuth 2.0 Token Exchange
https://datatracker.ietf.org/doc/html/rfc8693
AWS — AgentCore Identity terminology
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-terminology.html
AWS — Supported authentication patterns
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/common-use-cases.html
AWS — Understanding workload identities
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/understanding-agent-identities.html
AWS — Authenticate and authorize with Inbound Auth and Outbound Auth
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-oauth.html
AWS — Features of AgentCore Identity
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/key-features-and-benefits.html
Microsoft — Agent identities, service principals, and applications
https://learn.microsoft.com/en-us/entra/agent-id/agent-service-principals
Microsoft — Governing Agent Identities
https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview
Microsoft — Agent identity blueprints in Microsoft Entra Agent ID
https://learn.microsoft.com/en-us/entra/agent-id/agent-blueprint