관리자 도구를 쥔 AI 에이전트, 접근 제어의 사각지대

DEF CON 34에서 뚫린 건 모델이 아니라 접근 모델이었습니다.

2026년 9월 2일, Intigriti 연구진은 고객지원 봇 한 대에 접근해 원래는 가질 수 없어야 할 권한을 얻어냈습니다. 이 봇에는 관리자 도구가 그대로 연결돼 있었습니다. 프로필 정보 수정, 청구 내역 조회, 다른 계정으로 데이터·자금을 이체하는 기능까지, 지금 많은 상용 고객지원 에이전트가 실제로 쥐고 있는 것과 똑같은 도구였습니다. DEF CON 34 버그 바운티 빌리지에서 발표된 이 결과는 단 몇 번의 주말 사이 5만 달러 이상의 포상금으로 이어졌습니다. 프롬프트 인젝션으로 모델을 속여 오작동시킨 사례가 아니었습니다. 문제는 자금을 이동시킬 수 있는 도구를 실행하기 전에, 요청자가 누구인지를 봇이 한 번도 다시 확인하지 않았다는 데 있었습니다. 이미 팀이 상담 업무용 에이전트에 관리자 도구를 넘겨준 상태라면, 이번 주에 답해야 할 질문은 하나입니다. 그 도구를 호출하는 순간 실제로 다시 검증되는 것이 신원인지, 요청 내용인지, 아니면 그저 도구가 존재한다는 사실뿐인지입니다.

DEF CON 34가 찾아낸 것: 신원 확인의 실패

Ayoub과 Inti De Ceukelaire가 쓴 보고서 "고객지원 AI 에이전트 해킹하기"는 이 봇들에 실제로 연결돼 있던 기능을 그대로 짚습니다. "프로필 정보 수정, 청구 내역 조회, 심지어 다른 계정으로 데이터나 자금을 이체하는 것"까지 가능했습니다. 근본 원인은 모델보다 앞단에 있었습니다. "일부 챗봇은 발신자를 계정 소유자와 제대로 대조하지 못한다"는 것입니다. 신원을 위조하거나 지시를 주입하면, 이미 에이전트에 부여된 도구 권한을 그대로 타고 들어갈 수 있습니다. 도구가 실행되는 순간 요청자가 누구인지 다시 확인하는 절차가 없기 때문입니다.

Intigriti는 이 틈이 "사람이 신중하게 판단을 멈추는 지점과 과도한 권한을 가진 AI 에이전트가 넘겨받는 시점 사이"에 있다고 짚습니다. 엿새 뒤 GBHackers의 보도도 특정 벤더를 지목하지 않은 채 같은 패턴을 확인했습니다. 한 봇의 버그가 아니라 상담 에이전트를 연결하는 방식에 있는 구조적 문제입니다.

AI 에이전트 접근 제어란 무엇이고, 왜 이번 사고를 막지 못했나

요약: AI 에이전트 접근 제어는 보통 설정 시점에 한 번 내리는 두 가지 결정을 말합니다. 어떤 도구를 줄지, 어떤 데이터를 보게 할지입니다. DEF CON 34가 찾아낸 틈은 이 두 결정 중 어느 쪽도 답하지 않는 지점에 있었습니다. 도구가 실제로 실행되는 순간 무엇이 다시 검증되는가입니다.

AI 에이전트에게 접근 제어란 대개 설정 시점에 한 번 내리는 두 가지 결정을 말합니다. 이 에이전트에게 어떤 도구를 줄 것인가, 그리고 어떤 데이터를 보게 할 것인가입니다. 상담 에이전트에게 환불 도구를 주는 건 환불이 업무의 일부이기 때문이고, 청구 내역을 읽을 권한을 주는 건 질문에 답하려면 필요하기 때문입니다. 합리적이고 필요한 결정이지만, 대부분의 팀은 여기서 멈춥니다.

DEF CON 34는 그 결정 뒤에 남은 틈을 보여줬습니다. 환불 도구를 실행할 때, 현재 요청이 설정 시점에 부여한 권한의 범위에 맞는지 다시 확인하지 않습니다. 에이전트는 이미 도구를 쥐고 있습니다. 그 도구를 쓰는 순간 누가 실제로 통제하는지가 문제입니다.

이 틈은 드문 사례가 아닙니다. Kiteworks의 2026년 전망 보고서에 따르면 조직의 63%는 AI 에이전트에 목적 제한을 강제할 수 없고, 60%는 오작동하는 에이전트를 종료시킬 수 없습니다. 권한은 설정 시점에 한 번 부여됐을 뿐, 그 이후 무엇에 쓰이는지는 대부분의 조직에서 아무도 확인하지 않습니다.

Salesforce가 절반을 해결한 방법: 에이전트에게 고유한 신원 부여하기

Salesforce의 Agentforce는 이 문제의 절반에 대해 실제로 쓸 만한 답을 만들어 뒀습니다. 고객과 직접 마주하는 자율형 Service Agent는 사람의 권한이나 공유 서비스 계정 밑에서 돌아가지 않습니다. Agent User라 불리는 자기만의 합성 신원을 받고, 관리자는 이 신원에 자기만의 권한 세트를 따로 구성합니다. Salesforce Ben의 Agentforce 권한 해설에 따르면, 새 에이전트를 만들 때 "New User" 옵션을 고르면 "Salesforce가 자동으로 이 에이전트를 위한 사용자 레코드를 만들어 주며", 이는 에이전트가 "기존 프로필이나 권한 세트 그룹에서 아무것도 물려받지 않도록" 하기 위해서입니다. 이렇게 묶이는 권한 세트 그룹에는 AgentforceServiceAgentUserPsg라는 이름이 붙고, 여기에 Secure Base 세트와 관리자가 직접 채워 넣는, 에이전트별로 비어 있는 세트가 더해집니다.

이는 사람이 직접 호출하는 코파일럿과는 근본적으로 다른 모델입니다. 코파일럿은 로그인한 사람이 이미 볼 수 있는 것을 그대로 물려받을 뿐입니다. 하지만 뒤에 아무도 없는 자율형 에이전트는 물려받을 사람 자체가 없습니다. 그래서 Salesforce는 그 대신 관리자가 직접 구성하는 상시형 신원을 만들어 준 것입니다. "이 에이전트가 우리 CRM 안에서 무엇을 보고 무엇을 건드릴 수 있는가"라는 질문에는 이것으로 실제로 쓸 만한 답이 됩니다.

SaaS 권한 설정이 더 이상 통하지 않는 지점

Agentforce의 Agent User 모델과 권한 세트는 SaaS 플랫폼 안에서만 작동합니다. 그러나 관리자 도구는 대개 한 SaaS 안에 머물지 않습니다. 상담 에이전트의 환불 도구는 청구 데이터베이스에서 내부 스크립트를 실행하는 웹훅일 수 있습니다. 프로필 수정도 Salesforce 객체를 벗어나 내부 API를 직접 호출할 수 있고, MCP 도구는 프로덕션 호스트에 닿을 수도 있습니다.

Salesforce의 Agent User는 에이전트가 청구 필드를 볼 수 있고 Apex 액션을 호출할 수 있다고 알려 줍니다. 그러나 그 액션이 자체 인프라에 닿은 뒤 무엇을 하는지는 말해 주지 않습니다. 그 지점은 Salesforce의 범위를 벗어나기 때문입니다. Zendesk는 봇 설정 권한을 관리하고, Intercom은 봇이 동기화한 지식 소스까지 관리합니다. 두 경우 모두 설정을 통제할 뿐, 매 상호작용을 확인하는 런타임 검사는 아닙니다. 두 벤더의 문서에도 신원 확인 뒤에 행위 단위로 다시 검사하는 절차는 나오지 않습니다. Intigriti가 찾아낸 틈도 여기에 있습니다.

접근 제어는 SaaS 여부와 관계없이 에이전트가 어떤 도구를 쥘 자격이 있는지 판단합니다. 지금 이 호출이 승인하려던 요청과 같은지까지는 답하지 못합니다.

이미 관리자 도구를 쥔 에이전트, 지금 무엇을 확인해야 하나

요약: 에이전트의 관리자 도구 중 여러분 자신의 인프라에 닿는 부분에 대해서는, 연결 시점에 어떤 도구를 호출할 수 있는지 범위를 제한하고, 진행 중인 동작이 세션이 선언한 목적에 여전히 맞는지 확인하고, 실제로 실행된 내용을 하나의 기록으로 남깁니다. 이 중 어느 것도 에이전트가 CRM이나 헬프데스크 안에서 무엇을 볼 수 있는지는 다루지 않습니다. 그 부분은 여전히 SaaS 플랫폼의 몫입니다.

에이전트가 Salesforce나 Zendesk 안에서 고객의 청구 기록 중 무엇을 볼 수 있는지, SaaS 쪽 절반은 그 플랫폼의 몫입니다. Agent User나 필드 단위 보안이 제대로 구성돼 있는지 확인하는 것도 합리적인 접근입니다. 이 층에 대해서는 Alpacon도 아무 가시성도 통제권도 갖고 있지 않습니다.

하지만 여러분 자신의 인프라에 닿는 부분, 즉 내부 스크립트를 실행하는 웹훅, 내부 API, 데이터베이스 호출, 프로덕션 호스트에 연결된 MCP 도구라면 이야기가 다릅니다. 여기서부터는 실행 제어가 무엇을 할 수 있는지, 그리고 아직 어디까지가 좁게 남아 있는지를 함께 짚어야 합니다.

→ 에이전트가 애초에 닿을 수 있는 도구 자체를 제한합니다. alpacon-mcp의 로컬 모드는 --toolsets 플래그를 받아서, 운영자가 특정 AI 클라이언트에 필요한 도구 그룹만 등록하고 전체 도구를 기본으로 노출하지 않게 만들 수 있습니다. 다만 이 범위는 등록 시점에 정해질 뿐 호출마다 다시 판단되지 않고, 로컬 모드에서만 동작합니다. GitHub의 자체 MCP 서버도 같은 플래그를 제공한다는 점에서, 이는 경쟁 우위가 아니라 최소한의 기본기에 가깝습니다.

→ 세션이 선언한 목적에 비추어 동작을 판단합니다. Alpacon의 실행 레인(exec lane)에서는 위험도가 회색 지대로 채점된 명령을 명령 텍스트만이 아니라 그 세션이 애초에 밝힌 목적과 함께 LLM이 판단합니다. 여기에는 실제로 존재하는 한계가 세 가지 있습니다. 이 검사는 실행 레인에만 적용되고, 사람 운영자가 쓰는 화면인 대화형 Websh에는 적용되지 않습니다. 에이전트가 그 화면을 쓰지 않기 때문입니다. 또한 위험도가 대략 0.3에서 0.8 사이인 회색 지대에서만 작동하므로, 그보다 낮게 채점된 명령은 이 검사 자체를 건너뜁니다. 그리고 사전에 검증된 목적은 기준을 더 엄격하게 만들 수는 있어도, 더 느슨하게 만들지는 못합니다.

→ 회색 지대에 걸린 동작은 실행되기 전에 사람에게 넘어갈 수 있습니다. 위험도 레인이 회색 지대로 채점한 명령은 콘솔이나 Slack을 통한 대역외(out-of-band) 승인 대기 상태로 잡힐 수 있으며, 요청을 보낸 바로 그 채널이 스스로 승인할 수는 없습니다. 다만 여기서 "잡힐 수 있다"와 "항상 잡힌다"는 서로 다른 이야기입니다. 위험해 보이는 행동이라고 해서 전부 매번 사람 손을 거치는 것은 아닙니다.

→ 거버넌스 대상 채널에서는 명령이 실제로 실행될 때마다 판단하고 기록합니다. 명령 API, MCP, OS 수준 sudo 전반에서, 도구가 등록됐다는 사실이 아니라 명령이 실제로 실행되는 순간을 Alpacon이 판단하고 기록합니다. 설정값 조회처럼 호스트 명령을 내지 않는 도구 호출은 이 판단 대상에 들어가지 않습니다. 직접 SSH 접속과 서비스 토큰도 이 범위 밖에 있습니다.

이 기능들은 Salesforce 에이전트가 고객 레코드에서 무엇을 볼 수 있는지 알려 주지 않습니다. 하지만 범위가 다를 뿐, 에이전트의 관리자 도구가 SaaS 객체를 넘어 자체 인프라로 이어질 때 실제 실행 내용을 무엇이 확인하는지는 실행 제어가 일반적으로 답하는 질문입니다.

새 관리자 도구를 하나 더 연결하기 전에 물어야 할 질문

상담 에이전트에게 도구를 하나 더 얹기 전에, 이 도구가 선 어느 쪽에 있는지부터 물어야 합니다. Salesforce 필드나 Zendesk 티켓, Intercom 대화창처럼 SaaS 객체라면, 통제 지점은 신원과 권한 세트이고 Agentforce의 Agent User 모델은 견줘 볼 만한 합리적인 기준입니다. 웹훅이나 내부 API, 데이터베이스, 프로덕션 호스트에 연결된 MCP 도구처럼 여러분 자신의 인프라라면, 통제 지점은 그것이 실행되는 바로 그 순간이며, 몇 층 위에 있는 권한 세트는 그 순간에 대해 아무것도 말해 주지 못합니다. 대부분의 설정에는 이 둘이 섞여 있습니다. 어느 도구가 어느 쪽인지 먼저 아는 것이 두 통제 방식 모두가 제 몫을 하기 위한 전제 조건입니다.

자주 묻는 질문

Salesforce의 Agent User처럼 AI 에이전트에게 고유 신원을 주면 접근 제어의 이 틈이 메워지나요?

상시 권한 쪽 절반은 메워집니다. 그 플랫폼 안에서 에이전트가 무엇을 보고 건드릴 수 있는지는 해결됩니다. 하지만 DEF CON 34가 찾아낸 질문에는 답하지 못합니다. 지금 이 도구를 발동시킨 구체적인 요청이 실제로 누군가 승인한 바로 그 요청인지입니다. 이건 신원 모델이 아니라 런타임 검사가 답할 몫입니다.

Alpacon이 Salesforce나 Zendesk AI 에이전트가 고객 데이터에서 무엇을 보는지 통제할 수 있나요?

아니요. Alpacon은 인프라 실행 계층, 즉 셸, sudo, 명령 API, 관리 대상 호스트에 닿는 MCP 도구 호출에서 작동합니다. SaaS 애플리케이션 계층이 아닙니다. 상담 에이전트가 Salesforce 레코드나 Zendesk 티켓에서 무엇을 볼 수 있는지는 그 플랫폼 자체의 권한 모델이 결정하며, Alpacon이 결정하지 않습니다.

AI 에이전트에게 접근 제어와 실행 제어는 실제로 무엇이 다른가요?

접근 제어는 에이전트가 어떤 도구를 쥘 자격이 있는지 결정합니다. 실행 제어는 지금 이 도구를 이렇게 쓰는 일이 세션이 원래 하기로 돼 있던 일에 맞는지 판단합니다. DEF CON 34를 포함해 대부분의 관리자 도구 익스플로잇은 이 두 질문 사이의 공백에서 일어납니다.

회색 지대 승인은 사람이 에이전트의 모든 위험한 행동을 검토한다는 뜻인가요?

아니요. 위험도 엔진이 정의된 회색 지대(대략 0.3~0.8)로 채점한 행동에만 적용됩니다. 그보다 낮게 채점되면 이 검사 자체가 실행되지 않습니다. 회색 지대에 걸린 행동은 사람에게 넘어갈 수 있을 뿐, 매번 사람 손에 잡혀 있는 것은 아닙니다.

에이전트에 연결하는 도구는 하나씩 이 선을 넘게 됩니다. 그 도구가 어느 쪽에 있는지, 신원과 권한 세트로 다뤄야 할 문제인지 아니면 실행 하나하나를 확인해야 할 문제인지를 알아야 다음 관리자 도구에도 맞는 통제를 적용할 수 있습니다.