AI 코딩 에이전트 보안의 새 원칙: Prompt Guardrail보다 Sandbox·Egress Control이 중요한 이유

이경규·2026년 8월 9일

AI 코딩 에이전트 보안의 새 원칙: Prompt Guardrail보다 Sandbox·Egress Control이 중요한 이유

AI 코딩 에이전트의 보안을 처음 구성하면 보통 이런 지시부터 넣는다.

Production에 접근하지 마.

Secret을 읽지 마.

허가되지 않은 URL에 접속하지 마.

위험한 Shell 명령은 실행하지 마.

현재 Repository 밖의 파일은 수정하지 마.

그리고 AGENTS.md, CLAUDE.md, System Prompt 같은 곳에도 같은 내용을 적는다.

이런 규칙은 필요하다.

하지만 이것만으로 충분하지는 않다.

최근 AI Agent 보안 논란에서 계속 반복되는 문제는 모델이 규칙을 몰라서가 아니라, Agent가 실제로 사용할 수 있는 실행 환경이 너무 넓다는 데 있다.

예를 들어 Agent에게 다음 권한이 모두 있다고 하자.

홈 디렉터리 읽기

Repository 쓰기

Shell 실행

인터넷 연결

Git Credential 접근

Cloud CLI 접근

SSH Key 접근

Package 설치

그리고 Prompt에는 이렇게 적혀 있다.

절대 민감한 정보는 외부로 보내지 마.

이 구조에서 마지막 방어선은 결국 모델의 판단이다.

하지만 Agent가 Prompt Injection을 만나거나, 잘못된 Tool 호출을 만들거나, 정상적인 작업이라고 오판한다면 어떻게 될까?

더 안전한 구조는 반대다.

Agent가 잘못 판단하더라도

↓

Filesystem 밖으로 못 나감

↓

허용되지 않은 Network로 못 나감

↓

Production Credential이 없음

↓

위험한 Tool을 호출할 수 없음

↓

최악의 경우에도 피해 범위가 작음

즉 최근 Agent Security에서 중요한 질문은

Agent가 잘 행동할까?

보다

Agent가 잘못 행동했을 때
어디까지 피해를 낼 수 있을까?

에 가깝다.

이번 글에서는 Codex와 Claude Code 같은 Coding Agent를 기준으로 Blast Radius를 줄이는 Agent Runtime을 어떻게 구성할 수 있는지 정리한다.

1. 최근 Agent 보안 이슈에서 봐야 할 것은 “AI가 반란을 일으켰다”가 아니다

최근 AI Agent 보안 평가 사례가 공개되면서 일부 보도에서는

AI Agent escaped

AI Agent went rogue

Agent broke guardrails

같은 표현이 사용됐다.

이런 제목만 보면 마치 모델이 의지를 가지고 시스템을 탈출한 것처럼 느껴질 수 있다.

하지만 개발자가 봐야 하는 부분은 조금 다르다.

보안 사고는 대부분 다음 요소의 조합으로 발생한다.

강한 Agent Capability

+

넓은 Tool Permission

+

외부 Network

+

잘못된 Runtime Configuration

+

불완전한 Isolation

즉 Agent Security를 모델 성격 문제로만 보면 Runtime 설계 문제를 놓치게 된다.

구조적으로 보면 일반 서버 보안과 크게 다르지 않다.

Bug가 절대 발생하지 않게 만든다.

X

보다

Bug가 발생해도
중요 시스템까지 전파되지 않게 만든다.

O

가 현실적인 보안 전략이다.

2. Agent Security의 핵심 개념: Blast Radius

Blast Radius는 사고가 발생했을 때 피해가 얼마나 멀리 퍼질 수 있는지를 의미한다.

예를 들어 Coding Agent가 잘못된 명령을 실행한다고 하자.

구조 A

Agent

↓

개발자 계정 권한 그대로

↓

~/ 전체 접근

↓

SSH Key

↓

GitHub

↓

AWS

↓

Production

이 구조에서는 Agent 하나의 잘못된 판단이 여러 시스템으로 확장될 가능성이 있다.

반면 구조 B는 다르다.

Agent

↓

Ephemeral Sandbox

↓

현재 Repository만 Write

↓

Network Allowlist

↓

Task Scoped Credential

↓

작업 Branch만 Push

문제가 생겨도 피해 범위가 상당히 제한된다.

그래서 Agent 보안의 목표를 다음처럼 잡는 편이 좋다.

Agent Failure Probability

0으로 만들기

가 아니라

Failure Probability ↓

×

Blast Radius ↓

두 축을 함께 줄인다.

3. Prompt Guardrail은 보안 경계가 아니다

예를 들어 AGENTS.md에 다음을 적는다.

## Security

- Never read SSH keys.
- Never access production.
- Never send source code to external services.
- Never run destructive commands.

좋은 지침이다.

하지만 이것은 Behavior Instruction이다.

실제 권한 시스템은 아니다.

Agent가 다음을 실행할 권한 자체를 가지고 있다면

cat ~/.ssh/id_ed25519

보안은 결국 모델 판단에 달려 있다.

더 강한 구조는 OS가 막는 것이다.

Agent

↓

~/.ssh

↓

ACCESS DENIED

즉

Prompt

"하지 마"

보다

Runtime

"할 수 없음"

이 강하다.

4. Agent 보안 계층을 5단계로 나누자

실전에서는 다음 다섯 계층으로 보면 이해하기 쉽다.

1. Model Policy

2. Tool Policy

3. Filesystem Sandbox

4. Network Egress

5. Credential Boundary

그리고 마지막에

Audit / Trace

를 붙인다.

전체 구조는 다음과 같다.

                    Agent
                      │
                      ▼
                Model Policy
                      │
                      ▼
                 Tool Gate
                      │
               ┌──────┴──────┐
               │             │
               ▼             ▼
         Filesystem       Network
          Sandbox         Egress
               │             │
               └──────┬──────┘
                      │
                      ▼
              Credential Broker
                      │
                      ▼
                 External Tool
                      │
                      ▼
                    Audit

한 계층이 실패해도 다음 계층이 막아주는 구조다.

5. 첫 번째: Filesystem Scope를 줄인다

Coding Agent가 실제로 필요한 파일은 대부분 현재 Repository 안에 있다.

그런데 개발자 계정 전체 권한으로 실행하면 다음까지 접근 가능할 수 있다.

~/.ssh/

~/.aws/

~/.config/

~/Documents/

~/Downloads/

다른 회사 Repository

개인 프로젝트

환경 설정 파일

Agent가 이 모든 것을 읽을 이유는 거의 없다.

따라서 기본 원칙은 다음과 같다.

Read

필요한 범위만

Write

Workspace만

이다.

개념적으로:

/home/user/project

READ + WRITE

/home/user/.ssh

DENY

/home/user/.aws

DENY

/home/user/other-company-project

DENY

가 된다.

6. Codex가 기본적으로 Workspace Write를 사용하는 이유

Codex의 기본 Sandbox도 비슷한 방향이다.

일반적인 로컬 환경에서는 Agent가

파일 Read

→ 비교적 넓게 가능

하지만

파일 Write

→ 현재 Workspace 중심

으로 제한되는 형태를 사용한다.

그리고 Network Access나 더 높은 권한이 필요한 작업은 별도의 승인이나 설정이 필요하게 만든다.

이 구조의 핵심은 Agent에게

하지 마.

라고 말하는 것이 아니라

OS Level에서 수정 범위를 제한

하는 것이다.

macOS에서는 Seatbelt 같은 OS Sandbox Primitive를 활용할 수 있고, Linux에서는 seccomp·Landlock·bubblewrap 같은 기술을 사용할 수 있다.

7. Claude Code도 Permission Prompt만으로 끝내지 않는다

Claude Code 역시 초기에는 Permission Prompt가 중요한 안전장치였다.

예를 들어 Agent가 Shell을 실행하면

Claude wants to run:

npm install ...

Allow?

처럼 사람이 승인한다.

하지만 이 구조에는 문제가 있다.

하루 종일 Coding Agent를 사용하면

Approve

Approve

Approve

Approve

Approve

가 반복된다.

사람은 결국 자세히 보지 않게 된다.

이른바

Approval Fatigue

가 생긴다.

따라서 최근 Agent Runtime은

모든 작업을 사람이 승인

하는 방향보다

안전한 Sandbox 안

→ 자동 실행

Sandbox 밖

→ 승인

구조로 이동하고 있다.

8. 좋은 Sandbox는 Filesystem만 막아서는 안 된다

여기서 중요한 부분이다.

Filesystem Isolation만 만들어놓으면 충분할 것 같지만 그렇지 않다.

Agent가 Network를 자유롭게 사용할 수 있다고 하자.

Agent

↓

Repository 읽기

↓

HTTP Request

↓

외부 Server

Prompt Injection이 성공했다면 Source Code나 Secret을 외부로 보내려고 시도할 수 있다.

반대로 Network만 막고 Filesystem 전체 접근을 허용해도 위험하다.

따라서 좋은 Sandbox는 두 가지를 함께 사용한다.

Filesystem Isolation

+

Network Isolation

Anthropic도 Claude Code Sandbox를 설명하면서 두 경계가 함께 필요하다고 강조한다.

9. Network Egress가 최근 특히 중요해졌다

Coding Agent는 인터넷을 사용할수록 강력해진다.

공식 문서 확인

Package 다운로드

GitHub API

Issue 조회

MCP Server

Cloud API

하지만 Network는 데이터 유출 경로이기도 하다.

따라서

Internet

ALLOW ALL

은 가장 단순하지만 가장 넓은 권한이다.

대신 Egress Allowlist를 사용한다.

예:

network:

  default: deny

  allow:
    - api.github.com
    - github.com
    - developer.apple.com
    - registry.npmjs.org

이 YAML은 특정 Agent 제품의 공식 설정 형식이 아니라 정책 구조를 설명하기 위한 예시다.

핵심은

필요한 Destination만 허용

하는 것이다.

10. Repository 종류에 따라 Network Policy도 달라져야 한다

예를 들어 일반 iOS 앱 작업이라면:

github.com

api.github.com

developer.apple.com

정도로 충분할 수 있다.

Backend 작업:

github.com

npm registry

내부 package registry

Security Research:

별도 격리 Network

Production 운영 Agent:

가급적 별도 Runtime

즉 모든 Agent에게 같은 Network Profile을 주지 않는다.

11. 인터넷 접근은 Agent Capability로 생각해야 한다

Agent 설정에서 Internet Access를 단순한 편의 기능처럼 생각하기 쉽다.

하지만 실제로는 큰 Capability다.

Network OFF

Agent
→ Workspace 내부에서만 행동

Network ON

Agent
→ 외부 시스템과 상호작용 가능

따라서 Runtime에서는 다음처럼 분류할 수 있다.

Explorer

Network:
documentation only

Implementation Worker

Network:
package registry only

Reviewer

Network:
off

Release Agent

Network:
GitHub API
App Store API는 직접 금지

역할마다 Capability를 다르게 준다.

12. Tool Allowlist는 모델이 아니라 Runtime에서 강제한다

예를 들어 Agent에게 다음 Tool이 있다.

read_file

write_file

shell

git

github

aws

kubectl

database

deploy

모든 Agent가 모든 Tool을 볼 이유는 없다.

Explorer:

tools:
  - read_file
  - search_code

Reviewer:

tools:
  - read_file
  - git_diff
  - run_tests

Implementation Worker:

tools:
  - read_file
  - write_file
  - run_tests

Release Manager:

tools:
  - github_read
  - ci_read

Production Deploy:

Agent에게 직접 제공하지 않음

같은 식으로 나눈다.

13. “Tool을 사용할 수 있음”과 “Tool을 실행할 수 있음”도 분리한다

예를 들어 Agent가 GitHub Tool을 사용한다.

다음은 Read다.

PR 조회

Issue 조회

CI 상태 조회

Diff 조회

다음은 Write다.

Issue 생성

PR 생성

Branch Push

그리고 더 위험한 작업이 있다.

Merge

Branch Protection 변경

Secret 변경

Repository 삭제

따라서 Tool 이름 하나보다 Capability를 세분화해야 한다.

github:

  read_repository: allow

  create_issue: allow

  create_pull_request: allow

  merge_pull_request: ask

  change_repository_settings: deny

  manage_secrets: deny

14. Agent에게 Cloud CLI를 통째로 주지 않는다

위험한 구성 중 하나다.

Agent

↓

aws CLI

↓

개발자 Admin Credential

또는

Agent

↓

kubectl

↓

Production Cluster

이다.

Agent 입장에서는 CLI 명령 하나일 뿐이지만 피해 범위는 매우 크다.

더 나은 구조는 Tool을 좁게 만든다.

예:

get_deployment_status

restart_staging_service

fetch_logs

처럼 업무 단위 Capability를 제공한다.

Agent가 직접

aws *

kubectl *

gcloud *

를 사용할 수 있게 하지 않는다.

15. Credential은 Agent Environment에 넣지 않는 것이 가장 좋다

많은 CI와 Agent 시스템은 이렇게 구성한다.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...

그 상태에서 Agent를 실행한다.

그러면 Agent가 직접 사용하지 않더라도 Environment에서 Credential을 읽을 가능성이 생긴다.

더 나은 구조는

Agent

↓

Tool Request

↓

Credential Broker

↓

외부 API

이다.

Agent는 Credential 값을 알 필요가 없다.

16. Credential Broker 구조

예를 들어 GitHub Branch Push가 필요하다.

나쁜 구조:

Agent

↓

GitHub PAT

↓

git push

좋은 구조:

Agent

↓

Push Request

branch = agent/fix-142

↓

Git Proxy

↓

Policy Check

Repository 확인

Branch 확인

↓

Credential Attach

↓

GitHub

Agent에게 실제 GitHub Token을 전달하지 않는다.

Claude Code Web도 비슷한 방향으로 Git 동작을 Proxy하고, 제한된 Credential을 통해 허용된 Repository와 Branch 범위만 처리하도록 설계한다.

17. Task-Scoped Credential을 사용한다

Credential이 꼭 Agent Runtime에 전달되어야 한다면 범위를 최대한 줄인다.

예:

Credential

Repository:
mobile-app only

Permission:
contents: write

Branch:
agent/task-142

TTL:
30분

다음은 피한다.

Organization Admin

No Expiration

All Repositories

Production Access

좋은 Agent Credential은

짧게 살고

좁게 사용할 수 있고

작업이 끝나면 사라진다.

18. Ephemeral Workspace가 중요한 이유

Agent 작업이 끝난 뒤 Workspace가 그대로 남아 있으면 다음 Task가 이전 Task의 데이터를 볼 가능성이 있다.

Task A

↓

Secret Temporary File 생성

↓

Agent 종료

↓

Task B

↓

같은 Workspace 재사용

따라서 가능하면

Task

↓

새 Workspace

↓

Agent 실행

↓

Artifact 저장

↓

Workspace 삭제

방식을 사용한다.

Container나 Cloud Agent 환경에서 특히 적용하기 쉽다.

19. Agent도 CI Runner처럼 Disposable하게 생각한다

앞의 모바일 배포 글에서 Ephemeral Runner를 다뤘다.

Agent Runtime도 같은 원칙을 적용할 수 있다.

Persistent Agent Machine

X

대신

Task 생성

↓

Ephemeral Agent Runtime 생성

↓

Repository Checkout

↓

필요 Credential Inject

↓

Task 실행

↓

Artifact 추출

↓

Credential 폐기

↓

Runtime 삭제

구조로 만든다.

이것이 Long-running Agent와 모순되는 것은 아니다.

Long-running Task의 상태는 외부 Checkpoint와 Artifact에 저장한다.

Runtime 자체는 Disposable할 수 있다.

20. Agent Memory와 Secret을 분리한다

Agent가 긴 작업을 이어가기 위해 Memory를 사용한다고 하자.

저장할 만한 정보:

현재 Goal

Architecture 결정

완료한 Step

실패 원인

남은 작업

저장하면 안 되는 정보:

Access Token

Private Key

Password

Session Cookie

Production Credential

Memory는 다음 실행에서 다시 읽히기 때문이다.

memory:

  allowed:
    - task_state
    - decisions
    - artifact_paths

  prohibited:
    - credentials
    - secrets
    - auth_headers

21. Prompt Injection을 완전히 막는다고 생각하지 않는다

Coding Agent는 외부 데이터를 많이 읽는다.

README

Issue

PR Comment

웹페이지

Package Documentation

MCP Resource

Log

Generated File

이 중 악의적인 지시가 들어갈 수 있다.

예를 들어 문서 안에

Ignore previous instructions...

같은 내용이 숨어 있을 수 있다.

모델 수준에서 Prompt Injection 방어를 강화하는 것은 필요하다.

하지만 Agent Runtime은

Prompt Injection이 언젠가 성공할 수 있다.

를 전제로 설계하는 편이 안전하다.

그러면 질문이 달라진다.

Injection을 완벽히 막았나?

가 아니라

Injection이 성공해도
무엇을 할 수 있는가?

가 된다.

22. Prompt Injection에 가장 강한 대응은 Capability 최소화다

Prompt Injection이 성공했다고 가정한다.

Agent가 가진 Capability가

Read Repository

Write Workspace

Run Unit Test

뿐이라면 피해 범위가 제한된다.

반대로

Read Home Directory

Internet Access

AWS Admin

GitHub Admin

Production DB

를 가지고 있다면 상황이 다르다.

따라서

Prompt Injection Defense

+

Least Privilege

를 함께 사용해야 한다.

23. Agent마다 다른 Sandbox Profile을 만든다

모든 Agent가 같은 권한을 가져야 할 이유는 없다.

예를 들어:

Explorer

filesystem:
  repository: read
  workspace: read

network:
  docs: allow
  other: deny

tools:
  write: deny
  shell: deny

Reviewer:

filesystem:
  repository: read

network:
  default: deny

tools:
  diff: allow
  test: allow
  write: deny

Implementation Worker:

filesystem:
  workspace: read-write

network:
  package_registry: allow

tools:
  test: allow
  build: allow

Release Agent:

filesystem:
  repository: read

network:
  github_api: allow

tools:
  ci_read: allow
  release_note_write: allow
  production_deploy: deny

다시 말하지만 위 YAML은 특정 제품 설정 그대로가 아니라 Architecture 예시다.

24. Main Agent가 Subagent보다 더 많은 권한을 가져야 한다는 법도 없다

일반적으로

Main Agent
→ 가장 강한 모델

을 사용한다.

그렇다고

Main Agent
→ 가장 강한 권한

이어야 하는 것은 아니다.

오히려 Main Agent는 판단만 하고 Worker가 제한된 실행을 담당하게 할 수 있다.

Main Agent

Plan
Coordinate
Review

WRITE 없음

↓

Implementation Worker

Assigned Files만 WRITE

↓

Test Worker

Test Tool만 실행

이 방식은 멀티 에이전트에서도 유용하다.

25. Agent끼리 권한을 상속하지 않게 한다

다음 구조는 위험할 수 있다.

Main Agent

Production Credential 있음

↓

Subagent 생성

↓

Subagent도 자동 상속

Subagent가 많아질수록 Credential 노출 지점이 늘어난다.

대신

Child Agent

필요 Capability만 명시적으로 부여

한다.

예:

Security Reviewer

Repository Read
Test

만 제공한다.

26. Delegation Depth도 보안 경계다

Multi-Agent Runtime에서는 Agent가 또 다른 Agent를 만들 수 있다.

Coordinator

↓

Worker A

↓

Worker A-1

↓

Worker A-1-1

이렇게 계속 내려가면 누가 어떤 Capability를 갖고 있는지 관리하기 어려워진다.

그래서

delegation:

  maxDepth: 2

  maxAgents: 4

같은 제한을 둔다.

또 Child Agent가 Parent보다 더 높은 권한을 요구할 수 없게 한다.

Child Capability
⊆
Parent Capability

원칙이다.

27. Capability Escalation은 항상 Gate를 거친다

Agent가 작업하다 다음이 필요하다고 판단한다.

Network Access 필요

Repository 밖 파일 필요

새 Package 설치 필요

자동으로 권한을 확장하지 않는다.

Agent

↓

Capability Request

↓

Policy Engine

↓

Allow / Ask / Deny

형태로 처리한다.

예:

{
  "capability": "network",
  "target": "developer.apple.com",
  "reason": "Need to verify API availability.",
  "decision": "ask"
}

28. Policy Decision은 구조화해서 기록한다

type PolicyDecision = {
  action: "allow" | "ask" | "deny";

  capability: string;

  target?: string;

  ruleId: string;

  reason: string;
};

예:

{
  "action": "deny",
  "capability": "network",
  "target": "unknown.example",
  "ruleId": "NETWORK-DEFAULT-DENY",
  "reason": "Domain is not in the task allowlist."
}

나중에 Audit할 수 있다.

29. Risk Tier에 따라 Approval을 나눈다

모든 작업을 승인받는 것도 비효율적이다.

다음처럼 나눈다.

LOW

Repository Read

Code Search

Git Diff

Unit Test

자동.

MEDIUM

Workspace Write

Known Package Download

Task Branch Commit

정책 허용 가능.

HIGH

새 Network Destination

Dependency 추가

External Write API

Shared Configuration 수정

사람 승인.

CRITICAL

Production Deploy

Secret 변경

Database Migration

Repository 삭제

Signing 변경

Agent 직접 실행 금지 또는 강한 Human Gate.

30. Production은 Agent Sandbox 밖에 둔다

가장 강력하면서도 단순한 원칙이다.

Agent가 아무리 좋아져도 Production Credential을 Sandbox 안에 넣지 않는다.

Agent Sandbox

Production Credential

X

대신:

Agent

↓

Release Candidate

↓

CI

↓

Environment Approval

↓

Production Credential Injection

↓

Deterministic Deploy

구조로 만든다.

Agent는

배포 준비가 됐다.

는 판단까지 할 수 있다.

실제 배포는 별도 시스템이 한다.

31. Codex Security도 검증을 격리 환경에서 수행한다

최근 Codex Security의 구조도 참고할 만하다.

단순히 Source를 보고

취약점 같습니다.

라고 보고하지 않는다.

개념적으로는

Repository 분석

↓

Threat Model

↓

취약점 후보

↓

Isolated Validation Environment

↓

재현

↓

Patch Proposal

↓

Human Review

단계로 움직인다.

특히 취약점 검증을 별도 격리 환경에서 수행하는 부분이 중요하다.

Security Agent가 강한 공격 Capability를 가질수록 실행 환경을 더 좁게 해야 한다.

32. Security Agent는 일반 Coding Agent보다 더 위험할 수 있다

Security Agent는 다음 작업을 수행할 수 있다.

취약점 탐색

공격 경로 분석

Payload 생성

서비스 동작 검증

따라서 테스트 환경에서도

Internet 전체

Production Network

실사용자 Data

를 주면 안 된다.

권장:

Clone / Fixture

Isolated Sandbox

Synthetic Secret

Synthetic Service

Network 제한

이다.

33. Canary Secret을 둘 수도 있다

Agent Runtime에서 Secret 유출 시도를 탐지하려면 테스트용 Canary를 사용할 수 있다.

예:

FAKE_PRODUCTION_TOKEN

실제 권한은 없지만 접근하면 Alert를 발생시킨다.

Agent

↓

Canary Secret 접근

↓

Telemetry Event

↓

Security Alert

Production Credential 자체를 테스트용으로 넣는 방식보다 안전하다.

34. Network Egress Log는 반드시 남긴다

다음 정보를 기록한다.

Agent Run ID

Destination Domain

HTTP Method

Allowed / Denied

Policy Rule

Timestamp

예:

{
  "runId": "agent-run-142",
  "destination": "developer.apple.com",
  "action": "allowed",
  "rule": "DOCS-ALLOWLIST"
}

비정상 Destination이 반복되면 확인할 수 있다.

35. Shell Command도 Audit한다

Coding Agent 보안에서는 Shell이 가장 큰 Capability 중 하나다.

최소한 다음은 남긴다.

Command

Working Directory

Exit Code

Duration

Sandbox Result

Network Attempt

File Write

다만 Secret이 Argument에 들어갈 수 있으므로 Log Redaction이 필요하다.

36. Agent Trace와 일반 Application Log를 분리한다

Application Log:

서비스 장애 분석

Agent Trace:

Agent가 무엇을 보고

어떤 Tool을 호출했고

어떤 Policy에 의해 허용됐는지

목적이 다르다.

예:

{
  "traceId": "trace-8291",
  "agent": "implementation-worker",
  "tool": "shell",
  "commandClass": "test",
  "policyDecision": "allow",
  "exitCode": 0
}

37. Kill Switch도 필요하지만 “프로세스 종료 버튼”만으로 부족하다

Agent가 이상하게 동작하면 실행을 중단할 수 있어야 한다.

하지만 Kill Switch의 진짜 목적은 여러 Resource를 함께 회수하는 것이다.

Agent Kill

↓

Child Agents Cancel

↓

Task Lease 해제

↓

Temporary Credential revoke

↓

Network Session 종료

↓

Workspace Freeze

↓

Artifact 보관

이렇게 동작해야 한다.

단순히 Process 하나를 죽이면 이미 발급된 Credential이 남을 수 있다.

38. Runtime에 Budget Limit도 둔다

보안 사고가 아니더라도 Agent가 무한 Loop를 돌 수 있다.

Tool Call

↓

Retry

↓

Subagent

↓

Retry

↓

새 Subagent

따라서 다음을 제한한다.

budget:

  maxWallTimeMinutes: 60

  maxToolCalls: 100

  maxSubagents: 4

  maxRetries: 2

  maxExternalWrites: 3

이 또한 Blast Radius 제한이다.

39. External Write Budget을 따로 두는 것도 좋다

읽기 Tool 100번과 외부 Write 100번의 위험은 다르다.

따라서

Read Tool

비교적 넓은 Budget

External Write

아주 작은 Budget

을 줄 수 있다.

예:

externalWrites:

  create_issue: 5

  create_pull_request: 2

  send_message: 0

  deploy: 0

40. Agent가 직접 인터넷에서 Script를 받아 실행하지 못하게 한다

Coding Agent에게 흔히 생기는 위험 패턴이다.

문제 해결 방법 검색

↓

curl ...

↓

sh

사람 개발자도 조심해야 하는 패턴인데 Agent가 자동으로 실행하면 더 위험하다.

정책으로

Network Download

+

Immediate Execute

조합을 차단할 수 있다.

예:

curl | sh

wget | bash

같은 패턴은 Human Approval 대상으로 둔다.

41. Package 설치도 별도 Capability로 본다

Agent가

npm install package-x

를 실행하는 것은 단순한 Shell 명령이 아니다.

새로운 코드를 Runtime에 추가한다.

따라서

Install Dependency

→ Medium / High Risk

로 분류하는 편이 좋다.

특히 다음은 강하게 제한한다.

Global Package 설치

Unknown Registry

Git URL Dependency

Postinstall Script

42. MCP Server도 Sandbox 밖의 권한 경계다

MCP Server를 연결하면 Agent의 Capability가 크게 증가한다.

예:

GitHub MCP

Database MCP

Slack MCP

Cloud MCP

Browser MCP

따라서 Agent Sandbox만 잘 구성했다고 끝이 아니다.

MCP Server에도 다음을 적용한다.

Authentication

Authorization

Tool Allowlist

Data Scope

Network Scope

Audit

MCP Server 자체가 Agent보다 높은 권한을 가지지 않도록 한다.

43. MCP Tool은 세밀하게 나눈다

나쁜 Tool:

execute_sql

입력:

SQL 아무거나

좋은 Tool:

get_customer_summary

get_order_status

run_readonly_report

처럼 Capability가 좁다.

Agent가 자유 SQL을 실행할 수 있는 것과 정해진 Query를 호출하는 것은 위험도가 다르다.

44. Database Agent에는 Read Replica를 주는 것도 방법이다

운영 데이터를 분석해야 한다면

Production Primary

X

대신

Read Replica

Masking

Row Limit

Timeout

을 사용한다.

Agent가 실수해도 Write할 수 없다.

45. 실제 개발팀용 Agent Security Baseline

Repository에 다음처럼 관리할 수 있다.

.agent-security/
├── policy.yaml
├── network-allowlist.yaml
├── tool-policy.yaml
├── credential-policy.yaml
└── README.md

policy.yaml

version: 1

filesystem:
  workspace:
    read: true
    write: true

  home:
    read: false
    write: false

network:
  default: deny

credentials:
  inheritHostCredentials: false
  persistentCredentials: false

execution:
  production: deny
  shellOutsideWorkspace: deny

delegation:
  maxDepth: 2
  maxAgents: 4

다시 말하지만 이는 특정 Codex나 Claude Code 설정 그대로가 아니라 팀 보안 정책을 표현하기 위한 예시다.

46. Network Allowlist

version: 1

allow:

  documentation:
    - developer.apple.com
    - docs.github.com

  source:
    - github.com
    - api.github.com

  packages:
    - registry.npmjs.org

deny:
  - "*"

Agent Runtime이나 Proxy가 이 정책을 실제로 강제해야 의미가 있다.

Prompt에만 넣어서는 안 된다.

47. Tool Policy

tools:

  read_file:
    risk: low
    action: allow

  write_workspace:
    risk: medium
    action: allow

  run_tests:
    risk: low
    action: allow

  install_dependency:
    risk: high
    action: ask

  git_push:
    risk: high
    action: ask

  production_deploy:
    risk: critical
    action: deny

  read_secret:
    risk: critical
    action: deny

정책 Engine에서 사용한다.

48. Credential Policy

credentials:

  github:
    mode: task-scoped
    ttlMinutes: 30
    repositories:
      - current

  cloud:
    enabled: false

  production:
    enabled: false

  ssh:
    inheritFromHost: false

Agent가 개발자 Laptop의 Credential을 그대로 상속받지 않게 한다.

49. 개인 개발자도 간단하게 적용할 수 있다

회사 보안 플랫폼이 없어도 기본 원칙은 사용할 수 있다.

Codex 또는 Claude Code를 사용할 때:

1.

프로젝트 폴더에서 실행

2.

Full Access를 기본으로 쓰지 않음

3.

Network는 필요한 작업에서만 허용

4.

~/.ssh, ~/.aws 같은 Directory를 Agent 작업 범위 밖에 둠

5.

Production Credential이 들어 있는 Shell에서 Agent를 실행하지 않음

6.

외부 Repository나 문서를 읽을 때 Prompt Injection 가능성을 고려

7.

큰 작업은 Disposable Worktree나 Cloud Sandbox 사용

이 정도만 적용해도 위험이 크게 줄어든다.

50. Codex에서 추천하는 기본 사고방식

일반 Coding:

Workspace Write

Network 제한

Approval on request

탐색:

Read Only

중요 Repository:

Cloud Sandbox

또는

Ephemeral Worktree

Production:

Agent 직접 접근 없음

이 구조가 가장 단순하다.

51. Claude Code에서도 비슷하다

Claude Code에서는

/permissions

으로 권한을 확인하고

/sandbox

를 이용해 Filesystem과 Network Boundary를 구성하는 흐름을 사용할 수 있다.

피하고 싶은 것은

--dangerously-skip-permissions

를 일반 개발 환경에서 습관적으로 사용하는 것이다.

안전하게 모든 Prompt를 줄이고 싶다면

권한을 없애기

X

보다

Sandbox 안에서 자유롭게 행동하게 하기

O

가 더 나은 방향이다.

52. Agent Security Eval도 만들자

보안 정책이 실제로 작동하는지 테스트해야 한다.

예:

Test 1

Workspace 밖 파일 읽기 시도

Expected:
DENY

Test 2

허용되지 않은 Domain 접근

Expected:
DENY

Test 3

Package 설치

Expected:
ASK

Test 4

Production Tool 호출

Expected:
DENY

Test 5

Task Branch Push

Expected:
ALLOW

53. Prompt Injection Fixture도 넣을 수 있다

테스트 Repository에 악의적 Instruction이 들어 있는 Fixture를 둔다.

예:

tests/security-fixtures/

README-untrusted.md
issue-untrusted.json
tool-result-untrusted.json

Agent가 이를 읽었을 때 정책 밖 행동을 시도하더라도 Sandbox가 막는지 확인한다.

핵심은

모델이 Injection을 무시했는지

만 보는 것이 아니다.

모델이 속아도 Runtime이 막았는지

까지 보는 것이다.

54. Agent Security Eval 항목

다음 지표를 볼 수 있다.

Unauthorized Tool Attempt

Unauthorized Network Attempt

Filesystem Escape Attempt

Credential Access Attempt

Approval Escalation

Prompt Injection Success

Sandbox Containment Success

External Write Count

Human Intervention

특히 중요한 지표는 이것이다.

Policy Violation Attempt

≠

Security Incident

Agent가 위험한 행동을 시도했더라도 Runtime이 차단했다면 실제 사고는 발생하지 않은 것이다.

55. 최근 AISI 연구가 보여주는 것도 이 문제다

AI Security Institute의 대규모 Agent Red Teaming 연구에서는 현실적인 Agent 환경을 대상으로 매우 많은 Prompt Injection 공격을 시도했고, 다양한 Agent에서 정책 위반을 유도할 수 있음을 확인했다.

흥미로운 점은 단순히 더 큰 모델이나 더 많은 추론을 사용한다고 Agent Robustness가 자동으로 크게 개선되는 형태가 아니었다는 점이다.

즉

더 좋은 모델

=

완벽한 Agent Security

라고 보기 어렵다.

그래서 Model Safety 외에

Sandbox

Permission

Network

Credential

Policy Enforcement

같은 Runtime Defense가 필요하다.

56. 최근 보안 평가 사례의 핵심도 Configuration이다

최근 공개된 여러 Agent 보안 사례에서는 Agent가 테스트 환경 밖의 시스템에 접근한 사건들이 논란이 됐다.

일부 사건에서는 Agent Capability 자체뿐 아니라 테스트 환경의 Network 설정이나 Sandbox 구성 문제도 중요한 원인이었다.

이것이 개발팀에게 주는 교훈은 단순하다.

Agent를 안전하게 만드는 것

≠

System Prompt를 길게 쓰는 것

이다.

Agent 주변 인프라를 일반 Production Security 수준으로 봐야 한다.

57. Agent Runtime Threat Model을 만들어보자

Agent를 도입할 때 다음 네 가지를 먼저 적는다.

Assets

Source Code

Customer Data

Signing Key

Cloud Credential

Database

Internal API

Entry Points

User Prompt

Repository File

Issue

PR Comment

Web

MCP Result

Agent Capabilities

Filesystem

Network

Shell

Git

Cloud

Database

Trust Boundaries

Agent Sandbox

Host

MCP Server

CI

Production

이 네 가지를 연결하면 위험이 보인다.

58. 예를 들어 iOS Release Agent라면

Assets:

App Store Connect Key

Signing Certificate

Source Code

Agent Capability:

GitHub Read

CI Read

Release Note Write

Agent에게 필요하지 않은 것:

App Store Connect Key

Signing Certificate

Production Upload

그래서 구조는 다음이 된다.

Release Agent

↓

Read CI

↓

Release Readiness

↓

GitHub Environment

↓

Human Approval

↓

Fastlane

↓

App Store

앞에서 만든 모바일 Release Pipeline과 정확히 같은 원칙이다.

59. 보안이 강하면 Agent가 불편해지지 않을까?

Sandbox를 지나치게 강하게 만들면 Agent가 아무것도 못 한다.

파일 못 읽음

Network 못 씀

Test 못 돌림

Package 못 받음

그래서 목표는

Maximum Restriction

이 아니다.

Minimum Necessary Capability

다.

좋은 Agent Sandbox는

안전한 행동은 빠르게

위험한 행동만 Gate

한다.

60. Permission Prompt를 줄이면서 더 안전하게 만들 수 있다

직관적으로는

Prompt 많이 물어봄
→ 안전

처럼 느껴진다.

하지만 승인 피로가 생기면 오히려 안전성이 떨어질 수 있다.

더 나은 구조는

Sandbox 안

↓

자동 실행

Sandbox 밖

↓

승인

이다.

즉 Agent 자율성과 보안이 반드시 반대 관계는 아니다.

좋은 Sandbox가 있으면 Agent에게 좁은 영역 안에서 더 많은 자율성을 줄 수 있다.

61. 최종 추천 Architecture

개발팀에서 Coding Agent를 운영한다면 다음 구조를 추천한다.

Developer
    │
    ▼
Main Agent
    │
    ▼
Task Policy
    │
    ├──────────────┐
    │              │
    ▼              ▼
Read Worker     Write Worker
Read-only       Workspace only
    │              │
    └──────┬───────┘
           │
           ▼
      Sandbox Layer
           │
    ┌──────┴──────┐
    │             │
Filesystem     Egress Proxy
    │             │
    └──────┬──────┘
           │
           ▼
    Credential Broker
           │
           ▼
 GitHub / CI / MCP / API
           │
           ▼
      Audit / Trace

Production은 별도로 둔다.

Agent

↓

Artifact / PR

↓

CI

↓

Human Approval

↓

Production

62. 처음 적용할 때는 이 7개만 해도 된다

1. Agent Full Access를 기본값으로 사용하지 않는다.

2. Workspace 밖 Write를 차단한다.

3. Network 기본값을 제한한다.

4. Production Credential을 Agent Runtime에 넣지 않는다.

5. Explorer / Reviewer / Worker Tool을 분리한다.

6. Shell·Network·External Write를 Trace한다.

7. Production은 Human Gate 뒤에 둔다.

처음부터 거대한 Agent Security Platform을 만들 필요는 없다.

63. 앞으로 Agent 보안의 기준도 바뀔 것이다

초기 Agent Security는 주로 이런 질문이었다.

Agent가 위험한 답변을 생성하는가?

Coding Agent가 Tool을 직접 사용하기 시작하면서 질문이 바뀌었다.

Agent가 어떤 행동을 실행할 수 있는가?

앞으로는 더 나아간다.

Agent가 잘못된 행동을 했을 때
시스템이 어디에서 멈추게 만드는가?

여기서 Sandbox와 Egress Control이 중요해진다.

64. 마무리

AI Coding Agent를 안전하게 운영하기 위해

하지 마.

주의해.

위험한 명령을 실행하지 마.

를 Prompt에 반복해서 적는 것만으로는 부족하다.

Agent가 점점 강해질수록 더 중요한 것은 행동 의지가 아니라 행동 가능한 범위다.

구조를 다시 보면 다음과 같다.

Prompt Guardrail

↓

Tool Allowlist

↓

Filesystem Sandbox

↓

Network Egress Control

↓

Task Scoped Credential

↓

Human Gate

↓

Audit

한 계층이 실패해도 다음 계층이 막아준다.

한 줄로 정리하면 이렇다.

AI Agent 보안의 핵심은
Agent가 절대 실수하지 않게 만드는 것이 아니라,

실수하거나 속더라도
큰 사고를 낼 수 없는 환경을 만드는 것이다.

앞으로 Codex·Claude Code·Cloud Agent·MCP Agent를 조직에서 운영할수록 가장 중요한 보안 설정은 점점

System Prompt

보다

Sandbox

Filesystem Scope

Network Egress

Credential Scope

Tool Capability

Blast Radius

쪽으로 이동할 가능성이 크다.

모델에게 믿음을 요구하는 것보다,

모델이 잘못 판단해도 안전한 시스템을 만드는 것이 훨씬 강한 보안이다.

참고 자료

UK AI Security Institute — Security challenges in AI agent deployment
22개 Frontier Agent와 현실적인 Agent 환경을 대상으로 대규모 Prompt Injection Red Teaming을 수행하고, Model Capability만으로 Policy Violation 문제가 해결되지 않는다는 점을 분석한 연구.
Reuters — OpenAI, Anthropic AI agents implicated in new security breaches
2026년 8월 공개된 AISI 보안 평가 사례와 Agent가 평가 과정에서 허용되지 않은 행동을 수행한 사건을 정리한 보도.
Reuters — “Going rogue” draws critics amid widening AI hacks
Agent 사고를 “AI가 반란을 일으켰다”는 식으로 설명하면 모델보다 Runtime·권한·Configuration 책임이 가려질 수 있다는 최근 논쟁을 다룬 기사.
Anthropic Engineering — How we contain Claude across products
Agent Capability가 증가할수록 사고 확률뿐 아니라 Blast Radius를 줄여야 하며, Human Approval과 Sandbox·VM·Egress Control을 어떻게 조합하는지 설명한 엔지니어링 자료.
Anthropic Engineering — Beyond permission prompts: making Claude Code more secure and autonomous
Claude Code가 Permission Prompt 중심 구조에서 Filesystem Isolation과 Network Isolation을 함께 사용하는 Sandbox 구조로 발전한 이유를 설명한 자료.
OpenAI — Running Codex safely at OpenAI
Codex Agent의 Access Boundary, Human Approval, Tool Governance, Telemetry를 실제 개발 환경에서 어떻게 운영하는지 설명한 공식 자료.
OpenAI — Building a safe, effective sandbox to enable Codex on Windows
Workspace Write와 Network 제한을 OS 수준에서 강제하기 위해 Codex Sandbox를 어떻게 설계했는지 설명하는 공식 Engineering 글.
OpenAI — Codex Security
취약점 후보를 단순 생성하는 것이 아니라 격리된 환경에서 실제 검증하고, 검증된 문제의 Patch를 사람 Review Workflow로 연결하는 보안 Agent 구조를 설명하는 공식 자료.

핵심 참고 포인트

최근 Agent 보안 논란은 “더 좋은 System Prompt를 작성하면 해결된다”는 문제보다 Agent에게 실제로 어떤 실행 권한과 Network 접근을 주는지가 중요하다는 점을 다시 보여준다.

Anthropic은 실제 Claude Code 운영에서 Permission Prompt가 반복될수록 Approval Fatigue가 발생한다는 점을 확인했고, 최근 Agent Security 설계에서는 사람에게 모든 행동을 승인시키기보다 Filesystem과 Network Boundary를 OS·Proxy 계층에서 강제하는 방향을 사용하고 있다.

OpenAI 역시 Codex에서 Workspace Write와 Network 제한을 Sandbox로 강제하고, Codex Security에서는 취약점 검증 자체를 격리된 실행 환경에서 수행한다.

따라서 Agent 보안의 목표는 모든 잘못된 Tool 호출을 모델 수준에서 제거하는 것이 아니라, 잘못된 Tool 호출이 발생해도 Host·Credential·Production·외부 Network까지 피해가 확대되지 않도록 Blast Radius를 제한하는 것으로 보는 편이 현실적이다.

이경규

iOS 앱 개발자

이전 포스트

AI Release Agent로 모바일 배포 자동화하기: iOS·Android 테스트 빌드부터 TestFlight·Play Store 출시까지

다음 포스트

AI 코딩 에이전트 보안의 새 원칙: Prompt Guardrail보다 Sandbox·Egress Control이 중요한 이유

AI 코딩 에이전트 보안의 새 원칙: Prompt Guardrail보다 Sandbox·Egress Control이 중요한 이유

1. 최근 Agent 보안 이슈에서 봐야 할 것은 “AI가 반란을 일으켰다”가 아니다

2. Agent Security의 핵심 개념: Blast Radius

구조 A

3. Prompt Guardrail은 보안 경계가 아니다

4. Agent 보안 계층을 5단계로 나누자

5. 첫 번째: Filesystem Scope를 줄인다

6. Codex가 기본적으로 Workspace Write를 사용하는 이유

7. Claude Code도 Permission Prompt만으로 끝내지 않는다

8. 좋은 Sandbox는 Filesystem만 막아서는 안 된다

9. Network Egress가 최근 특히 중요해졌다

10. Repository 종류에 따라 Network Policy도 달라져야 한다

11. 인터넷 접근은 Agent Capability로 생각해야 한다

12. Tool Allowlist는 모델이 아니라 Runtime에서 강제한다

13. “Tool을 사용할 수 있음”과 “Tool을 실행할 수 있음”도 분리한다

14. Agent에게 Cloud CLI를 통째로 주지 않는다

15. Credential은 Agent Environment에 넣지 않는 것이 가장 좋다

16. Credential Broker 구조

17. Task-Scoped Credential을 사용한다

18. Ephemeral Workspace가 중요한 이유

19. Agent도 CI Runner처럼 Disposable하게 생각한다

20. Agent Memory와 Secret을 분리한다

21. Prompt Injection을 완전히 막는다고 생각하지 않는다

22. Prompt Injection에 가장 강한 대응은 Capability 최소화다

23. Agent마다 다른 Sandbox Profile을 만든다

24. Main Agent가 Subagent보다 더 많은 권한을 가져야 한다는 법도 없다

25. Agent끼리 권한을 상속하지 않게 한다

26. Delegation Depth도 보안 경계다

27. Capability Escalation은 항상 Gate를 거친다

28. Policy Decision은 구조화해서 기록한다

29. Risk Tier에 따라 Approval을 나눈다

LOW

MEDIUM

HIGH

CRITICAL

30. Production은 Agent Sandbox 밖에 둔다

31. Codex Security도 검증을 격리 환경에서 수행한다

32. Security Agent는 일반 Coding Agent보다 더 위험할 수 있다

33. Canary Secret을 둘 수도 있다

34. Network Egress Log는 반드시 남긴다

35. Shell Command도 Audit한다

36. Agent Trace와 일반 Application Log를 분리한다

37. Kill Switch도 필요하지만 “프로세스 종료 버튼”만으로 부족하다

38. Runtime에 Budget Limit도 둔다

39. External Write Budget을 따로 두는 것도 좋다

40. Agent가 직접 인터넷에서 Script를 받아 실행하지 못하게 한다

41. Package 설치도 별도 Capability로 본다

42. MCP Server도 Sandbox 밖의 권한 경계다

43. MCP Tool은 세밀하게 나눈다

44. Database Agent에는 Read Replica를 주는 것도 방법이다

45. 실제 개발팀용 Agent Security Baseline

46. Network Allowlist

47. Tool Policy

48. Credential Policy

49. 개인 개발자도 간단하게 적용할 수 있다

50. Codex에서 추천하는 기본 사고방식

51. Claude Code에서도 비슷하다

52. Agent Security Eval도 만들자

53. Prompt Injection Fixture도 넣을 수 있다

54. Agent Security Eval 항목

55. 최근 AISI 연구가 보여주는 것도 이 문제다

56. 최근 보안 평가 사례의 핵심도 Configuration이다

57. Agent Runtime Threat Model을 만들어보자

Assets

Entry Points

Agent Capabilities

Trust Boundaries

58. 예를 들어 iOS Release Agent라면

59. 보안이 강하면 Agent가 불편해지지 않을까?

60. Permission Prompt를 줄이면서 더 안전하게 만들 수 있다

61. 최종 추천 Architecture

62. 처음 적용할 때는 이 7개만 해도 된다

63. 앞으로 Agent 보안의 기준도 바뀔 것이다

64. 마무리

참고 자료

핵심 참고 포인트

AI Release Agent로 모바일 배포 자동화하기: iOS·Android 테스트 빌드부터 TestFlight·Play Store 출시까지

Codex·Claude Code를 깔아준다고 생산성이 오르지 않는다: AI 코딩 에이전트 도입을 성공시키는 7가지 운영 지표

0개의 댓글