AI 에이전트에게 권한을 부여하기 전에 결정해야 할 5가지 실행 경계

AI 에이전트 (AI Agent)를 실무나 사내 업무에 도입할 때, 가장 먼저 결정해야 할 것은 "어떤 모델을 사용할 것인가"가 아닙니다.

먼저 결정해야 할 것은, 어디까지 읽을 수 있는지, 어디에 쓸 수 있는지, 어디로 통신할 수 있는지, 어떤 능력을 불러올 수 있는지, 무엇을 기억해도 되는지 입니다.

최근 며칠에서 1주일 정도의 영어권 1차 정보(Primary Information)를 살펴보면, Anthropic, GitHub, Google, NVIDIA, OpenAI 모두 AI 에이전트를 "채팅 UI"가 아니라, 실행 환경(Execution Environment), 권한(Permission), 영속 상태(Persistent State), 능력 카탈로그(Capability Catalog)를 가진 소프트웨어로 취급하기 시작했습니다.

이 기사에서는 확인할 수 있는 뉴스 사실과 그로부터 도출되는 구현상의 판단을 구분하면서, 엔지니어와 기술 책임자가 먼저 만들어야 할 실행 경계 체크리스트를 정리합니다.

AI 에이전트에게 권한을 부여하기 전에, 최소한 이 5가지를 명문화합니다.

경계	결정할 사항	결정하지 않았을 때 발생하는 일
Workspace 경계	읽기, 쓰기, 삭제 가능한 경로	예상치 못한 설정, 비밀 정보, 다른 프로젝트 파일 읽기
...

한마디로 말하면, AI 에이전트 운용은 프롬프트 엔지니어링 (Prompt Engineering)이 아니라 권한 엔지니어링 (Permission Engineering) 입니다.

Anthropic은 2026년 5월 25일, Claude 제품군에서의 격리 (Containment) 설계를 공개하며, AI 에이전트의 능력과 액세스 범위가 넓어질수록 영향 범위의 상한 설계가 중요해진다고 설명했습니다.

원문: "how to cap the blast radius"

일본어 번역: 영향 범위를 어떻게 상한 지을 것인가.

출처: How we contain Claude across products

해당 기사에서는 Human-in-the-loop (인간 참여형)만으로는 승인 피로 (Approval Fatigue)가 발생한다는 점, 그리고 sandbox, VM, filesystem boundary, egress control과 같은 환경 측면의 제어가 필요하다는 점도 설명되어 있습니다.

"승인 다이얼로그를 띄우니까 안전하다"는 취약한 설계입니다. 에이전트가 할 수 있는 일 자체를 줄여야 합니다.

가장 먼저 만들어야 할 경계는 다음 3가지입니다.

agent_runtime_boundary:
filesystem:
read:
...

포인트는 경계를 "모델에 대한 부탁"이 아니라, 실행 환경의 설정으로 갖는 것입니다.

GitHub는 2026년 5월 26일, Copilot Memory에 삭제, repository-level off switch, Copilot CLI의 /memory, 저장 시의 스코프(Scope) 표시 등을 추가했습니다.

원문: "Clearer scope at capture time"

일본어 번역: 저장 시점에, 보다 명확한 스코프를 나타낸다.

출처: Copilot Memory has more controls for deletion, scope, and the Copilot CLI

GitHub는 저장되는 memory가 user-level preference인지 repository-level fact인지를 권한 프롬프트 (Permission Prompt)로 명시한다고 설명합니다.

Memory는 "기억해 주니 편리하다"가 아니라, 다음번 이후의 판단에 영향을 미치는 영속 설정 (Persistent Setting) 입니다. 외부 입력, 장애 대응 메모, 개인적인 습관, 고객 고유 정보가 섞이면 재현성과 감사성 (Auditability)이 무너집니다.

agent_memory_policy:
user_level:
allowed:
...

Memory를 기록하기 전에 "이것은 누구의 판단을 바꾸는 정보인가"를 확인하는 것만으로도 많은 사고를 피할 수 있습니다.

Google은 2026년 5월 19일의 I/O 2026 developer highlights에서, Gemini API의 Managed Agents를 발표했습니다. 단 한 번의 API call로, 도구 (Tool) 이용과 코드 실행 (Code Execution)을 수행하는 에이전트를 격리된 Linux 환경 (Isolated Linux Environment)에서 실행할 수 있다고 설명했습니다.

원문: "spin up an agent that reasons, uses tools and executes code"

일본어 번역: 추론하고, 도구를 사용하며, 코드를 실행하는 에이전트를 기동한다.

출처: Building the agentic future: Developer highlights from I/O 2026

해당 기사에서는 각 상호작용 (interaction)이 재개 가능한 지속적이고 격리된 환경 (persistent, isolated environment)을 생성한다고도 설명하고 있습니다.

관리형 에이전트 런타임 (managed agent runtime)은 환경 구축의 부담을 줄여줍니다. 하지만 지속적인 환경이 있다면, 그곳에는 상태 (state), 파일, 자격 증명 프록시 (credential proxy), 도구 (tool) 설정, 그리고 이전의 생성물이 남게 됩니다.

관리형 런타임 (managed runtime)을 사용하는 경우에도, 다음 항목들을 기업 측에서 보유해야 합니다.

확인 항목	구현 판단
environment resume	재개 가능한 기간과 폐기 조건을 결정한다
...
관리형 (managed)이라고 해서 안전한 것은 아닙니다. 관리형이 된 만큼, 기업이 어디를 설정 책임 (setting responsibility)으로 가질 것인가를 명확히 할 필요가 있습니다.

NVIDIA는 2026년 5월 19일, NVIDIA-verified agent skills를 공개하며, 에이전트 스킬 (agent skill)에 대해 보안 스캐닝 (security scanning), 스킬 카드 (skill card), 암호화 서명 (cryptographic signing) 등을 조합하는 방침을 설명했습니다.

원문: "trust extends beyond the runtime"

한국어 번역: 신뢰는 실행 시점 제어 (runtime control)의 외곽까지 확장된다.

출처: NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents

해당 기사에서는 SkillSpector가 취약한 종속성 (vulnerable dependencies), 의심스러운 스크립트 (suspicious scripts), 자격 증명 접근 (credential access), 데이터 유출 경로 (data exfiltration paths)뿐만 아니라, 숨겨진 지시문 (hidden instructions), 프롬프트 인젝션 (prompt injection), 도구 오염 (tool poisoning) 등 에이전트 고유의 리스크도 확인한다고 설명하고 있습니다.

스킬 (skill), MCP 서버 (MCP server), 커넥터 (connector), 도구 (tool) 정의는 단순한 보조 프롬프트가 아닙니다. 에이전트에게 새로운 행동 능력을 부여하는 배포 가능한 역량 (deployable capability)입니다.

사내에 스킬을 도입한다면, 최소한 이 매니페스트 (manifest)를 요구합니다.

capability_manifest:
name: invoice-review-skill
owner: finance-platform-team
...

"유명한 제공처니까 괜찮다"는 것만으로는 부족합니다. 다운로드 후에 변조되지 않았는지, 선언된 목적과 실제 액세스가 일치하는지를 확인해야 합니다.

OpenAI는 2026년 5월 21일 ChatGPT Release Notes를 통해, Codex의 Goal mode, Appshots, 브라우저 주석 (browser annotations), 잠금 컴퓨터 사용 (locked computer use) 등을 발표했습니다.

원문: "define an outcome and success criteria"

한국어 번역: 결과와 성공 조건을 정의한다.

출처: ChatGPT - Release Notes

이번 릴리스에서는 긴 작업을 진행하기 위해 작업 문맥 (work context)의 이해나 Goal mode를 확장하고 있다는 점도 설명되어 있습니다.

AI 에이전트를 장시간 구동할수록, "무엇을 하는가"보다 "어디서 멈추는가"가 중요해집니다.

agent_goal_contract:
objective: "의존성 라이브러리 업데이트의 영향을 조사하고, 필요한 최소한의 수정안을 만든다"
success_criteria:
...

이러한 계약 (contract)이 없으면, 에이전트는 "시도를 계속하는 것"을 성공으로 오해합니다. 업무용으로 사용할 때는 멈추는 조건을 결과물의 일부로 취급합니다.

운영 환경의 AI 에이전트를 도입하기 전에, 다음 체크리스트를 통과시킵니다.

[ ] 에이전트가 읽을 수 있는 파일 경로를 허용 목록 (allowlist)으로 정의했다
[ ] 에이전트가 쓸 수 있는 경로와 삭제할 수 있는 경로를 분리했다
[ ] 네트워크는 기본 거부 (default deny)로 설정했다
...

실패 패턴	무엇이 문제인가	대책
승인 다이얼로그(Approval Dialog)에만 의존함	승인 피로(Approval fatigue)로 인해 사실상 자동 승인(auto approve) 상태가 됨	환경 측에서 권한을 제한함
api.example.com을 통째로 허용함	동일한 도메인 내의 업로드(upload) 기능이 악용됨	엔드포인트(endpoint), 메서드(method), 토큰 출처(token provenance)로 제어함
README를 작성하듯 스킬(skill)을 추가함	숨겨진 지시사항(hidden instruction)이나 과도한 권한을 간과함	기능 명세서(capability manifest)와 서명 검증(signature verification)을 요구함
메모리(memory)에 조사 메모를 저장함	오래된 전제 조건이 다음 회차 이후에도 사용됨	세션 메모리(session memory)와 리포지토리 사실(repo fact)을 분리함
...

최근의 AI 뉴스는 AI 에이전트가 '똑똑한 보조자'에서 '권한을 가진 실행 주체'로 이동하고 있음을 보여줍니다.

그렇기에 도입 시의 중심은 모델 비교가 아니라, 실행 경계(execution boundary), 영속 상태(persistent state), 능력 관리(capability management), 감사 로그(audit log)여야 합니다.

오늘부터 바로 적용할 수 있는 최소 단위는 다음 세 가지입니다.

• 에이전트 런타임 경계(agent runtime boundary)를 YAML로 작성할 것
• 기능 명세서(capability manifest)가 없는 스킬(skill) / MCP / 커넥터(connector)를 도입하지 말 것
• 태스크(task)마다 성공 기준(success criteria)과 중단 조건(stop conditions)을 전달할 것

AI 에이전트에게 일을 맡기면 맡길수록, 인간 측은 '어디까지 맡길 것인가'를 코드와 설정으로 표현해야 합니다.

• How we contain Claude across products
• Copilot Memory has more controls for deletion, scope, and the Copilot CLI
• Building the agentic future: Developer highlights from I/O 2026
• NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents
• ChatGPT - Release Notes