티켓은 화요일에 접수되었습니다. AI 어시스턴트는 Jira, Confluence, Slack — 표준 기업 생산성 스택(enterprise productivity stack)에 연결되어 있었습니다. 한 제품 관리자(Product Manager)가

하지만 모델은 "이 사용자가 무엇을 검색하려고 의도했는가?"라고 묻지 않습니다. 대신 "이 질문에 답변하는 데 무엇이 관련이 있는가?"라고 묻습니다. 이 두 질문은 서로 다른 결과 집합을 반환하며, 그 사이의 간극이 바로 권한 경계 붕괴 (Authorization Boundary Collapse)가 발생하는 지점입니다. API는 신원 (Identity)을 검증합니다. LLM은 컨텍스트 (Context)를 집계합니다. 전통적인 기업용 권한 부여 (Authorization)는 대부분의 아키텍트가 암묵적으로 이해하고 있는 3계층 모델로 작동합니다: 인증 (Authentication) — 당신은 누구인가? 신원을 검증하고, 세션을 확인하며, 자격 증명을 체크합니다. 권한 부여 (Authorization) — 당신은 무엇을 할 수 있는가? RBAC (역할 기반 액세스 제어), ACL (액세스 제어 목록), 정책 집행. 이것이 대부분의 기업 보안 투자가 이루어지는 영역입니다. 맥락적 권한 부여 (Contextual authorization) — 이 특정 워크플로에서 당신이 무엇을 하려고 의도했는가? 이 계층은 대부분의 기업 권한 아키텍처에는 존재하지 않는데, 전통적인 시스템에는 이것이 필요하지 않았기 때문입니다. 데이터베이스 쿼리는 당신이 요청한 것을 정확히 반환합니다. REST 엔드포인트는 정의된 리소스를 반환합니다. 응답의 범위 (Scope)는 요청에 의해 결정됩니다. LLM은 이 세 번째 계층을 깨뜨립니다. 10개의 기업 시스템에 연결된 모델은 하나의 리소스를 검색하는 것이 아니라, 접근 가능한 모든 시스템에 걸쳐 프롬프트와의 관련성에 따라 정렬된 컨텍스트를 집계합니다. 사용자의 의도("사고 이력에 대해 알려줘")가 모델의 검색 범위가 되며, 그 범위는 사용자가 보았어야 하는 것이 아니라 모델이 접근할 수 있는 것에 의해서만 제한됩니다. 결과적으로, AI 워크플로는 API 계층에서의 모든 개별 권한 확인을 충족하면서도, 해당 정책 뒤에 숨겨진 조직의 의도를 위반하는 응답을 반환할 수 있습니다. 모든 호출은 권한을 승인받았습니다. 하지만 집계는 승인되지 않았습니다. 권한 경계 붕괴 (Authorization Boundary Collapse). 이 실패 패턴에는 이름이 있습니다: 권한 경계 붕괴 (Authorization Boundary Collapse) — AI 워크플로가 자신이 수행 중인 사용자 의도보다 더 넓은 액세스 범위 (Access scopes)를 상속받는 순간을 의미합니다. 이는 권한 오류 (Permissions failure)와는 다릅니다. 권한 자체는 올바르게 설정되어 있었습니다.

"이 사용자가 접근할 수 있도록 허용된 것"과 "이 문맥에서 이 사용자가 접근하도록 의도된 것" 사이의 경계가 단순히 정의되지 않았습니다. 이는 기업용 인증 인프라가 접근 가능한 모든 것에 대해 측면으로 집계(aggregate laterally)하는 AI 시스템이 아니라, 의도적이고 범위가 지정된(scoped) 요청을 위해 구축되었기 때문입니다. 권한 경계 붕괴 (Authorization Boundary Collapse)는 기업용 AI 배포 시 예측 가능한 패턴으로 나타납니다. 예를 들어, 인사(HR), 재무, 엔지니어링 시스템에 연결된 기업용 코파일럿(Copilot)이 인원 계획(headcount planning)에 대해 질문받았을 때 급여 정보를 반환하는 경우가 있습니다. 이는 모델의 연결 범위에 인사 시스템이 포함되어 있고, "인원 계획"이 보상 데이터와 의미론적으로 인접(semantically adjacent)하기 때문입니다. Slack과 티켓팅 시스템에 접근 권한이 있는 지원 AI가 고객 문제를 요약할 때 내부 에스컬레이션(escalation) 논의 내용을 드러내는 경우도 있습니다. 이는 해당 고객에 대한 내부 스레드가 모델의 Slack 통합 범위 내에 있기 때문입니다. 저장소와 문서에 접근 권한이 있는 개발자 어시스턴트가 서비스의 에러 처리(error handling)에 대해 질문받았을 때 보안 아키텍처 세부 정보를 반환하는 경우도 있습니다. 이는 위협 모델(threat model) 문서가 엔지니어링 런북(runbook)과 동일한 Confluence 공간에 존재하기 때문입니다. 이 중 그 어느 것도 버그가 아닙니다. 그 어떤 것도 접근 검토(access review)를 통해 포착되지 않았을 것입니다. 개별 권한은 모두 유효했습니다. 워크플로 권한 부여(workflow authorization)가 정의되지 않았을 뿐입니다.

기업용 인증의 숨겨진 가정 (The Hidden Assumption in Enterprise Auth)
아키텍처는 모든 요청이 의도적이라고 가정했습니다. 이 가정은 기업용 인증이 설계되고 집행되는 방식에 내재되어 있으며, 수십 년 동안 잘 유지되어 왔습니다. 전통적인 시스템은 측면 문맥(lateral context)을 생성하지 않고 명시적인 요청에만 응답하기 때문입니다. 사용자가 데이터베이스를 쿼리하면 쿼리가 범위를 정의합니다. 사용자가 API를 호출하면 엔드포인트(endpoint)가 리소스를 정의합니다. 요청과 응답은 권한 정책(authorization policy)이 제어할 수 있는 직접적이고 경계가 있는 관계를 가집니다. 반면 "이 고객 문제에 대한 문맥을 알려줘"를 처리하는 AI 어시스턴트는 경계가 있는 요청을 갖지 않습니다.

그것은 접근 가능한 모든 연결된 시스템을 탐색함으로써 충족할 의미론적 목표 (semantic goal)를 가지고 있습니다. 모델은 Slack 연동 기능이 내부 에스컬레이션 스레드 (internal escalation thread)를 노출해서는 안 된다는 사실을 알지 못합니다. 모델은 단지 그 스레드가 관련이 있다는 사실을 알고 있을 뿐입니다. 관련성 (Relevance)과 권한 부여 (Authorization)는 서로 다른 속성입니다. 그리고 대부분의 기업용 권한 부여 인프라 (auth infrastructure)는 이 중 하나만을 강제합니다.

Architect's Verdict: 만약 모델이 시스템 전반에 걸쳐 데이터를 집계 (aggregate)할 수 있다면, 권한 부여는 API 계층 (API layer)뿐만 아니라 워크플로 계층 (workflow layer)에서도 존재해야 합니다. 이는 각 AI 워크플로에 대해 다음 사항을 정의해야 함을 의미합니다: 어떤 데이터 소스가 범위 (scope) 내에 있는지, 어떤 검색 의도 (retrieval intent)가 권한을 부여받았는지, 그리고 이 문맥에서 이 사용자에게 어떤 응답 콘텐츠가 허용되는지 말입니다. 이러한 정의는 연결된 시스템의 권한으로부터 추론되는 것이 아니라, 모델이 데이터를 집계하기 전에 강제되는 명시적인 정책 (explicit policy)으로서 존재해야 합니다.

에이전트형 배포 (agentic deployments) — 단순히 검색만 하는 것이 아니라 행동을 취하는 AI 시스템 — 의 경우, 공격 표면 (surface area)은 검색에서 실행 (execution)으로 확장됩니다. 검색 워크플로에서의 권한 부여 경계 붕괴 (Authorization Boundary Collapse)는 당혹스러운 일입니다. 쓰기 권한 (write access)이 있는 에이전트형 워크플로에서의 붕괴는 사고 (incident)입니다. 모델은 답변했습니다. 아키텍처는 그것이 모델이 권한을 부여받은 것과 동일하다고 가정했습니다.

추가 리소스
Agentic AI Has a Control Plane Problem — AI 시스템이 스택 전반에 걸쳐 운영 권한을 상속받을 때
Autonomous Systems Don't Fail. They Drift Until They Break. — 실시간 인간의 권한 부여 없이 작동하는 AI 시스템을 위한 런타임 거버넌스 (runtime governance)
AI Infrastructure Architecture — 전체 AI 인프라 전략 및 거버넌스 모델
OWASP Top 10 for LLM Applications — 권위 있는 LLM 보안 실패 패턴 참조

원문 게시처: rack2cloud.com