AI 에이전트가 사용자 계정으로 직접 행동해도 될까?｜Impersonation과 Delegated Access를 구분하는 권한위임 설계

World Story Factory World Story Factory 9/17/2026 07:15:00 오전

AI 에이전트가 사용자 계정으로 직접 행동해도 될까?｜Impersonation과 Delegated Access를 구분하는 권한위임 설계

WSF 콘텐츠 역할
이번 글의 핵심은 단순한 “AI 에이전트 계정 보안”이 아닙니다. AI Agent가 사용자를 대신해서 행동하는 것과 사용자인 것처럼 행동하는 것은 어떻게 다른가를 파고듭니다.
조사자료에서도 이번 글의 핵심 메시지를 Impersonation: Agent = User처럼 행동과 Delegation: Agent ≠ User, Agent acts on behalf of User의 차이로 잡고 있습니다.
따라서 기존 Agent Identity → Agent-to-Agent Trust 콘텐츠와 겹치지 않도록 이번 글은 User Identity → Agent Identity → Consent → Delegated Permission → On-Behalf-Of → Resource/API → Actor·Subject Attribution → Audit에 집중합니다.

AI Agent에게 내 Google·Microsoft·업무 계정의 비밀번호나 Credential을 넘겨 직접 로그인하게 하는 것과, OAuth 2.0 기반 Delegated Access로 필요한 권한만 위임하는 것은 전혀 다른 보안 구조입니다.
AI Agent Security와 Identity and Access Management(IAM) 관점에서는 User Identity와 Agent Identity를 분리하고, Consent·Scope·Actor·Subject를 추적할 수 있게 만드는 것이 중요합니다.
특히 Agent가 이메일 전송, 파일 수정, 일정 관리, 결제 같은 실제 행동까지 수행하기 시작하면 “로그인할 수 있는가?”보다 “누구의 권한으로 누가 행동했는가?”가 더 중요한 질문이 됩니다.

2026년 8월 27일 미국 NIST는 Agentic AI Identity를 다룬 공식 글에서 개인·기업 Credential을 Agent와 공유하는 방식이 책임 추적의 공백을 만들 수 있으며, 특히 Agent가 User Credential을 사용하면 서비스 측에서 사람과 Agent를 구분하기 어려워져 User Impersonation 문제가 발생할 수 있다고 지적했습니다. NIST는 OAuth 2.0과 같은 기존의 현대적 Delegation 방식이 Agent Identity와 Authorization을 설계하는 중요한 기반이 될 수 있다고 설명합니다. (NIST)

그렇다면 답은 단순히 “AI에게 사용자 계정을 절대 주면 안 된다”일까요?

흥미롭게도 그렇지도 않습니다.

바로 그 지점에서 이번 이야기가 시작됩니다.

밤 11시 47분, 퇴근한 직장인의 메일함에서 계약서가 발송됐습니다.

다음 이야기는 실제 특정 기업의 사고 사례가 아니라 AI 에이전트 권한위임 환경에서 발생할 수 있는 상황을 재구성한 가상의 시뮬레이션입니다.

마케팅팀에서 근무하는 43세 직장인 윤서는 다음 날 아침까지 거래처 제안서 18건을 정리해야 합니다.

시계는 이미 밤 11시를 넘겼습니다.

형광등 아래 식어버린 커피에서는 씁쓸한 향만 남고, 메일함에는 아직 읽지 않은 메시지가 줄지어 있습니다.

윤서는 새로 도입한 AI 업무비서에게 말합니다.

“내일 오전 회의 전에 거래처 메일을 정리하고, 수정된 제안서를 담당자들에게 보내줘.”

AI Agent는 메일을 읽고 첨부파일을 정리합니다.

여기까지는 꽤 편리합니다.

그런데 다음 날 아침 윤서가 출근해 Sent Mail을 열어보니 이상한 점이 보입니다.

오전 2시 13분.

윤서 <yoonseo@company...>

명의로 제안서가 발송돼 있습니다.

겉으로 보면 윤서가 직접 보낸 메일처럼 보입니다.

하지만 윤서는 자고 있었습니다.

여기에서 질문이 생깁니다.

누가 이 메일을 보낸 것일까요?

윤서일까요?

AI Agent일까요?

회사의 메일 시스템은 둘을 구별할 수 있을까요?

윤서가 Agent에게 이메일을 “보내도 된다”고 허용한 것과 윤서의 계정 자체를 Agent에게 넘겨준 것은 같은 의미일까요?

그리고 Agent가 잘못된 첨부파일을 보내버렸다면 Audit Log에는 누구의 행동으로 기록되어야 할까요?

이 작은 차이가 바로 Impersonation과 Delegated Access의 경계입니다.

Impersonation이란?｜AI가 ‘나를 대신하는 것’과 ‘나인 것처럼 보이는 것’의 차이

Impersonation을 쉽게 이해하려면 회사 출입증을 떠올려보세요.

출장을 가면서 동료에게 이렇게 말합니다.

“오늘 회의자료를 대신 전달해 주세요.”

이것은 Delegation, 즉 위임에 가깝습니다.

그런데 내 사원증과 비밀번호를 동료에게 건네면서

“오늘 하루 그냥 나인 것처럼 회사 시스템을 사용하세요.”

라고 한다면 이야기가 달라집니다.

시스템에서는 실제 행동자가 누구인지 구별하기 어려워질 수 있습니다.

AI Agent도 마찬가지입니다.

사용자의 ID·Password나 광범위한 Credential을 그대로 사용하면 외부 Resource 입장에서는

User가 행동한 것인지, Agent가 행동한 것인지

구별하기 어려워질 수 있습니다.

NIST도 2026년 Agentic AI Identity 분석에서 Credential Sharing이 Accountability Gap을 만들 수 있으며, 특히 Consumer Agent 환경에서는 User Credential 공유가 Agent의 User Impersonation으로 이어질 수 있다고 설명합니다. 금융거래나 건강정보처럼 Non-Repudiation이 중요한 영역에서는 이 구분이 더욱 중요합니다. (NIST)

WSF 필자의 한 줄
“대신 일해주는 것과 내 이름이 되어버리는 것은 비슷해 보여도 책임의 흔적은 전혀 다릅니다.”

Delegated Access란?｜계정을 주지 않고 ‘필요한 권한’만 빌려주는 구조

Delegated Access는 생각보다 우리 일상과 닮았습니다.

호텔 프런트에 자동차를 맡긴다고 생각해보세요.

발레파킹 직원에게 자동차를 이동할 수 있는 권한은 줍니다.

하지만 집 현관 열쇠와 통장 비밀번호까지 줄 이유는 없습니다.

AI Agent도 비슷합니다.

Agent가 사용자를 대신해 이메일을 읽어야 한다면

메일 읽기 권한

이 필요할 수 있습니다.

일정을 추가해야 한다면

Calendar Write 권한

이 필요할 수 있습니다.

하지만 그것이

사용자의 모든 권한

을 의미하지는 않습니다.

핵심은 계정을 넘기는 것이 아니라 행동에 필요한 권한을 Scope 단위로 위임하는 것입니다.

NIST의 2026년 Software and AI Agent Identity and Authorization Concept Paper 역시 Agent에게 데이터·도구·애플리케이션 접근권한을 줄 때 Identification과 Authorization Control이 필요하다고 설명하며, Least Privilege, On-Behalf-Of Delegation, Human Identity와 Agent Identity의 Binding, Auditing과 Non-Repudiation을 주요 연구질문으로 제시하고 있습니다. (NIST CSRC)

Impersonation vs Delegated Access 비교 분석｜무엇을 구분해야 할까?

구분	User Impersonation 중심 구조	Delegated Access 중심 구조
Identity	Agent가 User Identity처럼 행동할 수 있음	User와 Agent Identity를 구분
Credential	사용자 Credential 공유 위험이 존재	Agent용 Token·Credential 사용 가능
권한	사용자 권한이 과도하게 전달될 위험	Scope·Policy로 필요한 범위 제한
행동 주체	실제 Actor 식별이 어려워질 수 있음	User와 Agent Actor를 함께 추적 가능
Consent	계정 접근 자체가 광범위해질 수 있음	특정 Delegated Permission에 동의 가능
Audit	"사용자가 했다"처럼 남을 위험	누가 대신 행동했는지 구분 가능
Revocation	Password 변경 등 거친 회수 필요 가능	위임된 Token·Permission 회수 설계 가능
적합한 방향	특수한 경우를 제외하고 신중한 설계 필요	사용자 대행 업무에 고려할 수 있는 현실적 구조

※ 모바일 화면에서는 표를 좌우로 스크롤하여 전체 내용을 편하게 확인하실 수 있습니다.

이 표에서 가장 중요한 차이는 기술 이름이 아닙니다.

책임을 분리할 수 있는가입니다.

User Identity와 Agent Identity를 왜 분리해야 할까?

사람과 Agent를 하나의 Identity로 취급하면 당장은 편합니다.

계정 하나만 연결하면 되기 때문입니다.

하지만 자동화 규모가 커지면 질문이 꼬이기 시작합니다.

누가 파일을 삭제했는가?

사용자가 직접 삭제했는가?

Agent가 삭제했는가?

어떤 Agent였는가?

사용자가 그 행동까지 허용했는가?

당시 Permission은 무엇이었는가?

그래서 Identity Architecture에서는 Human Principal과 Agent Principal을 분리하는 것이 중요해집니다.

Microsoft의 현재 Entra Agent ID 문서도 대부분의 AI Agent에는 Agent Identity를 사용하는 것을 권장하고 있으며, 일반적인 Human User Account를 Agent에 할당하는 방식은 권장하지 않습니다. Microsoft는 일반 User Account가 사람의 로그인 패턴을 전제로 만들어졌기 때문에 Conditional Access, Identity Protection, Governance 등에서 Agent와 맞지 않는 문제가 생길 수 있다고 설명합니다. (Microsoft Learn)

Subject와 Actor를 알면 Delegated Authorization이 쉬워집니다.

여기에서 조금 낯선 용어 두 개가 등장합니다.

Subject

그리고

Actor입니다.

어렵게 생각하지 마세요.

Subject는

“누구의 권한으로?”

라고 생각하면 됩니다.

Actor는

“실제로 누가 행동했는가?”

라고 생각해보세요.

예를 들면,

Subject: 윤서

Actor: Sales Assistant Agent

Action: send_email

Scope: mail.send

와 같은 식입니다.

즉 윤서의 권한 범위 안에서 Agent가 실제 실행자가 되는 것입니다.

Microsoft의 Agent Identity Architecture에서도 Interactive Agent의 경우 Token Subject를 사용자로 유지하면서 Agent를 Actor로 식별하는 패턴을 설명합니다. 반면 Autonomous Agent는 사람이 현재 참여하지 않는 Background Task에서 Agent 자신의 Identity를 사용합니다. (Microsoft Learn)

이 구조가 중요한 이유는 간단합니다.

User의 권한과 Agent의 행동을 동시에 설명할 수 있기 때문입니다.

On-Behalf-Of(OBO) Flow란?｜“사용자를 대신해서”를 기술적으로 표현하는 방법

On-Behalf-Of, 줄여서 OBO는 이름 그대로

“~을 대신해서”

라는 뜻입니다.

사용자가 Agent에 로그인합니다.

Agent가 사용자의 동의를 바탕으로 다른 API나 Resource를 호출해야 합니다.

이때 Agent가 사용자의 Password를 받아 다시 로그인하는 것이 아니라, 적절한 OAuth Token Flow를 이용해 Downstream Resource에 맞는 Delegated Permission으로 접근하는 패턴을 사용할 수 있습니다.

Microsoft Entra Agent ID의 현재 문서에서는 Signed-in User를 대신하는 Interactive Agent에 OAuth 2.0 On-Behalf-Of Flow를 사용할 수 있다고 설명합니다. 또한 OBO를 Delegated Access라고도 설명하며, Agent가 사용자의 원래 Token을 아무 Downstream API에 그대로 재사용하는 방식이 아니라 대상 Resource에 맞는 Token 흐름이 필요하다고 명시합니다. (Microsoft Learn)

쉽게 비유하면 이렇습니다.

사용자의 Token은 서울행 승차권인데 Agent가 부산행 열차까지 같은 표로 타려고 하면 안 됩니다.

어떤 Resource를 대상으로 발급된 Token인지, 즉 Audience도 중요합니다.

OAuth 2.0이 있으면 Agent 권한 문제가 자동으로 해결될까?

여기에서도 주의해야 합니다.

OAuth 2.0을 사용한다고 자동으로 안전해지는 것은 아닙니다.

Scope가 너무 넓다면 여전히 문제가 생깁니다.

예를 들어 Agent가 일정 제목만 읽으면 되는 업무인데

메일 읽기,

메일 보내기,

파일 삭제,

연락처 수정,

전체 Drive 접근

까지 허용한다면 OAuth를 사용하더라도 Least Privilege와 거리가 멉니다.

NIST도 현대적 Authorization Protocol로 옮기는 것만으로 과도한 권한 문제가 자동 해결되지는 않는다고 지적합니다. Agent의 속도와 실행범위를 고려하면 Authorization을 업무 가치와 Risk Tolerance에 맞게 좁히는 것이 중요하다는 설명입니다. (NIST)

그래서 중요한 것은

OAuth를 썼는가

보다

무엇을 얼마나 위임했는가

입니다.

Consent와 Permission은 같은 말일까?

Consent는

“사용자가 무엇에 동의했는가?”

입니다.

Permission은

“시스템이 실제로 무엇을 허용하는가?”

입니다.

Scope는

“그 허용 범위를 어디까지 제한했는가?”

에 가깝습니다.

예를 들어 여행 Agent에게

“내 캘린더를 보고 비어 있는 날짜를 찾아줘.”

라고 부탁했다고 해보겠습니다.

사용자의 의도는

Calendar Read

에 가까울 수 있습니다.

그런데 Agent가 Calendar Delete까지 사용할 수 있다면 사용자의 목적보다 기술적 권한이 더 넓습니다.

좋은 Permission Design은 단순히

“사용자가 동의 버튼을 눌렀다.”

에서 끝나지 않습니다.

사용자가 무엇에 동의했는지,

어떤 Resource인지,

어떤 Action인지,

얼마나 오래 사용할 수 있는지,

어떻게 취소할 수 있는지

설명할 수 있어야 합니다.

‘허용’ 버튼을 많이 보여주면 더 안전할까?

의외의 반전이 있습니다.

사용자에게 모든 행동을 승인받으면 가장 안전해 보입니다.

그런데 Agent가 5분마다 묻는다고 상상해보세요.

“메일을 읽을까요?”

허용.

“파일을 열까요?”

허용.

“일정을 확인할까요?”

허용.

“다른 API에 접근할까요?”

허용.

하루에 수십 번 반복되면 사용자는 문장을 읽지 않고 Allow를 누르기 시작할 수 있습니다.

NIST는 이를 Agentic AI에서 Human-in-the-Loop를 지나치게 사용하는 문제와 연결해 설명합니다. 승인요청이 지나치게 많으면 MFA Fatigue와 유사한 Consent Fatigue가 생겨 사용자가 습관적으로 허용할 위험이 있다는 것입니다. (NIST)

따라서 좋은 Agent UX는 승인창을 많이 띄우는 것이 아니라

위험한 순간에 의미 있는 승인을 요청하는 것

에 가깝습니다.

WSF 필자의 한 줄
“좋은 동의 화면은 허락을 많이 받아내는 화면이 아니라, 사용자가 무엇을 맡겼는지 기억할 수 있게 만드는 화면입니다.”

AI Agent에게 비밀번호를 직접 알려주면 왜 문제가 될까?

NIST는 Credential Sharing을 Agentic AI Identity에서 직접적인 보안 문제로 다룹니다.

Password를 Agent에게 주면 Agent는 사용자가 할 수 있는 일을 광범위하게 수행할 가능성이 있습니다.

서비스 입장에서는 사람의 정상 로그인인지 Agent의 자동화 행동인지 구분하기 어려울 수도 있습니다.

Credential이 Prompt·Log·Configuration File 등에 노출될 위험도 고려해야 합니다.

NIST는 특히 Static API Key와 Long-Lived Bearer Token 역시 탈취될 경우 다른 주체가 이를 제시할 수 있고, 장기 Credential이 Agent가 사용하는 여러 Network·Tool·Resource를 오가면 노출면이 커질 수 있다고 설명합니다. (NIST)

따라서

Password 공유 → 광범위한 User Impersonation

보다는

Agent Identity → Consent → Scoped Delegation → Short-Lived Credential → Resource

와 같은 방향을 검토할 가치가 있습니다.

하지만 “Agent는 절대로 User Account를 가지면 안 된다”도 틀릴 수 있습니다.

이번 글에서 가장 중요한 반전입니다.

앞에서는 일반 User Account를 Agent에게 넘기는 위험을 설명했습니다.

그렇다면 모든 Agent User Account가 잘못된 것일까요?

그렇지는 않습니다.

Microsoft Entra Agent ID에는 실제로 Agent's User Account라는 별도의 개념이 있습니다.

예를 들어 어떤 Agent가

Mailbox,

Calendar,

Teams Channel

처럼 User Object가 필요한 Resource에 접근해야 한다면 Agent Identity와 1:1로 연결되는 Agent용 User Account를 구성할 수 있습니다.

중요한 차이가 있습니다.

이것은 기존 인간 사용자의 계정과 Password를 Agent에게 넘겨주는 구조와 같지 않습니다.

Microsoft 문서상 Agent's User Account는 일반 Password나 Passkey를 갖는 Human Account와 다르게 제한된 Authentication Model을 사용하며, Parent Agent Identity와 연결됩니다. Microsoft는 이 Account를 User Object가 실제로 필요한 경우에만 사용하도록 설명합니다. (Microsoft Learn)

따라서 정확한 질문은

“AI Agent가 User Account를 가져도 되는가?”

가 아니라

“사람의 User Account를 Agent와 공유하는 것인가, 아니면 Agent용으로 관리되는 별도 Identity인가?”

입니다.

이 둘은 전혀 다른 문제입니다.

Autonomous Agent와 Interactive Agent도 구분해야 합니다.

모든 Agent가 User를 대신하는 것도 아닙니다.

새벽 3시에 서버 상태를 확인하는 Agent를 생각해보세요.

현재 로그인한 사용자가 없습니다.

이런 경우에는

Autonomous Agent

패턴이 더 자연스러울 수 있습니다.

Microsoft의 현재 Agent Identity Architecture에서는 두 가지 대표 Operation Pattern을 구분합니다.

Interactive Agent

User → Agent → Delegated Permission → Resource

사용자가 현재 참여하고 있으며 Agent가 사용자의 Permission Boundary 안에서 행동합니다.

반면

Autonomous Agent

Agent Identity → Application Permission → Resource

현재 사용자가 없는 Background·Scheduled·System-to-System 업무에서 Agent 자신의 Identity로 행동합니다. (Microsoft Learn)

그래서 모든 Agent에게 Delegated Access를 사용해야 한다는 것도 정답은 아닙니다.

누구를 대신하는 업무인가?

부터 판단해야 합니다.

Service Account도 모두 위험하다고 보면 안 됩니다.

Service Account라는 단어만 나오면 오래된 기술이니 위험하다고 단정하기 쉽습니다.

하지만 핵심 문제는 이름이 아닙니다.

공유 Identity인지,

Static Credential인지,

권한이 지나치게 넓은지,

누가 행동했는지 Attribution이 가능한지,

Credential Rotation과 Revocation이 가능한지

가 더 중요합니다.

현재 Microsoft Entra Agent ID 역시 Agent Workload에는 Agent 전용 Identity를 우선적으로 고려하도록 안내하고 있지만, 기존 Service Principal 자체를 모든 상황에서 “위험한 계정”이라고 정의하는 것은 정확하지 않습니다. (Microsoft Learn)

보안은 이름표보다 권한과 통제구조를 봐야 합니다.

Delegated Access도 무한정 이어지면 안 됩니다.

User가 Agent A에게 권한을 줍니다.

Agent A가 Agent B를 호출합니다.

B가 C를 호출합니다.

이제 질문이 달라집니다.

사용자가 A에게 준 Permission을 C도 사용할 수 있을까요?

A가 B에게 재위임할 권한은 있었을까요?

B가 Scope를 넓히지는 않았을까요?

이 부분은 직전 WSF의 Agent-to-Agent Trust·Delegation Chain 주제와 연결됩니다.

이번 글에서는 핵심만 기억하면 됩니다.

Delegation은 권한을 복제하는 과정이 아니라 필요한 범위로 제한하면서 전달하는 과정이어야 합니다.

User에게 mail.read만 허용받은 Agent가 Sub-Agent에게 mail.send, mail.delete까지 새로 만들어줄 수 있어서는 곤란합니다.

Permission은 오래 살아 있을수록 편리할까?

사용자는 한 번 연결하고 계속 사용하는 것을 좋아합니다.

매번 다시 인증하는 것은 귀찮기 때문입니다.

하지만 Agent 관점에서는 오래 살아 있는 Credential과 Permission이 항상 좋은 것은 아닙니다.

NIST는 Long-Lived API Key와 Access Token이 Agent 환경에서 위험을 확대할 수 있으며, Dynamic·Tightly Scoped·Audience-Restricted Credential 같은 기존 Identity Best Practice를 활용할 수 있다고 설명합니다. (NIST)

여기에서 기존 WSF의 Task-Scoped Access·Temporary Credentials 주제와 연결됩니다.

오늘 한 번의 파일 업로드를 위해 받은 권한이 6개월 뒤에도 살아 있을 이유는 무엇일까요?

권한은

누구에게

무엇을 위해

어떤 Resource에

어떤 Action으로

언제까지

허용했는지 설명할 수 있어야 합니다.

Audit Log에는 User만 기록하면 왜 부족할까?

가상의 윤서 사례로 돌아가겠습니다.

새벽 2시 13분에 계약서가 발송됐습니다.

로그에는

User: yoonseo

만 남았습니다.

이 정보만 보면 윤서가 직접 보냈는지 Agent가 보냈는지 알기 어렵습니다.

조금 더 설명 가능한 구조라면 다음과 같은 Context를 생각해볼 수 있습니다.

Subject: yoonseo
Actor: proposal-agent-17
Action: send_email
Resource: partner-mailbox
Scope: mail.send
Delegation: user-consented
Timestamp: 02:13
Result: success

물론 실제 Claim 이름과 Audit Schema는 사용하는 Identity Platform에 따라 달라집니다.

핵심은 특정 제품의 필드명이 아닙니다.

사용자와 실제 실행 Agent를 구분할 수 있어야 한다는 것입니다.

Microsoft Agent Identity 문서에서도 User Delegation 시 User Identity Context를 유지하면서 Agent를 Acting Entity로 식별하는 Token 패턴을 설명하고 있습니다. (Microsoft Learn)

WSF 필자의 한 줄
“자동화가 깊어질수록 로그는 ‘무엇이 일어났는가’보다 ‘누가 누구의 권한으로 했는가’를 말할 수 있어야 합니다.”

Non-Repudiation은 왜 AI Agent 시대에 중요할까?

Non-Repudiation은 우리말로 부인방지라고 번역합니다.

조금 딱딱합니다.

쉽게 말하면

“나는 그 행동을 하지 않았다.”

“Agent가 한 일이다.”

“사용자가 승인했다.”

“아무도 승인하지 않았다.”

같은 책임 다툼이 생겼을 때 행동과 승인관계를 설명할 수 있는 성질입니다.

NIST의 2026년 Agent Identity Concept Paper도 Auditing과 Non-Repudiation을 주요 검토영역으로 제시하며, Agent Action을 Human Authorization과 어떻게 연결할지 질문하고 있습니다. (NCCoE)

특히

결제,

의료정보,

계약,

개인정보,

기업 데이터 삭제

처럼 결과가 큰 행동에서는 이 문제가 중요해집니다.

권한위임을 설계할 때 반드시 확인할 실전 체크리스트

AI Agent에 계정이나 API를 연결하기 전에 다음 질문을 확인해보세요.

Agent가 Human User Account의 Password를 직접 사용하고 있지는 않은가?

User Identity와 Agent Identity를 구분할 수 있는가?

Agent가 사용자를 대신하는 Interactive Task인지, 자체 Identity가 필요한 Autonomous Task인지 구분했는가?

User Consent가 무엇에 대한 동의인지 설명할 수 있는가?

Permission Scope가 실제 업무보다 넓지는 않은가?

Read만 필요한 Agent에 Write·Delete까지 주고 있지는 않은가?

Access Token의 Audience가 대상 Resource와 맞는가?

Agent가 다른 Agent에게 권한을 재위임할 수 있는지 Policy가 존재하는가?

Credential의 Expiration과 Revocation을 관리하는가?

Subject와 Actor를 구분해 Audit할 수 있는가?

고위험 Action에 추가 Approval을 요구하는가?

Agent가 사라지면 Permission과 Credential도 회수되는가?

사용자가 자신이 허용한 Agent Permission을 확인하고 취소할 방법이 있는가?

체크가 많이 비어 있다면 AI 기능을 더 붙이기 전에 Identity Architecture부터 다시 그려보는 편이 좋습니다.

일반 사용자도 확인할 수 있는 AI 계정연동 보안 팁

기업 개발자만의 이야기는 아닙니다.

주부가 쇼핑 Agent를 사용하고,

직장인이 이메일 Agent를 연결하고,

자영업자가 회계 자동화 서비스를 사용하고,

학생이 Cloud Drive와 AI 서비스를 연동하는 시대라면 일반 사용자도 Permission 화면을 읽을 필요가 있습니다.

AI 서비스가 Google·Microsoft 등의 계정 연결을 요청할 때

“모든 파일 읽기·수정·삭제”

같은 광범위한 권한이 정말 필요한지 확인해보세요.

업무가 끝났는데도 오래된 연결이 남아 있다면 Account Security Settings에서 연결된 앱과 Permission을 점검하는 습관도 도움이 됩니다.

특히 Password 자체를 Chat이나 Prompt에 입력하라는 서비스는 더욱 신중하게 판단할 필요가 있습니다.

AI가 우리의 시간을 돌려주는 기술이라면 보안은 그 시간을 불안으로 다시 빼앗지 않도록 만드는 장치입니다.

아침에 눈을 떴을 때 Agent가 밤새 처리한 일을 보며

“편하다.”

라고 느낄 수 있어야지,

“내 계정으로 대체 무슨 일을 한 거지?”

라고 불안해해서는 안 됩니다.

그 작은 안심이 좋은 Agent Identity 설계의 가치입니다.

FAQ｜AI Agent Impersonation·Delegated Access에서 많이 묻는 질문

AI Agent에게 사용자 계정을 줘도 되나요?

기존 Human User Account의 Password나 광범위한 Credential을 그대로 Agent와 공유하는 방식은 신중해야 합니다. NIST도 Credential Sharing과 User Impersonation 문제를 지적합니다. 대신 Agent Identity와 제한된 Delegated Permission을 사용하는 방식을 검토할 수 있습니다. (NIST)

Impersonation과 Delegation의 차이는 무엇인가요?

Impersonation은 Agent가 다른 Identity처럼 행동하는 상황을 포함합니다. Delegation은 User와 Agent를 구분한 상태에서 User가 특정 권한을 Agent에게 위임하는 구조입니다.

Delegated Access란 무엇인가요?

로그인한 사용자의 권한 범위 안에서 Application이나 Agent가 특정 Resource에 접근하도록 권한을 위임하는 방식입니다.

On-Behalf-Of(OBO)란 무엇인가요?

사용자가 로그인한 상태에서 Agent가 사용자를 대신해 Downstream Resource에 접근하는 OAuth 기반 패턴입니다. Microsoft는 Agent의 OBO를 Delegated Access 패턴으로 설명합니다. (Microsoft Learn)

Agent가 사용자의 원래 Access Token을 다른 API에 그대로 사용해도 되나요?

일반화해서 그렇게 해서는 안 됩니다. Token은 Audience 등 사용 조건을 가지며, Microsoft의 OBO 설명에서도 원래 Token을 다른 Audience의 Downstream Resource에 단순 재사용하는 구조와 구분합니다. (Microsoft Learn)

Agent Identity와 User Identity는 무엇이 다른가요?

User Identity는 사람을 나타내는 Identity이고 Agent Identity는 AI Agent라는 별도 실행주체를 나타냅니다. 실제 제품별 구현은 다르지만 두 주체를 구분하면 Authentication·Authorization·Audit 설계가 쉬워집니다.

Subject와 Actor는 무엇인가요?

이번 문맥에서는 Subject를 “누구의 권한인가”, Actor를 “실제로 누가 행동했는가”로 이해하면 쉽습니다.

Autonomous Agent도 사용자 Permission이 필요한가요?

항상 그런 것은 아닙니다. 현재 사용자가 없는 Background Task에서는 Agent 자체 Identity와 Application Permission을 사용하는 구조가 적합할 수 있습니다. Microsoft도 Interactive와 Autonomous Operation Pattern을 구분합니다. (Microsoft Learn)

Agent에게 User Account가 필요한 경우도 있나요?

있을 수 있습니다. Microsoft Entra Agent ID에는 User Object를 요구하는 Mailbox·Teams 등의 Resource를 위해 Agent Identity와 1:1로 연결하는 Agent's User Account가 존재합니다. 하지만 이는 기존 인간의 계정 Password를 Agent에게 공유하는 것과 다른 구조입니다. (Microsoft Learn)

OAuth를 사용하면 안전한가요?

OAuth 자체만으로 안전이 보장되지는 않습니다. Scope·Consent·Token Lifetime·Audience·Revocation·Least Privilege를 함께 설계해야 합니다.

Agent에게 한 번 동의하면 계속 사용할 수 있나요?

제품과 Token·Permission Policy에 따라 다릅니다. 그래서 Consent와 Permission Lifetime, Revocation을 함께 확인해야 합니다.

Human-in-the-Loop가 많을수록 안전한가요?

항상 그렇지는 않습니다. NIST는 과도한 승인요청이 Consent Fatigue를 만들 수 있다는 문제도 지적합니다. 고위험 행동에 의미 있는 승인을 배치하는 설계가 중요합니다. (NIST)

Agent Identity는 국제표준으로 완성됐나요?

단일한 완성형 Agent Identity 표준이 확정됐다고 표현하기는 어렵습니다. NIST는 2026년 Agent Identity와 Authorization을 별도 연구영역으로 다루고 있으며 AI Agent Standards Initiative도 추진 중입니다. (NIST CSRC)

필자의 주관적인 마무리 의견

AI Agent를 바라보면서 저는 “얼마나 많은 일을 대신할 수 있는가”보다 이제 “어떤 이름과 권한으로 그 일을 하는가”를 더 중요하게 봐야 할 시점이 왔다고 생각합니다.

사람에게 비서를 고용했다고 해서 주민등록증과 통장 비밀번호, 회사 계정 전체를 건네주지는 않습니다. 필요한 일을 맡기고 필요한 범위의 권한을 줍니다. 그런데 디지털 세계에서는 편리하다는 이유로 AI에게 훨씬 넓은 Credential을 한꺼번에 주는 일이 쉽게 일어날 수 있습니다.

저는 Agent가 사람을 대신해 일하는 미래 자체를 부정적으로 보지 않습니다. 오히려 반복적인 메일 정리와 일정 조정, 자료 검색 같은 일을 Agent가 맡아주면 우리는 가족과 저녁을 먹거나 조금 더 일찍 퇴근하거나 중요한 판단에 시간을 쓸 수 있습니다. 기술이 주는 진짜 가치는 어쩌면 그런 평범한 한 시간에 있을지도 모릅니다.

하지만 그 편리함이 오래 지속되려면 Agent와 사람을 같은 Identity 뒤에 숨겨서는 안 됩니다.

누가 권한의 주인인지,

실제로 누가 행동했는지,

어떤 Permission을 받았는지,

사용자는 무엇에 동의했는지,

언제 권한이 끝나는지,

문제가 생겼을 때 행동을 추적할 수 있는지

설명할 수 있어야 합니다.

그래서 제가 생각하는 좋은 AI Agent 권한위임은 “AI를 얼마나 믿느냐”의 문제가 아닙니다.

믿어야 하는 범위를 기술적으로 작게 만드는 문제에 가깝습니다.

User Identity는 User에게 남겨두고, Agent Identity를 구분하고, 필요한 Scope만 위임하고, 행동을 Audit하며, 일이 끝나면 권한을 회수할 수 있어야 합니다.

AI가 내 삶을 편하게 해주는 디지털 비서가 되는 순간에도 내 계정의 주인은 여전히 나여야 합니다.

그 경계를 지키는 것이 Impersonation과 Delegated Access를 구분해야 하는 가장 현실적인 이유라고 생각합니다.

공식 자료 및 직접 확인 링크

이번 주제는 보안·Identity 기술이 빠르게 발전하고 있으므로 제품 설명과 연구 중인 방향을 구분해서 확인하는 것이 좋습니다.

NIST — Back to the Future: Why Agentic AI Needs a Strong Identity Foundation
2026년 8월 27일 공개된 NIST 공식 Cybersecurity Insights 글입니다. Credential Sharing, User Impersonation, Static Credential, Broad Authorization, HITL Consent Fatigue 등을 직접 다룹니다. (NIST)

NIST — Software and AI Agent Identity and Authorization Concept Paper
Agent Identification·Authentication·Authorization·Delegation·Auditing·Non-Repudiation 등을 다루는 NIST NCCoE Concept Paper입니다. 현재 확정표준이 아니라 연구·프로젝트 방향을 위한 Concept Paper라는 상태를 구분해야 합니다. (NIST CSRC)

NIST — AI Agent Standards Initiative
NIST는 2026년 2월 AI Agent가 사용자를 대신해 안전하게 행동하고 디지털 생태계에서 상호운용될 수 있도록 관련 표준 생태계를 지원하는 Initiative를 발표했습니다. (NIST)

Microsoft — Plan your agent identity architecture
Agent Identity, Interactive Agent, Autonomous Agent, Delegated Permission과 Agent's User Account의 역할을 구분하는 데 유용합니다. (Microsoft Learn)

Microsoft — Agent OAuth On-Behalf-Of Flow
Signed-in User를 대신하는 Agent가 OAuth 2.0 OBO Flow와 Delegated Permission을 이용하는 구조를 설명합니다. (Microsoft Learn)

Microsoft — Agent's User Account
“Agent는 User Account를 절대 가져서는 안 된다”는 과도한 단정을 피하기 위해 함께 확인할 가치가 있는 공식 자료입니다. (Microsoft Learn)