Agent Access Model(작업 기반 에이전트 권한 모델)

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

이 글은 에이전트(작업 단위의 소프트웨어 주체)가 사람 기반 권한 모델을 무너뜨리는 현실을 전제로, 각 행동을 작업 템플릿과 누적된 그래프 상태로 재검증하는 Agent Access Model(AAM)을 제안합니다. 핵심 구성요소는 작업-범위 자격증명(Identity Broker), 작업-스코프 Access Engine, 허니스와 네트워크로 이루어진 Mediation Layer, 그리고 상태 축소를 담당하는 Trust Ratchet이며, 집행 이벤트는 Agent Activity Log에 기록돼 Grant Review Loop로 정책을 개선하는 근거가 됩니다. 멀티플레이어 접근 제어는 여전히 해결되지 않은 과제로 남아 있으며, 우선 단일 작업 경계에 대해 짧은 수명 토큰·런타임 집행·증거 기반 감사부터 적용하라고 권고합니다.

섹션별 상세

기업 보안이 BeyondCorp를 통해 네트워크 기반 신뢰를 제거한 이후, 글은 인간 중심의 '주체(principal)' 모델이 에이전트라는 새로운 소프트웨어 주체로 바뀌면서 기존 제어가 맞지 않게 된 문제를 문제 제기와 함께 정리합니다. 에이전트는 짧은 수명과 기계 속도로 대규모 작업을 수행하므로 기존의 장기적 자격증명과 사람 중심 탐지·제어는 실시간성과 짧은 수명 요구를 충족하지 못합니다. 이 차이가 곧 AAM을 설계해야 하는 배경이라는 점을 작업 흐름·위험 패턴의 관점에서 연결해 보여 줍니다.

Agent Access Model(AAM)은 '런(run)을 신뢰하지 말라'는 단일 규칙을 출발점으로 하여, 각 행동을 작업(task)과 그동안의 그래프 상태에 대해 다시 권한 검증하는 구조를 제안합니다. 권한은 디스패치 시점에 확정되는 작업 템플릿과 발행된 작업 범위 자격증명으로 한정되고, 실행 도중 발생한 'Trust Ratchet' 상태 전환은 그래프의 남은 능력을 일방향으로 축소하며 엔포스먼트를 동기화합니다. 이렇게 하면 복잡한 위험 판단을 줄여 결정 지점에 요구되는 심사 범위를 좁히고, 방어 표면을 실행 경로(harness, 네트워크) 쪽으로 옮겨 기계 속도에서 실시간으로 차단할 수 있다는 설계 논리가 뒷받침됩니다.

근거

자격증명은 작업 수명에 맞춰 짧게 발급되고 송신자 제약(sender-constrained)을 가져야 한다. — 본문 4.1항에서 OAuth 2.0 Token Exchange(RFC 8693)와 DPoP(RFC 9449)를 사례로 들며 송신자 제약과 작업-스코프 토큰의 필요성을 기술하고 있음.

아키텍처 관점에서 AAM은 네 가지 능동 제어와 두 개의 보조 시스템을 제안합니다: Agent Identity Broker, Task-Scoped Access Engine, Mediation Layer(harness + 네트워크), Trust Ratchet가 능동 경로를 구성하고, Agent Activity Log와 Grant Review Loop가 증거 수집과 정책 개선을 담당합니다. Identity Broker는 작업 범위 자격증명을 발급하고 Task-Scoped Access Engine은 디스패치한 템플릿과 발행자 권한을 교차해 실행 상한을 계산하며, Mediation Layer는 도구 호출과 이그레스 경로에서 실제 요청 표현을 고정해 집행 지점에서 검증·집행합니다. 이 조합은 권한이 선언된 범위를 벗어나지 못하도록 실행 경로에서 실패-폐쇄(fail-closed)하도록 설계되어야 한다는 구현 요구와 제약을 명확히 합니다.

Figure 2. The Agent Activity Log and Grant Review Loop support later policy changes. — Diagram이 도식은 능동 제어(Access Engine·Identity Broker·Mediation Layer·Tools)와 보조 경로(Trust Ratchet·Agent Activity Log·Grant Review Loop)의 관계를 흐름으로 정리합니다. 특히 에이전트 활동 로그가 집행 지점에서 캡처된 이벤트를 중앙에 모아 Grant Review Loop로 전달하고, 그 루프가 템플릿 변경 제안을 생성해 향후 작업에만 적용한다는 점을 시각적 화살표로 연결해 근거-기반 권한 조정 과정을 보여 줍니다. 이 그림은 증거 수집과 정책 개선의 책임 경로를 검증 가능하게 만드는 아키텍처 요구를 강조합니다.

근거

작업의 권한 상한은 디스패치 시점에 작업 템플릿과 주체 권한의 교차로 결정되며, 런타임에 에이전트가 협상해 확장할 수 없다. — Task-Scoped Access Engine 설명에서 템플릿이 구성 단위이며 디스패치 시점에 상한이 확정된다는 서술과, 템플릿 기반 정책 적용 흐름이 제시됨.

Trust Ratchet는 보호된 입력이나 분류 결과가 감지되면 작업 그래프의 능력을 단계적으로 줄여 데이터 유출 경로를 차단하는 메커니즘으로서 동작합니다. 이 메커니즘은 정책으로 어떤 전환이 능력을 제거할지 선언하고, 허니스(harness)와 네트워크 등 모든 집행 지점이 새로운 상태를 확인·승인할 때까지 보호된 응답을 버퍼링한 뒤 모든 확인이 도착하면 응답을 해제하는 방식으로 동기화를 보장합니다. 구현상 compare-and-set 같은 직렬화 기법과 캐시·연결 정리 로직을 요구하며, 어떤 실패나 타임아웃이 발생하면 전환을 실패-폐쇄로 처리해 위험을 열어두지 않도록 하는 운영 규칙이 근거로 제시됩니다.

Figure 1. The Trust Ratchet holds protected data until the task's declared restrictions are active. — Diagram이 다이어그램은 Trust Ratchet 흐름을 Baseline에서 Restricted로 전환하며 보호된 읽기 이후에 능력을 축소하는 동작을 시각화합니다. 왼쪽에서 시작해 'Read Protected Data' → 'Apply Restrictions' → 'Update Enforcement' → 'Release Response'로 이어지는 단계는 응답을 모델 컨텍스트 밖에 보관하고 모든 집행 지점이 새 상태를 채택할 때까지 해제를 지연시키는 동기화 요구를 명확히 보여 줍니다. 이 그림은 Trust Ratchet의 핵심 설계인 '능력은 작업 중에만 줄어들고, 제거된 권한은 새로 인증된 작업에서만 복원된다'는 운영 규칙을 직관적으로 보완합니다.

근거

Trust Ratchet은 보호된 입력이 확인되면 작업 그래프의 권한을 일방향으로 축소하고, 모든 집행 지점의 확인을 받아야 응답을 해제한다. — 본문 4.4항에 Trust Ratchet 동작 순서(상태 전환, 집행 지점 확인, 버퍼링 후 해제)와 실패-폐쇄 동작을 설명한 도식과 사례가 포함되어 있음.

구체적 사례로는 야간 정산(reconciliation) 작업을 통해 AAM의 동작을 단계별로 추적합니다. 스케줄러가 작업을 디스패치하면 Access Engine이 템플릿과 주체 권한을 교차해 10분짜리 상한을 정하고 Identity Broker가 작업 범위 토큰을 발급합니다. 이후 프로세서 보고서를 허니스가 받아 분류 결과가 '보호됨'으로 나오면 Trust Ratchet이 프로세서·지원 경로를 닫고 검증이 완료된 이후에만 모델 컨텍스트로 데이터를 해제하며, 모델이 인젝션된 지시문을 통해 외부 전송을 시도해도 허니스와 네트워크 양쪽에서 차단되는 흐름을 예로 들어 동작 원리와 증거 기록 방식을 보입니다.

Figure 3. Protected input closes processor and support paths while preserving the approved finance output. — Diagram이 도식은 야간 정산 예시의 시간축을 따라 디스패치·작업 실행·제한 전환·거부 기록·고정된 결과 게시의 순서를 보여 줍니다. 사례의 각 단계에 Access Engine과 Identity Broker의 역할, 허니스가 보호된 응답을 버퍼링하는 시점, Trust Ratchet이 외부 경로를 닫는 시점, 그리고 허니스와 네트워크 양쪽에서 거부가 발생했을 때 로그가 남는 흐름을 일치시켜 실무 구현의 체크포인트를 명확히 합니다. 실무자는 이 그림을 통해 작업 템플릿 설계·토큰 수명·버퍼링 시점·출력 스키마 제한 등을 검토하게 됩니다.

멀티플레이어 접근 제어(multi-principal access control)는 여전히 열린 문제로 남아 있으며, 문서에서는 에이전트가 여러 사람을 대신해 작동하는 환경에서 권한·출처 라벨을 세밀하게 추적하지 않으면 권한 누수·캐시 재사용 등으로 프라이버시 침해가 발생할 수 있음을 논리적·실험적 근거와 함께 제시합니다. 한 방향의 해결책으로는 컨텍스트의 각 아이템에 권한·출처 라벨을 붙여 서빙 경로에서 현재 요청자의 권한과 비교해 검증하는 방안을 제시하지만, 생성 과정에서 모델이 라벨을 보전할 수 없으므로 출력 전후의 외부 집행 지점에서 직접 검사해야 한다는 한계까지 명확히 밝힙니다.

용어 해설

BeyondCorp: — BeyondCorp는 네트워크 위치에 따라 신뢰를 부여하지 않고 사용자 신원과 디바이스 상태로 접근을 결정하는 Zero Trust 설계의 초기 구현으로, 사람 사용자를 전제로 한 액세스 결정을 핵심으로 삼습니다.
제로 트러스트(Zero Trust): — 제로 트러스트는 네트워크 경계 대신 개별 인증·권한 검사로 접근을 통제하는 원칙으로, 요청의 출처 대신 발행된 신원·디바이스 정보와 실시간 정책으로 허가를 판단합니다.
작업 범위 자격증명(Task-scoped credential): — 작업 범위 자격증명은 에이전트의 특정 실행(run)에 한정되어 발급되고 해당 작업이 종료되면 만료되며, 발급 시점의 권한 상한을 인코딩하여 장기 키의 재사용을 막습니다.
송신자 제약 토큰(Sender-constrained token): — 송신자 제약 토큰은 토큰 단독으로는 재사용되지 않도록 클라이언트가 보유한 증명키(proof key)와 결합해 요청 단위로 증명을 요구하는 방식으로, 탈취 시 재사용 위험을 줄입니다.
작업 실행 그래프(Task execution graph): — 작업 실행 그래프는 단일 에이전트 실행에 속한 모든 연산·도구 호출·리소스 접근을 포함하는 실행 단위로, AAM에서는 이 그래프의 누적 상태가 권한 축소의 기준이 됩니다.

기술

OAuth 2.0 Token Exchange는 작업-스코프 토큰 발급 패턴을 지원하는 표준으로, 문서에서는 토큰의 act 클레임과 중첩된 행위자 표기가 작업 주체 표기와 귀속(attribution)에 어떻게 기여하는지 짚습니다. 이 표준은 AAM의 Identity Broker 구현에서 이용 가능한 기존 프리미티브로 위치합니다.
DPoP(Demonstrating Proof of Possession)는 토큰을 클라이언트 증명키에 묶어 탈취된 토큰 단독으로 재사용할 수 없게 하는 메커니즘을 제공한다는 점에서 AAM의 송신자 제약 요건을 충족하는 참고 사례로 본문에서 다뤄집니다. 다만 DPoP 증명은 HTTP 메서드·URI까지 바인딩하고 본문·쿼리·툴 인수는 포함하지 못하므로 허니스 레이어에서 불변 요청 표현이 필요하다고 명시합니다.
AAuth 초안은 에이전트 대 리소스 신원과 인가를 다루는 작업 단위 식별, 툴 권한, 감사·비동기 인가 같은 개념을 포함해 AAM의 일부 요구를 실현할 수 있는 후보로 언급됩니다. 본문은 AAuth가 작업별 ID와 미션(missions) 같은 개념을 제공하지만 아직 진행 중인 표준임을 함께 지적합니다.
Model Context Protocol(MCP)와 OpenTelemetry/OCSF 같은 관찰 도구는 에이전트 활동 이벤트를 표준화·수집해 SIEM으로 전달하는 경로에서 활용 가능한 기술 스택으로 언급됩니다. 본문은 OpenTelemetry의 생성형 AI 규약과 OCSF의 정규화가 통합 작업을 줄일 수 있다고 제안합니다.

활용 사례

야간 정산(reconciliation) 에이전트는 시스템 레코드에 접근해 여러 원장과 외부 프로세서 보고서를 비교하고 고정된 형식의 요약을 게시하는 작업 흐름에서 AAM을 적용하기에 적합합니다. 이 사례는 작업 템플릿 기반 상한 설정, 보호된 입력 감지 시 Trust Ratchet 트리거, 그리고 허니스와 네트워크의 이중 집행으로 외부 유출을 막는 전체 경로를 검증하는 현실적 예시를 제공합니다. 운영팀은 이 패턴으로 기존 배치 작업·자동화 봇을 순차적으로 재구성할 수 있습니다.
로그·경고 선별(log triage) 에이전트는 민감한 로그를 읽고 요약만 외부로 노출해야 하는 상황에서 AAM의 허니스와 Trust Ratchet로 민감 데이터의 범위를 좁히고 출력 스키마를 제한해 안전하게 운영할 수 있습니다. 이 유스케이스는 분류에 따라 스트림을 버퍼링하고 분류 완료 후에만 요약을 생성하는 운영 규칙이 실무적으로 어떻게 적용되는지 보여 줍니다.
풀 리퀘스트 생성·수정 봇 같은 개발자 자동화는 코드 저장소·이슈 트래커 접근을 작업 범위로 한정하고, 결과물은 고정된 채널·스키마로만 전달하도록 제한해 권한 남용과 의도치 않은 정보 노출을 줄이는 데 AAM을 활용할 수 있습니다. 특히 개발 파이프라인에서 권한 상한을 디스패치 시점에 고정하면 CI·CD 흐름의 안전성을 개선할 수 있습니다.

언급된 리소스

문서BeyondCorp: A New Approach to Enterprise Security

문서RFC 8693 – OAuth 2.0 Token Exchange

문서RFC 9449 – OAuth 2.0 Demonstrating Proof of Possession (DPoP)

문서AAuth protocol (draft)

API DocsModel Context Protocol. Authorization. Specification revision 2026-07-28

문서Open Cybersecurity Schema Framework (OCSF)

문서OpenTelemetry: Generative AI semantic conventions

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

섹션별 상세

근거

자격증명은 작업 수명에 맞춰 짧게 발급되고 송신자 제약(sender-constrained)을 가져야 한다. — 본문 4.1항에서 OAuth 2.0 Token Exchange(RFC 8693)와 DPoP(RFC 9449)를 사례로 들며 송신자 제약과 작업-스코프 토큰의 필요성을 기술하고 있음.

근거

작업의 권한 상한은 디스패치 시점에 작업 템플릿과 주체 권한의 교차로 결정되며, 런타임에 에이전트가 협상해 확장할 수 없다. — Task-Scoped Access Engine 설명에서 템플릿이 구성 단위이며 디스패치 시점에 상한이 확정된다는 서술과, 템플릿 기반 정책 적용 흐름이 제시됨.

근거

Trust Ratchet은 보호된 입력이 확인되면 작업 그래프의 권한을 일방향으로 축소하고, 모든 집행 지점의 확인을 받아야 응답을 해제한다. — 본문 4.4항에 Trust Ratchet 동작 순서(상태 전환, 집행 지점 확인, 버퍼링 후 해제)와 실패-폐쇄 동작을 설명한 도식과 사례가 포함되어 있음.

용어 해설

BeyondCorp: — BeyondCorp는 네트워크 위치에 따라 신뢰를 부여하지 않고 사용자 신원과 디바이스 상태로 접근을 결정하는 Zero Trust 설계의 초기 구현으로, 사람 사용자를 전제로 한 액세스 결정을 핵심으로 삼습니다.
제로 트러스트(Zero Trust): — 제로 트러스트는 네트워크 경계 대신 개별 인증·권한 검사로 접근을 통제하는 원칙으로, 요청의 출처 대신 발행된 신원·디바이스 정보와 실시간 정책으로 허가를 판단합니다.
작업 범위 자격증명(Task-scoped credential): — 작업 범위 자격증명은 에이전트의 특정 실행(run)에 한정되어 발급되고 해당 작업이 종료되면 만료되며, 발급 시점의 권한 상한을 인코딩하여 장기 키의 재사용을 막습니다.
송신자 제약 토큰(Sender-constrained token): — 송신자 제약 토큰은 토큰 단독으로는 재사용되지 않도록 클라이언트가 보유한 증명키(proof key)와 결합해 요청 단위로 증명을 요구하는 방식으로, 탈취 시 재사용 위험을 줄입니다.
작업 실행 그래프(Task execution graph): — 작업 실행 그래프는 단일 에이전트 실행에 속한 모든 연산·도구 호출·리소스 접근을 포함하는 실행 단위로, AAM에서는 이 그래프의 누적 상태가 권한 축소의 기준이 됩니다.

기술

OAuth 2.0 Token Exchange는 작업-스코프 토큰 발급 패턴을 지원하는 표준으로, 문서에서는 토큰의 act 클레임과 중첩된 행위자 표기가 작업 주체 표기와 귀속(attribution)에 어떻게 기여하는지 짚습니다. 이 표준은 AAM의 Identity Broker 구현에서 이용 가능한 기존 프리미티브로 위치합니다.
DPoP(Demonstrating Proof of Possession)는 토큰을 클라이언트 증명키에 묶어 탈취된 토큰 단독으로 재사용할 수 없게 하는 메커니즘을 제공한다는 점에서 AAM의 송신자 제약 요건을 충족하는 참고 사례로 본문에서 다뤄집니다. 다만 DPoP 증명은 HTTP 메서드·URI까지 바인딩하고 본문·쿼리·툴 인수는 포함하지 못하므로 허니스 레이어에서 불변 요청 표현이 필요하다고 명시합니다.
AAuth 초안은 에이전트 대 리소스 신원과 인가를 다루는 작업 단위 식별, 툴 권한, 감사·비동기 인가 같은 개념을 포함해 AAM의 일부 요구를 실현할 수 있는 후보로 언급됩니다. 본문은 AAuth가 작업별 ID와 미션(missions) 같은 개념을 제공하지만 아직 진행 중인 표준임을 함께 지적합니다.
Model Context Protocol(MCP)와 OpenTelemetry/OCSF 같은 관찰 도구는 에이전트 활동 이벤트를 표준화·수집해 SIEM으로 전달하는 경로에서 활용 가능한 기술 스택으로 언급됩니다. 본문은 OpenTelemetry의 생성형 AI 규약과 OCSF의 정규화가 통합 작업을 줄일 수 있다고 제안합니다.

활용 사례

야간 정산(reconciliation) 에이전트는 시스템 레코드에 접근해 여러 원장과 외부 프로세서 보고서를 비교하고 고정된 형식의 요약을 게시하는 작업 흐름에서 AAM을 적용하기에 적합합니다. 이 사례는 작업 템플릿 기반 상한 설정, 보호된 입력 감지 시 Trust Ratchet 트리거, 그리고 허니스와 네트워크의 이중 집행으로 외부 유출을 막는 전체 경로를 검증하는 현실적 예시를 제공합니다. 운영팀은 이 패턴으로 기존 배치 작업·자동화 봇을 순차적으로 재구성할 수 있습니다.
로그·경고 선별(log triage) 에이전트는 민감한 로그를 읽고 요약만 외부로 노출해야 하는 상황에서 AAM의 허니스와 Trust Ratchet로 민감 데이터의 범위를 좁히고 출력 스키마를 제한해 안전하게 운영할 수 있습니다. 이 유스케이스는 분류에 따라 스트림을 버퍼링하고 분류 완료 후에만 요약을 생성하는 운영 규칙이 실무적으로 어떻게 적용되는지 보여 줍니다.
풀 리퀘스트 생성·수정 봇 같은 개발자 자동화는 코드 저장소·이슈 트래커 접근을 작업 범위로 한정하고, 결과물은 고정된 채널·스키마로만 전달하도록 제한해 권한 남용과 의도치 않은 정보 노출을 줄이는 데 AAM을 활용할 수 있습니다. 특히 개발 파이프라인에서 권한 상한을 디스패치 시점에 고정하면 CI·CD 흐름의 안전성을 개선할 수 있습니다.

언급된 리소스

문서BeyondCorp: A New Approach to Enterprise Security

문서RFC 8693 – OAuth 2.0 Token Exchange

문서RFC 9449 – OAuth 2.0 Demonstrating Proof of Possession (DPoP)

문서AAuth protocol (draft)

API DocsModel Context Protocol. Authorization. Specification revision 2026-07-28

문서Open Cybersecurity Schema Framework (OCSF)

문서OpenTelemetry: Generative AI semantic conventions

Agent Access Model(작업 기반 에이전트 권한 모델)

TL;DR

섹션별 상세

용어 해설

기술

활용 사례

언급된 리소스

관련 토론

댓글

관련 기사

AI 에이전트의 정체성 부재가 만드는 권한 경계 취약성

Agent Auth: 자율 에이전트를 위한 인증 프로토콜

에이전트 AI 거버넌스의 첫 30일: 실무 체크리스트

AI 에이전트 신원·권한 관리 문제와 자체 호스팅 신원 제공 도구 공개

에이전트 신원은 설정이 아니라 수명주기다

Agent Access Model(작업 기반 에이전트 권한 모델)

TL;DR

섹션별 상세

용어 해설

기술

활용 사례

언급된 리소스

관련 토론

댓글

관련 기사

AI 에이전트의 정체성 부재가 만드는 권한 경계 취약성

Agent Auth: 자율 에이전트를 위한 인증 프로토콜

에이전트 AI 거버넌스의 첫 30일: 실무 체크리스트

AI 에이전트 신원·권한 관리 문제와 자체 호스팅 신원 제공 도구 공개

에이전트 신원은 설정이 아니라 수명주기다