대부분의 에이전트 플랫폼은 단일 권한 모델을 제공합니다. 즉, 에이전트가 권한을 부여받았거나 그렇지 않거나 둘 중 하나이며, 그 상태는 에이전트가 수행하도록 요청받을 수 있는 모든 작업에 적용됩니다. 이러한 모델은 한 팀이 하나의 작업을 위해 하나의 에이전트를 운영할 때는 문제없이 작동합니다. 하지만 팀이 동일한 시스템을 대상으로 여러 작업을 수행하기 위해 여러 에이전트를 운영하는 순간 문제가 발생하기 시작하며, 이는 2026년 대부분의 엔지니어링 조직(engineering orgs)에게 있어 예외적인 사례가 아닌 이미 일반적인 상황입니다.

글로벌 액세스 모델이 실제로 부여하는 것

글로벌한 에이전트 수준의 권한은 사실 단 하나의 결정이 아닙니다. 그것은 해당 에이전트가 앞으로 내려야 할 모든 결정이 사전에 승인된 상태를 의미합니다. 에이전트 ID(agent identity)에 관한 Microsoft의 가이드라인은 이로 인해 발생하는 실패 모드(failure mode)를 직접적으로 지적합니다. 에이전트는 종종 할당된 어떠한 작업이라도 완료할 수 있도록 충분히 광범위한 권한을 부여받게 되는데, 이는 금융 데이터를 분석하기 위해 구축된 에이전트가 특정 분석에 필요한 범위를 훨씬 넘어선 기록, 비용 보고서 및 공급업체 계약에 대한 상시 액세스 권한을 갖게 될 수 있음을 의미합니다 (Microsoft Learn). 동일한 출처에서는 이러한 문제의 조직 전체 버전으로 **에이전트 확산 (agent sprawl)**을 언급하며, 개별 에이전트가 무엇에 접근할 수 있는지에 대한 중앙 집중식 가시성 없이 팀 전체로 에이전트가 급격히 늘어나는 현상을 지적합니다.

이 문제가 생각보다 포착하기 어려운 데에는 구조적인 이유가 있습니다. 전통적인 IAM(Identity and Access Management)은 요청을 수행하는 주체의 신원을 확인하고 해당 신원의 권한을 적용합니다. 일단 에이전트가 동작을 실행하게 되면, 시스템은 요청한 사용자가 아닌 에이전트의 신원을 확인합니다. 이는 제한된 액세스 권한을 가진 사용자가 개별 권한 규칙을 위반하지 않고도 에이전트를 통해 직접적으로는 얻을 수 없는 결과를 얻을 수 있음을 의미합니다 (The Hacker News).

글로벌 대 작업 수준: 모델이 실제로 차이 나는 지점

글로벌 대 작업 수준: 모델이 실제로 차이 나는 지점

이러한 틀은 최근 에이전트 보안에 관한 학술 연구에서 직접적으로 나온 것입니다. AgentSentry라는 논문은 에이전트를 위한 작업 중심의 접근 제어(task-centric access control)를 제안하며, 권한은 에이전트 자체에 묶여서는 안 되며 특정 사용자 승인 작업을 수행하는 생애 주기와 함께 생성되고 부여되며 취소되어야 한다고 주장합니다(arXiv). AI 에이전트를 인증하는 관련 논문은 이를 더 나아가 작업 범위 지정(task scoping) (에이전트가 수행할 수 있는 작업 또는 워크플로우)과 리소스 범위 지정(resource scoping) (작업을 수행하는 동안 사용할 수 있는 데이터 또는 시스템)으로 분리합니다. 전자가 좁아지면 후자도 자동으로 좁아지는 경향이 있습니다(arXiv).

아무것도 고장 나기 전에도 팀들이 광범위한 접근을 거부하는 이유

작업 수준 범위 지정(task-level scoping)의 필요성은 보통 보안 논거로 제시되지만, 그 이면에는 진지하게 받아들일 만한 행동적 근거가 있습니다. _Decision Support Systems_에 발표된 자기 확증 이론(self-affirmation theory)에 기반한 연구에 따르면, 시스템이 사람이 무엇을 넘겨주는지 범위 지정하지 않고도 자체적으로 작업을 수행하겠다고 제안할 때, 이는 개인의 역량감에 대한 경미한 위협으로 인식되며, 그 반응은 위임 의향을 측정 가능하게 감소시킵니다(ScienceDirect). 별도로, AI 위임을 연구하는 연구자들은 세분성(granularity)을 신뢰나 인식된 위험과는 구별되는 독립적인 변수로 취급합니다(arXiv).

실제적으로는 엔지니어들이 스프린트 기간 동안 명확하게 범위가 지정된 다섯 가지 작업에 대해서는 에이전트를 주저 없이 승인하지만, 같은 에이전트에게

현재 도구에서 나타나는 방식

이론에 그치지 않고 이미 구현되어 출시되고 있는 몇 가지 수렴하는 패턴들이 있습니다:

• 루트 자격 증명 대신 스코프가 지정된 OAuth 토큰. 전체 API 표면을 커버하는 하나의 키 대신, 캘린더 읽기, 이메일 보내기, 연락처 보기와 같은 세분화된 스코프를 사용합니다 (Stytch).
• 에이전트 동작을 위해 특별히 구축된 RBAC(역할 기반 접근 제어). 인간 계정이 구성되는 방식과는 별개로, 특정 에이전트에 대한 권한 변경이 모든 에이전트의 기능을 조용히 바꾸지 않도록 합니다 (Sendbird).
• 역할 기반 다중 에이전트 프레임워크. CrewAI는 '크루(crew)' 내의 각 에이전트에 고유한 역할과 스코프를 할당하며, 하나의 모델이 모든 기능을 보유하는 방식과는 다릅니다. 이 접근 방식은 현재 50,000개의 GitHub 스타와 거의 백만 건에 가까운 월간 다운로드를 기록하고 있습니다 (DataCamp).
• 빌드 플랫폼의 작업 라우팅 전문 에이전트. 8080.ai의 다중 에이전트 설정은 들어오는 각 작업을 일치하는 전문가, 아키텍처, 프론트엔드, 백엔드, 배포에 할당하고 감독 모델을 통해 처리하며, 개별 에이전트의 동작 기록은 하나의 공유된 ID 아래가 아닌 별도로 기록됩니다 (8080.ai). 여기서 스코핑은 추가되는 별도의 권한 기능이 아니라, 플랫폼 자체가 작업을 작업별로 분할하는 방식의 부산물입니다.

오늘 에이전트 권한을 설계하는 팀들을 위한 시사점

글로벌 온/오프 스위치가 틀렸다고 할 수는 없습니다. 다만 다중 에이전트 환경에서는 잘못된 기본값일 뿐입니다. 여전히 사고 발생 시 모든 것을 일시 중지하거나, 에이전트를 완전히 종료하는 '외부 경계'로서의 역할은 남아 있습니다. 변화하고 있는 것은 팀들이 가장 먼저 손을 대는 제어 방식입니다. 작업 수준 스코핑(Task-level scoping)은