AI 에이전트가 실제로 도달할 수 있는 범위: 실제 인프라에서의 에이전트 액세스 매핑

AI 에이전트는 운영 관점에서 보면 자격 증명을 보유한 하나의 프로세스입니다. 누군가가 에이전트에게 서비스 계정, API 키 또는 IAM 역할을 부여하여 작업을 수행하게 하고, 그 순간부터 에이전트는 그 자격 증명이 도달하는 모든 것에 도달할 수 있습니다. 직무 설명에는 “매일 밤 청구 데이터를 내보내기”라고 적혀 있었습니다. 자격 증명은 “프로덕션 데이터베이스, 그리고 객체 스토어, 그리고 큐에 대한 읽기 및 쓰기”라고 말하고 있었습니다. 누구도 이 둘을 조율하지 않았습니다. 몇 달 후, 팀의 그 누구도 마땅히 자명해야 할 질문에 답하지 못합니다. 이 에이전트가 실제로 도달할 수 있는 범위는 어디까지이며, 실제로 무엇을 건드리는가?

이 간극은 가설이 아닙니다. 독립적인 업계 조사(CSA/Token)에 따르면, 약 82%의 조직이 자신들이 모르는 AI 에이전트를 운영하고 있는 반면, 실시간 인벤토리를 유지하는 곳은 약 21%에 불과합니다. 볼 수 없는 것은 거버넌스할 수 없으며, 현재 대부분의 환경은 자신들의 에이전트를 전혀 보지 못합니다 — 각 에이전트와 그것이 도달할 수 있는 리소스를 연결하는 엣지(edge)는 말할 것도 없습니다.

일상적으로 뒤섞이는 세 가지 서로 다른 질문

“이 에이전트가 무엇에 도달할 수 있는가”에 답하기 어려운 이유는, 이 질문이 세 가지 별개의 질문을 하나로 뭉뚱그리기 때문입니다. 이 셋을 구분된 상태로 유지하는 것이 핵심의 전부입니다.

• 보유(Held) — 에이전트가 소유한 자격 증명. 토큰, 키, 역할 바인딩 등입니다. 이는 정체성에 관한 사실입니다. 에이전트가 어떤 문의 열쇠를 가지고 있는지입니다.
• 허용(Permitted) — 그 자격 증명이 정책에 따라 수행하도록 허락된 것: IAM 권한 부여, 데이터베이스 역할, 네트워크 규칙 등입니다. 이는 정책에 관한 사실이며, 거의 항상 누군가의 기억보다 넓습니다. 권한은 누적되지만 누구도 회수하지 않기 때문입니다.
• 관측(Observed) — 에이전트가 실제로 수행하는 모습이 목격된 것: 어떤 리소스에 도달했는지, 그리고 각 액세스가 읽기였는지 쓰기였는지입니다. 이는 행동에 관한 사실이며, 수집하기 전까지는 어디에도 존재하지 않습니다.

대부분의 보안 도구는 허용에서 멈춥니다. IAM을 읽고 에이전트가 청구 내보내기 버킷에 쓸 수 있다고 알려줍니다. 이는 필요하지만 불충분합니다. “할 수 있다”는 잠재적 권한 수천 개의 집합이며, 사람은 수천 개의 “어쩌면”을 분류할 수 없기 때문입니다. 대화의 양상을 바꾸는 것은 관측을 허용 옆에 나란히 놓고 그 차이를 들여다보는 것입니다.

액세스 맵

액세스 맵은 그러한 엣지들의 그래프입니다. 발견된 모든 에이전트에 대해, 그것이 도달할 수 있는 각 리소스로 엣지를 그리고, 그 엣지를 가로질러 실제로 관측된 내용을 주석으로 표기합니다. 중요한 단위는 엣지이며, 엣지에서 가장 중요한 주석은 읽기/쓰기 구분입니다.

**R(읽기)**는 에이전트가 데이터를 변경하지 않고 가져왔음을 의미합니다. SELECT, GET, 파일 읽기 등입니다. **RW(읽기/쓰기)**는 상태를 변경했음을 의미합니다. INSERT/UPDATE/DELETE, 객체 스토리지로의 PUT, 스키마 마이그레이션 등입니다. 이 둘의 폭발 반경은 비교 대상이 되지 않습니다. 민감한 테이블에 대한 읽기 엣지는 노출(exposure)에 관한 문제입니다. 쓰기 엣지 — 특히 의도되지 않은 것 — 는 무결성과 사고(incident)에 관한 문제입니다. 이 둘을 동일한 “액세스”로 취급하는 것이 바로 팀이 정작 중요한 발견을 놓치는 방식입니다.

맵이 구축된 후 단일 에이전트의 한 행은 다음과 같은 모습입니다.

첫 번째 행을 보십시오. 이 내보내기 작업은 prod-postgres에서 읽고 그 결과를 s3://billing-exports에 쓰도록 의도되었습니다. 소스에서 읽고, 목적지에 쓴다는 것입니다. 그러나 이 작업에 부여된 자격 증명은 데이터베이스에 대한 RW를 허락하며, 수집기는 이 작업이 prod-postgres에 쓰는 것을 관측했습니다 — 누구도 검토하거나 의도하지 않았고 현재 설명할 수도 없는, 프로덕션 기록 시스템(system of record)에 대한 변경입니다. Permitted 열은 이것이 줄곧 허용되어 있었다고 조용히 말하고 있었습니다. 이것이 바로 빤히 보이는 곳에 앉아 있는 사고의 씨앗이며, Observed 열이 없다면 표시할 만한 단서가 전혀 없습니다.

허용에서 관측을 빼면 드리프트가 남는다

핵심 산출물은 그 차이(diff)입니다. **최소 권한 드리프트(least-privilege drift)**는 한 열에서 다른 열을 뺄 때 얻어지며, 양방향으로 작동합니다.

• 허용되었으나 한 번도 관측되지 않음 — 에이전트는 internal-metrics-api에 도달할 수 있지만, 전체 관측 기간 동안 한 번도 그러지 않았습니다. 이것은 죽은 범위(dead scope)입니다. 동작에는 손대지 않으면서 공격 표면을 줄이기 위해 안전하게 회수를 제안할 수 있는 권한입니다.
• 검토된 범위를 넘어선 관측 — 누구도 승인하지 않은 prod-postgres로의 쓰기입니다. 이것이 신호가 강한 발견입니다. 프로비저닝 시점에 누군가에게 물었다면 승인하지 않았을 행위가 실제로 일어나고 있는 것입니다.

두 번째 범주가 가장 핵심적인 위험이며, 정직한 제품이라면 이를 결코 지어내지 않습니다. 모든 관측된 엣지는 **신뢰도 수준(confidence level)**을 동반합니다 — 보강 신호와 함께 특정 에이전트 정체성에 결부된 행위는 attributed, 증거가 약한 경우는 approximate입니다. 추측을 확실성으로 세탁하는 대신 그 차이를 그대로 보여줍니다. 뒷받침할 수 없는 발견은 발견이 없는 것보다 나쁩니다.

수동적으로 발견하고, 에이전트별로 귀속한다

두 가지 설계상의 선택이 이를 또 하나의 대시보드가 아니라 신뢰할 수 있는 것으로 만듭니다.

첫째, 발견(discovery)은 **수동적(passive)**입니다. 수집기는 관측합니다 — 로그, OpenTelemetry 트레이스, PostgreSQL의 pgAudit 같은 데이터베이스 감사 스트림, 그리고 그라운드 트루스(ground-truth)의 최후 보루로서 커널 수준의 eBPF 등입니다 — 그리고 에이전트의 데이터 경로에 위치하지 않습니다. 필수적인 프록시가 없습니다. 수집기가 실패하더라도 에이전트는 계속 동작합니다. 관측 가능성은 저하되지만 프로덕션은 그렇지 않습니다. 핵심 인프라를 거버넌스하는 것이 존재 이유인 시스템에서, 이 비대칭성이 바로 그 설계입니다. 하방 위험은 낮고, 신호는 강합니다.

둘째, 모든 행위는 공유 서비스 계정이 아니라 특정 에이전트 정체성에 귀속됩니다. 이것이 “내보내기 역할이 02:14에 prod-postgres에 썼다”라고 말하는 감사 원장(audit ledger)과, 어떤 에이전트가 누구의 소유 아래서 어떤 의도된 범위에 대해 그렇게 했는지를 말하는 원장의 차이입니다. 에이전트별 정체성은 최소 권한 원칙이 조금이라도 의미를 갖기 위한 전제 조건입니다 — 이것이 없으면 행위는 목격될 수는 있어도 책임 있는 소유자에게로 추적할 수는 없습니다.

저장되는 것은 오직 엣지와 읽기/쓰기 사실뿐입니다. 맵은 관계를 기록합니다 — 에이전트 대 리소스, R 또는 RW — 페이로드도, 읽힌 행(row)도, 시크릿도 기록하지 않습니다. 시크릿이나 PII를 포함할 수 있는 입력값은 무엇이든 기록되기 전에 마스킹되고 시크릿 스캔을 거칩니다. 이 그래프는 바로 액세스 맵이기 때문에 민감하며, 따라서 거버넌스를 가능하게 하는 최소한만을 보유하고 그 이상은 보유하지 않도록 설계되어 있습니다.

에이전트 자체 생태계에서 나오는 신호는 도움이 되지만 그 자체만으로 신뢰되지는 않습니다. MCP 서버는 readOnlyHint 같은 주석을 통해 어떤 도구가 읽기 전용이라고 광고할 수 있습니다. MCP 명세에 따르면 그러한 힌트는 신뢰되지 않으며(untrusted) 반드시 보강되어야 하고 결코 맹목적으로 믿어서는 안 됩니다. 읽기 전용이라고 주장하고서 실제로는 쓴 도구를 잡아내는 것은 커널 수준의 관점입니다.

맵이 일단 존재하면, 다음 단계는 시행(enforcement)입니다. 내보내기 작업을 데이터베이스에서 읽기 전용으로 고정하고, 쓰기를 거부하며, 단순히 로깅하는 대신 경보를 발생시키는 것 — 사고 발생 후 재구성하는 것이 아니라 액세스 시점에 적용되는 정책입니다.

agent "data-export-job" {
  resource "prod-postgres" {
    access = "read"        # intended scope: read source only
    deny   = ["write", "ddl"]
  }
  resource "s3://billing-exports" {
    access = "read-write"  # intended scope: write destination
  }
  on_violation {
    action = "block"
    alert  = "secops"
  }
}

맵은 당신이 작성했어야 할 정책이 무엇인지 알려줍니다. 에이전트가 실제로 필요로 했던 단 하나의 액세스와, 한 번도 사용하지 않은 열두 개의 액세스를 보여주기 때문입니다. 이것이 최소 권한을 추측하는 것과 그라운드 트루스로부터 도출하는 것의 차이입니다.

만약 당신의 환경이 오늘 답할 수 없는 질문이 바로 이것 — 각 에이전트가 무엇에 도달할 수 있으며, 실제로 무엇을 건드리는가 — 이라면, 액세스 맵은 정확히 그것을 위한 것입니다. 제품 개요는 발견과 허용-대-관측 차이를 따라가며 설명합니다. 아키텍처는 수동 수집, 에이전트별 정체성, 감사 원장이 당신의 에이전트 데이터 경로에 결코 위치하지 않으면서 어떻게 맞물리는지를 다룹니다.