AI 에이전트가 실제 작업을 수행해야 할 때, 위험하지만 간단한 지름길은 서비스 API 키를 제공하고 프롬프트가 제대로 작동하기를 바라는 것입니다.

그 지름길은 확장성이 없습니다. 유용한 에이전트는 이제 티켓을 읽고, 이슈를 생성하고, CRM 레코드를 업데이트하고, 쿼리를 실행하고, 워크플로우를 트리거하며, 내부 도구를 호출할 수 있습니다. 만약 이 모든 것이 하나의 광범위한 키를 통해 실행된다면, 당신은 사용자 권한을 가진 것이 아닙니다. 당신은 빌려온 마스터 배지를 가진 로봇을 가진 것입니다.

더 안전한 패턴은 **AI 에이전트 권한 상속 (AI agent permission inheritance)**입니다. 즉, 에이전트가 명시적인 제한, 취소 가능성, 그리고 감사 추적 (audit trail)을 갖춘 상태에서, 하나의 작업을 위해 현재 사용자의 범위가 지정된 권한 (scoped permissions)으로 행동하는 것입니다.

이 가이드는 프로덕션 AI 도구를 위해 해당 패턴을 설계하는 방법을 보여줍니다.

왜 지금 권한 상속이 중요한가

최근 AI 플랫폼 논의는 동일한 문제 주변을 계속 맴돌고 있습니다. 에이전트가 단순히 답변하는 것을 넘어 행동할 수 있기 때문에 유용해지고 있다는 점입니다. 하지만 행동에는 접근 권한이 필요합니다.

압박은 여러 방향에서 오고 있습니다:

• 내부 팀들은 지원, 영업, 엔지니어링, 문서 및 데이터 시스템 전반에서 작동하는 에이전트를 원합니다.
• 개발자들은 MCP 서버, 워크플로우 플랫폼, 브라우저 도구 및 프라이빗 API를 통해 에이전트를 연결하고 있습니다.
• 보안 팀은 실험 과정에서 광범위한 키, 복사된 토큰, 그리고 프롬프트에 노출되는 자격 증명 (credentials)이 나타나는 것을 목격하고 있습니다.
• AI 게이트웨이와 에이전트 플랫폼은 모델 호출이 인프라가 됨에 따라 관찰 가능성 (observability), 접근 제어 (access control), 폴백 (fallback), 그리고 비용 제어 기능을 추가하고 있습니다.
• 잘못 구성된 에이전트 환경과 관련된 안전 사고는 빌더들에게 "테스트"와 "프로덕션" 경계가 반드시 실질적이어야 함을 상기시켜 줍니다.

실질적인 교훈은 "에이전트가 행동하게 하지 마라"가 아닙니다. 그것은 너무 투박합니다. 교훈은 다음과 같습니다: 에이전트는 영구적인 공유 비밀 (shared secret)이 아니라, 사용자 및 작업으로부터 제한된 권한을 상속받아야 합니다.

흔한 안티 패턴: 모든 에이전트에 하나의 키 사용

소규모 팀은 종종 다음과 같은 아키텍처로 시작합니다:

사용자 요청 (User request)
  -> AI 에이전트 (AI agent)
  -> 도구 라우터 (tool router)
...

이 방식은 빠르게 느껴집니다. 데모하기 쉽습니다. OAuth의 복잡성을 피할 수 있습니다. 하지만 또한 다음과 같은 문제들을 야기합니다:

AI 에이전트 권한 상속 (AI agent permission inheritance)이란 무엇인가?

AI 에이전트 권한 상속 (AI agent permission inheritance)이란 에이전트가 사용자의 신원 (identity), 역할 (role), 테넌트 (tenant), 동의 (consent) 및 현재 워크플로 (workflow)로부터 파생된, 작업 범위로 제한된 (task-scoped) 일시적인 권한을 부여받는 것을 의미합니다.

에이전트는 사용자의 원시 비밀번호 (raw password)를 받지 않습니다. 광범위한 서비스 키 (service key)를 받지도 않습니다. 대신 다음과 같은 내용을 담은 위임 토큰 (delegation token) 또는 권한 엔벨로프 (permission envelope)를 전달받습니다:

• 누가 작업을 시작했는가
• 어떤 테넌트 (tenant) 또는 워크스페이스 (workspace)에 속해 있는가
• 어떤 도구 (tools)를 호출할 수 있는가
• 어떤 레코드 (records) 또는 리소스 (resources)가 범위 (scope) 내에 있는가
• 어떤 작업이 읽기 전용 (read-only), 초안 전용 (draft-only), 또는 실행 가능 (executable)한가
• 얼마만큼의 비용 (spend), 시간, 또는 도구 사용이 허용되는가
• 권한이 언제 만료되는가
• 어떤 증거 (evidence)를 로그 (log)에 남겨야 하는가
• 무엇이 인간의 승인 (human approval)을 필요로 하는가

간단한 모델은 다음과 같습니다:

사용자 세션 (User session)
  -> 권한 서비스 (permission service)
  -> 작업 범위 제한 위임 토큰 (task-scoped delegation token)
...

핵심 아이디어: 에이전트의 권한은 프롬프트 (prompt)에 의해 결정되지 않습니다. 프롬프트는 업무를 설명할 수 있지만, 백엔드 (backend)가 허용되는 범위를 강제합니다.

권한 엔벨로프 (The permission envelope)

일반 객체 (plain object)로 시작하세요. 설계를 프롬프트 내부에 숨기지 마십시오.

{
  "delegation_id": "dlg_01J8...",
  "actor_user_id": "user_123",
...

이 객체는 제품 (product), 보안 (security), 엔지니어링 (engineering), 그리고 지원 (support) 팀 간의 계약 (contract)이 됩니다. 또한 "사용자가 접근할 수 있는 것에만 접근하라"와 같은 모호한 지시보다 테스트하기가 훨씬 쉽습니다.

도구를 모델의 의도(model intent)가 아닌 사용자 권한에 매핑하기

에이전트가 특정 도구가 필요하다고 주장할 수 있습니다. 하지만 그 주장만으로는 충분하지 않습니다.

모든 도구 호출 (tool call)은 다음을 결합한 정책 검사 (policy check)를 통과해야 합니다:

1. 사용자 권한 (User permissions): 이 사용자가 AI 없이도 이 작업을 수행할 수 있는가?
2. 작업 범위 (Task scope): 이 리소스가 현재 작업의 일부인가?
3. 에이전트 모드 (Agent mode): 에이전트가 읽기 전용 (read-only), 초안 (draft), 코파일럿 (copilot), 또는 자율 주행 (autopilot) 모드 중 어느 상태인가?
4. 위험 등급 (Risk tier): 이 작업이 돈을 송금하거나, 데이터를 삭제하거나, 고객에게 이메일을 보내거나, 권한을 변경하거나, 비밀 정보 (secrets)를 노출할 가능성이 있는가?
5. 근거 (Evidence): 에이전트가 인자 (arguments)를 생성할 때 신뢰할 수 있는 출처를 사용했는가?
6. 예산 (Budget): 실행 과정이 도구, 토큰, 또는 시간 제한을 초과했는가?

다음은 단순화된 TypeScript 스타일의 정책 검사 (policy check) 예시입니다:

type ToolCall = {
  tool: string;
  args: Record<string, unknown>;
...

빠져 있는 부분을 주목하세요: "LLM이 이것은 안전하다고 말했다"라는 분기 (branch)는 존재하지 않습니다.

모델은 제안할 수 있지만, 결정은 런타임 (runtime)이 합니다.

수명이 짧은 위임 토큰 (short-lived delegation tokens) 사용하기

위임 토큰 (delegation token)은 지루해야 합니다. 이는 찬사입니다.

좋은 위임 토큰의 조건은 다음과 같습니다:

• 수명이 짧음 (short-lived)
• 하나의 테넌트 (tenant)로 범위가 제한됨
• 하나의 작업 또는 워크플로 실행 (workflow run)으로 범위가 제한됨
• 사용자와 에이전트 신원 (identity)에 결합됨
• 에이전트 런타임 외부에서는 사용할 수 없음
• 취소 가능함 (revocable)
• 도구 호출을 승인할 때마다 로그가 남음

그림자 계정 (shadow accounts)이 되어버리는 수명이 긴 "에이전트 토큰 (agent tokens)"은 피하십시오. 나중에 백그라운드 에이전트가 작업을 계속해야 한다면, 워크플로 상태를 유지하고 정책을 재검토한 후 새로운 위임 토큰을 발급하십시오.

장시간 실행되는 작업의 경우, 리스 (leases)를 사용하십시오:

실행 시작 -> 10분 동안 위임 유효
실행 일시 중지 -> 리스 해제
실행 재개 -> 정책 재검토 -> 새로운 위임 발급

이는 사용자의 역할이 변경되거나, 고객 기록이 잠기거나, 테넌트가 통합 (integration)을 비활성화하거나, 지원 관리자가 승인을 취소할 때 도움이 됩니다.

읽기, 초안, 실행 모드 분리

가장 유용한 에이전트 워크플로는 첫날부터 완전한 자율성을 필요로 하지 않습니다.

다음과 같이 모드를 사용하십시오:

권한 엔벨로프 (permission envelope)에는 모드가 포함되어야 합니다. 도구 핸들러 (tool handlers)는 이를 강제해야 합니다.

UI 레이블에만 의존하지 마십시오. 제품에서 "초안 모드 (draft mode)"라고 표시한다면, 백엔드(backend)는 상태를 변경하는 호출을 거부해야 합니다.

출시 전 권한 취소 (revocation)를 위한 설계

권한 취소 (revocation)는 많은 에이전트 시스템이 모호해지는 지점입니다.

최소한 네 가지의 권한 취소 경로가 필요합니다:

1. 사용자 권한 취소 (User revocation): 사용자가 에이전트 실행을 취소합니다.
2. 관리자 권한 취소 (Admin revocation): 관리자가 사용자, 역할 (role), 테넌트 (tenant), 또는 통합 (integration)을 비활성화합니다.
3. 정책 권한 취소 (Policy revocation): 한도나 증거 규칙 (evidence rules)이 변경되어 리스크 엔진 (risk engine)이 실행을 차단합니다.
4. 사고 권한 취소 (Incident revocation): 보안 팀이 도구 (tool), 제공자 (provider), 커넥터 (connector), 또는 에이전트 클래스 (agent class)를 비활성화합니다.

에이전트 런타임 (agent runtime)은 실행이 시작될 때뿐만 아니라, 모든 도구 호출 (tool call) 전에 권한 취소 여부를 확인해야 합니다.

async function beforeToolCall(call, delegation) {
  const status = await delegationStore.getStatus(delegation.delegation_id);

...

이 방식이 엄격하게 느껴질 수 있지만, 에이전트 실패의 최악의 상황, 즉 인간이 중단되었다고 생각한 후에도 워크플로 (workflow)가 계속 동작하는 상황을 방지합니다.

위임 영수증 (delegation receipts) 저장

모든 의미 있는 에이전트 동작은 영수증 (receipt)을 남겨야 합니다.

좋은 영수증은 다음 질문에 답할 수 있어야 합니다:

• 누가 이것을 시작했는가?
• 어떤 에이전트가 행동했는가?
• 어떤 권한 엔벨로프 (permission envelope)가 이를 허용했는가?
• 어떤 도구 (tool)가 실행되었는가?
• 어떤 리소스 (resources)가 사용되었는가?
• 동작이 읽기 (read), 초안 (draft), 또는 실행 (execute)이었는가?
• 승인 (approval)이 필요했는가?
• 결과는 무엇인가?
• 재현 (replay), 검토 (review), 또는 롤백 (rollback)이 가능한가?

영수증 예시:

{
  "receipt_id": "rcpt_01J9...",
  "delegation_id": "dlg_01J8...",
...

영수증은 감사 (audit)만을 위한 것이 아닙니다. 개발자가 잘못된 출력을 디버깅하고, 지원 팀이 에이전트의 동작을 설명하며, 제품 팀이 어떤 워크플로가 더 자동화할 만큼 충분히 신뢰할 수 있는지 파악하는 데 도움을 줍니다.

콘텐츠 격차: 대부분의 가이드가 생략하는 것

AI 에이전트, OAuth, MCP, 그리고 API 보안에 관한 상위 랭킹 콘텐츠들은 종종 한 가지 계층만을 잘 다룹니다:

• 도구를 연결하는 방법
• 비밀값 (secrets)을 저장하는 방법
• OAuth 흐름 (flows)을 구축하는 방법
• 프롬프트 가드레일 (prompt guardrails)을 추가하는 방법
• 모델 호출 (model calls)을 로깅하는 방법
• AI 게이트웨이 (AI gateway)를 사용하는 방법

부족한 실질적 가치는 이러한 계층 간의 연결입니다. 권한 상속 (Permission inheritance)이 바로 그 연결 고리입니다.

질문은 단지 "키를 어디에 저장할 것인가?"에 그치지 않습니다. 다음과 같아야 합니다:

이 에이전트가 이 작업을 수행하기 위해 이 사용자로부터 상속받아야 할 정확한 권한은 무엇이며, 시스템은 해당 권한을 강제했음을 어떻게 증명할 것인가?

이것이 소규모 팀들이 초기에 메워야 할 아키텍처 격차 (architecture gap)입니다.

구현 체크리스트 (Implementation checklist)

에이전트에게 실제 도구 (tools)에 대한 액세스 권한을 부여하기 전에 이 체크리스트를 사용하세요.

1. 모든 도구 분류 (Classify every tool)

위험도에 따라 도구에 태그를 지정하세요:

• 고객 데이터 읽기 (read customer data)
• 내부 데이터 읽기 (read internal data)
• 초안 작성 (write draft)
• 운영 상태 기록 (write production state)
• 외부 메시지 전송 (send external message)
• 비용 지출 (spend money)
• 권한 변경 (change permissions)
• 비밀 정보 접근 (access secrets)

도구를 분류할 수 없다면, 자율 에이전트 (autonomous agent)가 사용할 수 없어야 합니다.

2. 실행당 권한 엔벨로프 생성 (Create a permission envelope per run)

에이전트가 프롬프트 (prompt)로부터 스스로의 권한을 찾아내게 두지 마세요. 사용자의 세션 (session), 테넌트 (tenant), 역할 (role), 플랜 (plan), 동의 (consent) 및 통합 상태 (integration status)를 확인한 후 백엔드 권한 엔벨로프 (permission envelope)를 생성하세요.

3. 도구 호출을 신뢰할 수 있는 인자(arguments)에 바인딩

에이전트가 주문 환불을 원한다면, order_id는 자유 형식의 텍스트 (free text)만으로 결정되는 것이 아니라, 신뢰할 수 있는 조회 결과나 선택된 UI 레코드로부터 가져와야 합니다.

4. 위험한 작업에 대한 승인 게이트 추가 (Add approval gates for risky actions)

승인 단계에서는 차이점 (diff), 근거 자료 (source evidence), 그리고 정확한 동작을 보여주어야 합니다. "에이전트 승인"은 너무 모호합니다. "order_555에 대한 $42.00 환불 초안 승인"은 검토가 가능합니다.

5. 트레이스(traces)뿐만 아니라 영수증(receipts)도 기록

모델 트레이스 (Model traces)는 에이전트가 무엇을 생각했는지 보여줍니다. 영수증 (Receipts)은 시스템이 무엇을 허용했는지 보여줍니다. 두 가지 모두가 필요합니다.

6. 테넌트 간 거부 테스트 (Test cross-tenant denial)

에이전트가 잘못된 테넌트, 잘못된 고객, 잘못된 레코드 또는 만료된 위임 (delegation)에 대해 유효한 도구를 사용하려고 시도하는 회귀 테스트 (regression tests)를 추가하세요. 이러한 테스트는 실패 시 차단 (fail closed)되어야 합니다.

7. 사용자에게 중지 버튼 제공

눈에 보이는 중지 버튼은 위임을 취소하고, 대기 중인 단계를 취소하며, 동일한 실행 (run)에서의 향후 도구 호출을 방지해야 합니다.

실제 사용 사례 (Real-world use cases)

지원 에이전트 (Support agent)

지원 에이전트 (Support agent)는 현재 티켓을 읽고, 최근 주문 내역을 조사하며, 환불 초안을 작성하고, 답변을 준비할 수 있습니다. 하지만 사람이 정확한 동작을 승인하기 전까지는 환불을 실행하거나 고객에게 이메일을 보낼 수 없습니다.

분석 에이전트 (Analytics agent)

분석 에이전트는 사용자가 이미 접근할 수 있는 지표 (metrics)를 쿼리할 수 있습니다. 권한 위임 (delegation)에는 행 수준의 테넌트 필터 (row-level tenant filters), 지표 정의 (metric definitions), 쿼리 예산 (query budgets), 그리고 차단된 컬럼 (blocked columns)이 포함됩니다. 에이전트는 더 넓은 권한을 가진 데이터 웨어하우스 역할 (warehouse role)에 대해 원시 SQL (raw SQL)을 작성함으로써 분석 권한을 우회할 수 없습니다.

엔지니어링 에이전트 (Engineering agent)

코딩 에이전트는 이슈 (issues)를 읽고, 리포지토리 (repository) 파일을 조사하며, 브랜치 (branch)를 생성하고, 풀 리퀘스트 (pull request) 초안을 작성할 수 있습니다. 하지만 승인 없이 비밀값 (secrets)을 교체하거나, 배포 설정 (deployment settings)을 변경하거나, 머지 (merge)할 수는 없습니다.

영업 운영 에이전트 (Sales operations agent)

영업 에이전트는 리드 (lead) 정보를 보강하고, CRM 노트를 작성하며, 다음 단계를 제안할 수 있습니다. 하지만 동의와 속도 제한 (rate limits) 없이는 전체 고객 명단을 내보내거나 외부 메시지를 보낼 수 없습니다.

간단한 참조 아키텍처 (A simple reference architecture)

[User Session]
      |
      v
...

이 아키텍처는 도구가 REST API, MCP 서버, 큐 (queues), 브라우저 동작 (browser actions), SQL 쿼리, 또는 내부 SDK 호출인지 여부와 관계없이 작동합니다. 중요한 점은 모든 실행 경로가 정책 게이트웨이 (policy gateway)를 통과한다는 것입니다.

측정 항목 (What to measure)

권한 상속 (permission inheritance)이 제대로 작동하는지 확인할 수 있는 지표를 추적하세요:

• 사유별 거부된 도구 호출 (denied tool calls by reason)
• 작업 유형별 승인율 (approval rate by action type)
• 취소된 위임 (revoked delegations)
• 만료된 위임의 재사용 (expired delegations reused)
• 테넌트 간 거부 테스트 통과 여부 (cross-tenant denial tests passing)
• 실행당 도구 호출 횟수 (tool calls per run)
• 성공적인 위임 작업당 비용 (cost per successful delegated task)
• 과도하게 넓은 범위와 관련된 사고 (incidents involving overbroad scope)
• 승인 수정 및 취소율과 같은 사용자 신뢰 신호 (user trust signals, such as approval edits and cancellation rate)

만약 모든 작업이 승인된다면, 에이전트의 권한이 너무 제한적일 수 있습니다. 만약 어떤 작업도 거부되지 않는다면, 정책이 실제로 제 역할을 하지 못하고 있을 수 있습니다.

개발자를 위한 시사점 (The builder takeaway)

AI 에이전트가 유용하려면 접근 권한이 필요합니다. 하지만 접근 권한이 모델에게 광범위한 키 (keys), 보이지 않는 권한 (invisible permissions), 또는 영구적인 권한 (permanent authority)을 부여하는 것을 의미해서는 안 됩니다.

권한 상속 (Permission inheritance)은 개발자에게 더 나은 절충안을 제공합니다. 즉, 에이전트가 사용자의 제한된 권한 (bounded authority) 내에서, 특정 작업에 대해, 모든 도구 호출 (tool call) 시 영수증 (receipts), 권한 취소 (revocation), 그리고 정책 검사 (policy checks)를 거치며 행동할 수 있게 합니다.

이것이 바로 인상적인 데모 수준을 넘어 사용자가 실제로 신뢰할 수 있는 에이전트 워크플로 (agent workflows)로 나아가는 방법입니다.

FAQ

AI 에이전트 권한 상속이란 무엇인가요?

AI 에이전트 권한 상속 (AI agent permission inheritance)은 에이전트가 현재 사용자의 권한 (permissions), 테넌트 (tenant), 동의 (consent), 그리고 워크플로 모드 (workflow mode)로부터 파생된, 일시적이고 작업 범위가 지정된 권한 (task-scoped authority)을 부여받는 패턴입니다. 에이전트는 광범위한 API 키 (API keys)나 가공되지 않은 자격 증명 (raw credentials)을 받지 않습니다.

권한 상속이 OAuth와 동일한가요?