
AI 에이전트의 폭주를 방지하는 Control Plane 설계: 권한·Skill·Sandbox·감사 API 구현 체크리스트
요약
AI 에이전트 도입의 패러다임이 모델 선택에서 관리 및 감사 가능한 운영 환경 구축으로 변화하고 있습니다. Google, Anthropic, OpenAI, NVIDIA 등의 최신 동향을 바탕으로 에이전트의 권한, 실행 환경(Sandbox), 감사 기능을 제어하는 'Control Plane' 설계의 중요성과 체크리스트를 제시합니다.
핵심 포인트
- AI 에이전트 운영의 핵심은 모델 성능보다 '무엇을 맡겨도 안전한지 증명할 수 있는 관리 계층(Control Plane)' 구축에 있음
- Google의 Managed Agents 사례를 통해 격리된 Linux 환경(Sandbox)과 세션 관리의 중요성 확인
- Anthropic의 SDK 및 MCP 강화는 에이전트가 도달할 수 있는 시스템의 범위를 결정하는 핵심 요소임
- 에이전트 도입 시 Runtime Boundary(실행 경계)를 설정하고 Identity, Skill, Sandbox, 감사 API를 체계적으로 설계해야 함
2026년 5월 21일 JST 시점의 영어권 AI 뉴스를 보면, AI 에이전트 도입의 주전장은 "어떤 모델을 선택할 것인가"에서, 에이전트를 어떻게 관리·감사·정지할 수 있는 상태로 운영 환경에 배치할 것인가로 옮겨가고 있습니다.
Google은 클라우드 상의 managed agents를 출시하고, Anthropic은 SDK/MCP 기반을 강화하며, GitHub은 Copilot cloud agent 설정을 REST API로 감사할 수 있도록 하고, OpenAI는 Enterprise를 위한 agent/remote access/admin controls를 확장하고 있으며, NVIDIA는 agent skills의 검증·서명·skill card를 제시하고 있습니다.
이 기사에서는 이러한 1차 정보를 바탕으로, AI 에이전트 도입 전에 구축해야 할 Control Plane 구현 체크리스트를 정리합니다. 뉴스에서 확인할 수 있는 사실과 그로부터 도출된 실무적 해석을 구분하여 다룹니다.
AI 에이전트를 운영 환경에서 사용하려면, 애플리케이션 본체와는 별도로 다음과 같은 Control Plane을 설계해야 합니다.
| Control Plane 항목 | 목적 | 최소한의 구현 |
|---|---|---|
| Agent Identity | 어떤 agent가 실행했는지 추적 | agent_id, owner, workspace, 실행 host, token 종류 |
| ... |
한마디로 말하면, AI 에이전트의 Control Plane은 "무엇을 맡길 것인가"가 아니라 "무엇을 맡겨도 괜찮은 상태인지 증명할 수 있는가"를 관리하는 계층입니다.
Google은 2026년 5월 19일, Gemini API의 Managed Agents를 발표했습니다. Antigravity agent를 API를 통해 기동하여 추론, tool 이용, 코드 실행을 클라우드 상에서 처리할 수 있다고 설명하고 있습니다.
인용:
"executes code in an isolated, ephemeral Linux environment"
일본어 번역: 격리된 일시적인 Linux 환경에서 코드를 실행합니다.
또한, Google은 remote Linux environment가 tool call, file 관리, web browsing를 처리하며, follow-up call을 통해 session 상태를 지속할 수 있다고 설명합니다.
managed agent는 편리하지만, 도입 측면에서 보면 "실행 환경을 직접 세세하게 만들지 않아도 된다"는 것과 "실행 환경의 책임을 모호하게 해도 된다"는 것은 별개의 문제입니다.
가장 먼저 설계해야 하는 것은 model 선정이 아니라 Runtime Boundary입니다.
agent_runtime_boundary:
agent_id: support-ticket-triage-agent
provider_runtime: gemini-managed-agent
...
실패하기 쉬운 지점은 sandbox를 "안전해 보이는 실행 장소"로만 취급하여, session 영속화, network, file 쓰기, browser 이용의 경계를 각각 별도로 관리하지 않는 것입니다.
Anthropic은 2026년 5월 18일, SDK와 MCP server tooling을 다루는 Stainless의 인수를 발표했습니다. Stainless는 Anthropic 공식 SDK 생성에도 관여하며, TypeScript, Python, Go, Java 등의 SDK, CLI, MCP server 생성을 지원해 왔다고 설명되었습니다.
인용:
"agents are only as capable as the systems they can reach"
일본어 번역: 에이전트는 도달할 수 있는 시스템의 범위 내에서만 유용합니다.
MCP나 SDK는 agent의 "편리한 연결 부품"이 아니라, agent가 실행할 수 있는 조작 범위 그 자체입니다.
인간을 위한 API 문서에서는 다소 모호하더라도 운영을 통해 흡수할 수 있는 경우가 있습니다. 하지만 agent의 경우, 모호한 API 사양은 그대로 오작동, 과도한 권한, 감사 불능으로 이어집니다.
Tool Registry에서는 최소한 다음 사항을 고정합니다.
tool_registry:
- name: github-repo-readonly
type: mcp_server
...
여기서 중요한 것은 MCP server 이름만을 관리하지 않는 것입니다. server 내부에 있는 tool, scope, 쓰기 가능 여부, data classification, owner, 변경 리뷰 조건까지 관리 대상으로 삼아야 합니다.
GitHub는 2026년 5월 18일, repository의 Copilot cloud agent configuration을 REST API로 감사할 수 있는 기능을 public preview로 발표했습니다.
인용:
"audit the security posture of your repositories at scale"
한국어 번역: repository 군의 보안 태세를 대규모로 감사할 수 있습니다.
GitHub는 이 API가 MCP server configuration, enabled tools, GitHub Actions workflow policy, firewall configuration을 반환한다고 설명합니다.
AI coding agent 도입 시 두려운 것은 초기 설정 실수만이 아닙니다. 더 현실적인 문제는 repository마다 설정이 조금씩 어긋나서, 반년 뒤에 "어떤 repo에서 어떤 agent가 무엇을 할 수 있는지" 알 수 없게 되는 것입니다.
따라서 Control Plane에는 policy audit job을 포함해야 합니다.
agent_policy_audit:
schedule: "daily"
targets:
...
핵심은 agent 설정을 "관리 화면을 보면 알 수 있는" 상태로 두지 않는 것입니다. API로 가져올 수 있다면, CI나 scheduled job을 통해 drift(설정 드리프트)를 감지할 수 있습니다.
OpenAI의 ChatGPT Enterprise & Edu release notes에서는 2026년 5월 14일에 Codex remote access와 access tokens for automation이 안내되었습니다. ChatGPT mobile app에서 장시간 실행 중인 Codex 작업에 접속하여, 질문에 대한 답변, 실행 리다이렉션, 승인, 출력 리뷰, host 전환이 가능하다고 설명되어 있습니다.
인용:
"admins able to manage workspace-level availability"
한국어 번역: 관리자가 workspace 레벨의 이용 가능 여부를 관리할 수 있습니다.
동일한 release notes에서는 2026년 5월 7일에 Enterprise Key Management를 지원하는 workspace agents가 안내되었으며, agents는 template 또는 scratch에서 생성할 수 있고, publishing 전에 preview할 수 있으며, workspace 내에서 공유 및 schedule 실행이 가능하다고 설명되어 있습니다.
agent의 Identity Plane에서는 최소한 다음을 구분해야 합니다.
| 종별 | 예 | 주요 리스크 | 관리 대상 |
|---|---|---|---|
| Human interactive | mobile에서 Codex로 복귀 | 승인자 착오 | user identity, device, MFA, approval log |
| ... |
설계 템플릿은 다음과 같은 형태입니다.
agent_identity_plane:
human_approval:
required_for:
...
agent를 단순히 "누군가를 대신해 움직이는 것"으로 취급하는 것만으로는 부족합니다. 인간, token, workspace agent, connector를 별개의 identity로 취급하고, 승인 로그(approval log)를 통합해야 합니다.
NVIDIA는 2026년 5월 19일, NVIDIA-verified agent skills에 관한 기술 블로그를 공개했습니다. verified skills는 portable instruction sets로서, transparency, provenance, security scanning, cryptographic signing 등을 skill layer에 도입하는 것이라고 설명되어 있습니다.
인용:
"trust extends beyond the runtime"
한국어 번역: 신뢰는 실행 환경(runtime) 너머로 확장됩니다.
NVIDIA는 verified skill이 cataloged, scanned, signed 되며, skill card를 통해 documented 된다고 설명합니다. 또한, SkillSpector가 hidden instructions, prompt injection, tool poisoning, excessive agency와 같은 agent 고유의 리스크도 확인한다고 밝혔습니다.
AI 에이전트의 skill은 단순한 prompt 조각이 아닙니다. 에이전트에 새로운 능력을 추가하는 deployable artifact (배포 가능한 아티팩트)입니다.
즉, 애플리케이션의 library (라이브러리)나 container image (컨테이너 이미지)와 마찬가지로, skill에도 Supply Chain (공급망) 관리가 필요합니다.
skill_supply_chain:
required_files:
- SKILL.md
...
실수하기 쉬운 점은, skill을 '편리한 절차서'로서 그대로 에이전트에 넣는 것입니다. skill은 tool (도구) 사용, data access (데이터 접근), 실행 판단을 변화시키기 때문에, 도입 전에 card (카드), scan (스캔), 서명, version pinning (버전 고정)을 확인해야 합니다.
AI 에이전트 도입 전에, 다음 체크리스트를 PR template (PR 템플릿)이나 security review (보안 검토)에 포함시키십시오.
## AI Agent Control Plane Checklist
### 1. Agent Identity
- [ ] agent_id 와 owner 가 명시되어 있음
...
| 실패 | 왜 위험한가 | 대책 |
|---|---|---|
| sandbox (샌드박스)가 있으므로 안전하다고 생각함 | network (네트워크), file (파일), session state (세션 상태)가 열려 있으면 영향 범위가 넓어짐 | Runtime Boundary (런타임 경계)를 YAML로 정의한다 |
| ... |
처음부터 거대한 platform (플랫폼)을 만들 필요는 없습니다. 작게 시작한다면 다음 5개의 파일로 충분합니다.
agent-control-plane/
agents.yaml # agent_id, owner, runtime, token, schedule
runtimes.yaml # sandbox, network, file scope
...
agents.yaml의 예시입니다.
agents:
- id: pr-fix-agent
owner: developer-platform
...
tools.yaml의 예시입니다.
tools:
- id: github-mcp
type: mcp
...
이 정도 규모의 작은 장부만 있어도, 에이전트 도입 시의 대화는 크게 달라집니다. "이 에이전트는 편리한가"가 아니라, "이 에이전트는 어디까지 할 수 있고, 어디서 멈추며, 어떻게 감사(audit)되는가"를 리뷰할 수 있게 되기 때문입니다.
최근의 AI 뉴스를 통해 읽을 수 있는 흐름은 명확합니다.
- agent runtime (에이전트 런타임)은 managed (관리형)화되며, sandbox (샌드박스)와 state (상태) 관리가 전제가 된다
- API와 MCP는 에이전트의 조작 경계 그 자체가 된다
- repository (저장소)나 workspace (워크스페이스)의 에이전트 설정은 API로 감사하는 시대가 된다
- human (사람), automation token (자동화 토큰), workspace agent (워크스페이스 에이전트)는 별도의 identity (ID)로 관리할 필요가 있다
- skill은 prompt (프롬프트)가 아니라, 서명·스캔·카드를 가진 supply chain artifact (공급망 아티팩트)가 된다
AI 에이전트 도입 시 가장 먼저 만들어야 할 것은 장대한 자율화 구상이 아닙니다.
**agent, runtime, tool, skill, policy, approval을 한눈에 파악할 수 있는 Control Plane (컨트롤 플레인)**입니다.
- Google: Introducing Managed Agents in the Gemini API
https://blog.google/innovation-and-ai/technology/developers-tools/managed-agents-gemini-api/ - Anthropic: Anthropic acquires Stainless
https://www.anthropic.com/news/anthropic-acquires-stainless - GitHub Changelog: Audit repository Copilot cloud agent configuration via the REST API
https://github.blog/changelog/2026-05-18-audit-repository-copilot-cloud-agent-configuration-via-the-rest-api/ - OpenAI Help Center: ChatGPT Enterprise & Edu Release Notes
https://help.openai.com/en/articles/10128477-chatgpt-enterprise-edu-release-notes - NVIDIA Technical Blog: NVIDIA-Verified Agent Skills은 AI 에이전트의 역량 거버넌스(Capability Governance)를 제공합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기