AI 코딩 에이전트도 Policy as Code가 필요하다: managed-settings.json으로 권한·플러그인·모델 통제하기

AI 코딩 에이전트를 개인이 사용할 때는 설정이 단순하다.

개발자
↓
Codex / Claude Code / Copilot
↓
프로젝트 작업

사용할 모델을 고르고, 필요한 MCP Server나 Plugin을 연결한 뒤 작업하면 된다.

하지만 팀 전체가 에이전트를 사용하기 시작하면 문제가 달라진다.

개발자 A
→ 승인 없이 모든 명령 자동 실행

개발자 B
→ 검증되지 않은 Plugin 설치

개발자 C
→ 개인 MCP Server 연결

개발자 D
→ 비용이 높은 모델을 항상 사용

Cloud Agent
→ 로컬과 다른 정책으로 작업

각 개발자가 설정을 따로 관리하면 조직의 AI 개발 환경은 빠르게 흩어진다.

보안 담당자는 다음을 알기 어렵다.

누가 어떤 Plugin을 사용하는가?

어떤 Marketplace에서 설치했는가?

Agent가 명령 실행 승인을 건너뛸 수 있는가?

Cloud Agent도 같은 정책을 적용받는가?

사용자가 로컬에서 정책을 덮어쓸 수 있는가?

최근 GitHub는 Enterprise Managed Settings의 적용 범위를 Copilot 앱과 Copilot Cloud Agent까지 확대했다.

이제 하나의 managed-settings.json으로 여러 Copilot Client에 공통 Guardrail을 적용할 수 있다.

구조는 다음과 같다.

Enterprise Policy Repository

copilot/managed-settings.json
              │
              ├── VS Code
              ├── Copilot CLI
              ├── Copilot App
              └── Copilot Cloud Agent

이번 글에서는 이를 단순한 GitHub 기능 소개가 아니라 AI Coding Agent용 Policy as Code 관점에서 정리해본다.

1. Agent Policy as Code가 뭔가

기존 Infrastructure as Code는 Server와 Network 구성을 코드로 관리한다.

Terraform

Kubernetes YAML

CloudFormation

Policy as Code는 보안과 운영 규칙을 코드로 관리한다.

누가 무엇을 실행할 수 있는가

어떤 Resource에 접근할 수 있는가

어떤 변경에 승인이 필요한가

AI Agent에서도 같은 구조가 필요하다.

Agent가 어떤 Tool을 사용할 수 있는가

어떤 Plugin을 설치할 수 있는가

명령 실행 승인을 건너뛸 수 있는가

어떤 모델을 기본값으로 사용할 것인가

Telemetry를 어디로 보낼 것인가

이 규칙을 관리자 화면에서만 설정하지 않고 Repository의 파일로 관리하는 것이 Agent Policy as Code다.

2. 왜 개인 설정만으로는 부족할까

개발자 로컬 설정은 편하지만 조직 정책으로는 약하다.

예를 들어 사용자가 자신의 설정 파일에서 다음과 같이 구성할 수 있다고 하자.

{
  "permissions": {
    "allowAllCommands": true
  }
}

또는 승인 없이 명령을 실행하는 모드를 켤 수 있다.

Agent
→ Shell 명령 제안
→ 승인 생략
→ 즉시 실행

개인 프로젝트에서는 개발자가 위험을 감수할 수 있다.

하지만 기업 Repository에서는 다르다.

rm

git reset --hard

curl

npm install

brew install

배포 Script

Cloud CLI

이런 명령을 Agent가 승인 없이 실행할 수 있으면 사고 범위가 커진다.

조직 정책은 사용자 설정보다 높은 우선순위를 가져야 한다.

3. 정책 우선순위를 명확하게 만든다

관리형 설정에서는 여러 설정 출처가 존재할 수 있다.

MDM

Server-managed Policy

로컬 File

User Setting

일반적으로 상위 관리 정책이 하위 개인 설정보다 우선해야 한다.

개념적으로는 다음과 같다.

MDM Policy
    ↓
Enterprise Server Policy
    ↓
Project / File Setting
    ↓
User Setting

사용자가 로컬 설정을 바꿔도 Enterprise Policy가 강제한 항목은 덮어쓸 수 없어야 한다.

Enterprise

승인 우회 금지

Developer Local

승인 우회 활성화

최종 결과:

승인 우회 금지

이게 관리형 정책의 핵심이다.

4. 관리 Repository부터 만든다

GitHub 방식에서는 보통 Enterprise 내부의 비공개 관리 Repository를 사용한다.

구조는 다음과 같다.

.github-private/
└── copilot/
    └── managed-settings.json

이 Repository는 일반 제품 코드와 분리하는 것이 좋다.

제품 Repository

my-ios-app
backend-api
admin-web

AI 정책 Repository

.github-private

정책 변경 권한도 제한한다.

Enterprise Owner

AI Platform Team

Security Team

일반 개발자가 직접 Merge하지 못하게 한다.

5. 첫 managed-settings.json 만들기

처음에는 정책을 너무 많이 넣지 않는다.

가장 위험도가 높은 세 가지부터 시작한다.

{
  "permissions": {
    "disableBypassPermissionsMode": true
  },
  "strictKnownMarketplaces": true,
  "enabledPlugins": []
}

의미는 단순하다.

승인 우회 제한

허용된 Marketplace만 사용

승인된 Plugin만 사용

실제 지원되는 값과 Schema는 사용하는 GitHub Enterprise 및 Client 버전의 공식 Reference에 맞춰 확인해야 한다.

6. 승인 우회를 막는 것이 1순위다

Agent Tool에는 Side Effect가 있다.

파일 수정

Shell 실행

URL 접근

외부 API 호출

Git Push

일반적인 Interactive Client는 실행 전 사용자에게 묻는다.

Agent가 이 명령을 실행하려고 합니다.

허용하시겠습니까?

그러나 일부 Client에는 모든 승인을 건너뛰는 모드가 있을 수 있다.

흔히 다음처럼 부른다.

YOLO Mode

Auto Approve

Bypass Permissions

Enterprise에서는 이를 기본적으로 차단하는 편이 안전하다.

{
  "permissions": {
    "disableBypassPermissionsMode": true
  }
}

이 정책의 목적은 Agent 사용을 막는 것이 아니다.

읽기와 분석
→ 빠르게

위험한 실행
→ 확인 후

으로 경계를 나누는 것이다.

7. 모든 명령에 승인받게 하면 생산성이 떨어진다

반대로 명령 하나마다 승인을 요구하면 Agent Workflow가 지나치게 느려진다.

파일 읽어도 될까요?

검색해도 될까요?

테스트를 실행할까요?

Git Diff를 볼까요?

그래서 위험도에 따라 구분하는 것이 좋다.

낮은 위험

파일 읽기

코드 검색

Git Diff

Local Test

정적 분석

자동 허용 후보.

중간 위험

작업 폴더 파일 수정

Package Lockfile 변경

Local Build Script 실행

팀 정책에 따라 허용.

높은 위험

외부 Network 요청

새 Package 설치

Git Push

Issue 생성

PR 생성

명시적인 승인 또는 제한된 Scope.

치명적 위험

Production Deploy

Secret 변경

Repository 삭제

Database Migration

Signing 변경

사람 승인 필수.

8. Permission Matrix를 따로 만든다

정책 파일 하나만 보면 운영 의도를 이해하기 어려울 수 있다.

Repository에 설명 문서를 함께 둔다.

.github-private/
├── copilot/
│   └── managed-settings.json
│
└── docs/
    ├── permission-matrix.md
    ├── plugin-policy.md
    └── incident-response.md

permission-matrix.md 예시:

# Agent Permission Matrix

| Action | Interactive Agent | Cloud Agent | Approval |
|---|---|---|---|
| Read repository | Allow | Allow | No |
| Run unit tests | Allow | Allow | No |
| Modify task files | Allow | Allow | No |
| Install package | Ask | Deny | Yes |
| Push branch | Ask | Allow on task branch | Policy |
| Merge PR | Deny | Deny | Human |
| Deploy production | Deny | Deny | Human |

Agent 제품이 표의 모든 항목을 직접 지원하지 않더라도 조직의 기준을 명확하게 만드는 데 도움이 된다.

9. Plugin은 Agent의 실행 코드를 확장한다

Plugin을 단순한 UI Extension으로 생각하면 안 된다.

AI Coding Agent Plugin은 다음을 포함할 수 있다.

새 Tool

새 Command

새 Agent

MCP 연결

Skill

외부 실행 코드

즉 Plugin 설치는 Agent의 권한을 확장하는 행동이다.

Agent

기본 Tool

에서

Agent

기본 Tool
+
Database Tool
+
Cloud Tool
+
Deployment Tool

로 바뀐다.

따라서 Plugin도 Package Dependency처럼 검토해야 한다.

10. Marketplace를 제한한다

개발자가 임의의 Marketplace를 추가할 수 있으면 검증되지 않은 Plugin이 들어올 수 있다.

Public Marketplace

개인 Registry

알 수 없는 URL

Fork된 Plugin

조직에서는 허용된 Source만 사용하게 만든다.

개념적인 설정:

{
  "strictKnownMarketplaces": true,
  "extraKnownMarketplaces": [
    {
      "name": "company-agent-marketplace",
      "url": "https://example.invalid/agent-marketplace"
    }
  ]
}

실제 조직 주소와 인증 방식은 외부 공개 문서나 일반 Repository에 넣지 않는다.

11. Private Marketplace 구조

사내 Agent Resource를 중앙에서 관리할 수 있다.

Private Agent Marketplace

├── ios-review-plugin
├── backend-migration-plugin
├── security-review-agent
├── release-note-skill
└── internal-mcp-tools

개발자는 승인된 Resource만 설치한다.

Developer

↓

Approved Marketplace

↓

Reviewed Plugin

개인 URL에서 바로 설치하는 흐름을 막는다.

12. Plugin 검토 절차

새 Plugin을 바로 허용 목록에 넣지 않는다.

Discover

↓

Quarantine

↓

Source Review

↓

Permission Review

↓

Sandbox Test

↓

Approve

↓

Marketplace 등록

검토 항목은 다음과 같다.

어떤 Tool을 추가하는가?

외부 Network 요청을 하는가?

파일 시스템 어디까지 읽는가?

Shell 명령을 실행하는가?

Secret에 접근하는가?

자동 업데이트되는가?

의존 Package가 무엇인가?

앞에서 다룬 Agent Skills Supply Chain과 같은 원리가 Plugin에도 적용된다.

13. enabledPlugins는 Allowlist로 운영한다

허용 Plugin을 명시적으로 관리한다.

개념 예시:

{
  "enabledPlugins": [
    "company/ios-review",
    "company/security-check",
    "company/test-runner"
  ]
}

좋은 운영 원칙은 다음과 같다.

기본 거부

필요한 Plugin만 허용

Version 또는 Revision 고정

업데이트 시 재검토

사용 기록 수집

모든 Plugin을 기본 허용하고 문제가 생긴 뒤 차단하는 방식보다 안전하다.

14. Cloud Agent에는 더 강한 정책이 필요하다

로컬 Interactive Agent와 Cloud Agent는 실행 환경이 다르다.

Interactive Agent

개발자가 화면 앞에 있음

실행 요청을 바로 확인 가능

중간에 취소 가능

Cloud Agent

Background에서 실행

개발자가 자리를 비울 수 있음

수십 분 뒤 PR 생성

여러 Task 동시 진행

Cloud Agent에서는 실행 중 매번 사람에게 Prompt를 띄우기 어렵다.

그래서 사전에 경계를 더 명확하게 정해야 한다.

허용 Plugin

허용 Marketplace

Repository 범위

Branch 정책

Network 정책

Secret Scope

PR 완료 조건

15. Interactive Client와 Cloud Agent 정책은 완전히 같지 않다

중앙 설정을 공유하더라도 모든 Key가 모든 Client에서 똑같이 동작하는 것은 아니다.

예를 들어 승인 우회 제어는 사용자가 상호작용하는 Client에 적용하기 자연스럽다.

Copilot App

Copilot CLI

VS Code

Cloud Agent는 사용자에게 매 명령 승인 Prompt를 보여주는 방식이 아니므로, 다른 정책 계층이 필요하다.

Repository Permission

Workflow Permission

Plugin Allowlist

Branch Protection

Ruleset

Environment Approval

따라서 중앙 설정 하나로 모든 보안 문제가 해결된다고 생각하면 안 된다.

16. Cloud Agent는 GitHub 보호 장치와 함께 쓴다

Cloud Agent의 결과는 PR로 들어오게 한다.

Issue

↓

Cloud Agent

↓

Task Branch

↓

Pull Request

↓

CI

↓

Code Review

↓

Merge

Agent가 main에 직접 반영하지 않게 한다.

GitHub 쪽에서는 다음을 같이 적용한다.

Branch Protection

Required Review

Required Status Check

CODEOWNERS

Ruleset

Environment Approval

Agent Policy와 Repository Policy를 함께 사용해야 한다.

17. Model 기본값도 정책 대상이다

조직에서 모델 선택을 완전히 사용자에게 맡기면 비용과 결과가 크게 달라질 수 있다.

개발자 A

항상 최고급 모델

개발자 B

항상 빠른 모델

개발자 C

매번 임의 선택

Model Router를 중앙에서 직접 구현하지 않더라도 기본값을 정할 수 있다.

예:

{
  "model": "auto"
}

Auto Model Selection을 기본으로 두면 Client가 작업에 따라 적절한 모델을 선택하도록 할 수 있다.

다만 다음은 구분해야 한다.

기본값

≠

강제 고정

지원되는 Client와 Key에 따라 사용자가 변경할 수 있는 범위가 다를 수 있다.

18. 비용 상한은 별도 계층에서 관리한다

Model 기본값만으로 비용을 통제하기 어렵다.

다음도 같이 본다.

사용자별 Budget

Cost Center

AI Credit Pool

Session Limit

Input / Output Token Limit

정책 구조는 다음처럼 나눌 수 있다.

managed-settings.json

→ Client 동작과 Guardrail

GitHub Billing / AI Controls

→ 사용자·조직 비용

Repository Policy

→ 어떤 작업에 Agent를 쓰는가

하나의 설정 파일에 모든 책임을 넣지 않는다.

19. Token Limit도 운영 정책이다

BYOK나 Custom Endpoint를 사용할 경우 Input·Output Token Limit을 설정할 수 있는 Client가 있다.

예를 들어

maxInputToken

maxOutputToken

을 지나치게 크게 설정하면 비용과 지연 시간이 늘어난다.

지나치게 작으면 Agent가 필요한 Context를 읽지 못한다.

Task Type별 기준을 잡는 편이 좋다.

간단한 Q&A

작은 Context

일반 Coding

중간 Context

Repository Review

큰 Context

모든 Task에 최대 Context를 주는 방식은 피한다.

20. Telemetry도 중앙에서 관리한다

Agent Workflow에서는 일반 IDE 사용보다 더 많은 운영 정보가 필요하다.

Agent Run

Model

Tool Call

Latency

Token

Error

Approval

Plugin

OpenTelemetry로 내보내면 기존 관찰 시스템과 연결할 수 있다.

Copilot Client

↓

OpenTelemetry Export

↓

Collector

↓

Grafana / Datadog / New Relic / 사내 시스템

다만 Source Code와 Prompt 전체를 무조건 수집하면 안 된다.

21. Telemetry에 무엇을 남길까

권장 후보:

Client 종류

Agent Session ID

Model 이름

실행 시간

Tool 호출 수

성공·실패

승인 요청 수

사용 Credit

Error Code

주의할 데이터:

전체 Prompt

Source Code 원문

Secret

사용자 개인정보

Private Repository 경로

Tool Argument 전체

Telemetry Schema를 미리 정의한다.

{
  "sessionId": "session-142",
  "client": "copilot-app",
  "model": "auto",
  "durationMs": 94211,
  "toolCalls": 18,
  "approvalRequests": 3,
  "status": "completed"
}

Source Code는 넣지 않는다.

22. OpenTelemetry Attribute도 Allowlist로 관리한다

무분별하게 모든 Attribute를 Export하지 않는다.

telemetry:
  attributes:
    allow:
      - client.type
      - model.name
      - session.duration_ms
      - tool.call_count
      - run.status

    deny:
      - prompt.content
      - tool.arguments
      - source.code
      - authorization

제품이 이 정확한 YAML 구조를 지원한다는 의미는 아니다.

조직의 Telemetry Policy를 표현한 예시다.

23. Cross-client 정책이 중요한 이유

한 개발자가 여러 Surface를 사용할 수 있다.

VS Code에서 코드 작성

Copilot App에서 긴 Task 실행

CLI에서 Repository 조사

Cloud Agent에 Issue 위임

한 Client만 보호하면 우회 경로가 생긴다.

예:

VS Code

미승인 Plugin 차단

하지만

Copilot App

미승인 Plugin 허용

이면 정책이 약해진다.

보안은 가장 느슨한 Surface 기준으로 무너진다.

그래서 중앙 Policy가 모든 Client를 따라가야 한다.

24. 최근 GitHub 변화의 의미

이전에는 managed-settings.json이 VS Code와 Copilot CLI를 중심으로 적용됐다.

최근 업데이트로 Copilot 앱과 Cloud Agent도 같은 관리 범위에 들어왔다.

Before

VS Code
Copilot CLI

After

VS Code
Copilot CLI
Copilot App
Copilot Cloud Agent

조직이 하나의 정책 파일을 더 넓은 Agent Surface에 적용할 수 있게 된 것이다.

25. Copilot App 사용 여부도 별도 정책으로 나뉜다

모든 조직이 Desktop Agent App을 허용해야 하는 것은 아니다.

이제 Copilot App 자체의 접근 정책을 독립적으로 관리할 수 있다.

개념적인 선택은 다음과 같다.

전체 허용

전체 차단

Organization별 결정

CLI는 허용하지만 App은 차단할 수도 있다.

Copilot CLI

Enabled

Copilot App

Disabled

Client별 위험과 운영 준비 상태가 다를 수 있기 때문이다.

26. 처음부터 전사 적용하지 않는다

Agent Policy는 Pilot을 거치는 편이 좋다.

1단계

AI Platform Team

2단계

개발 조직 일부

3단계

일반 Engineering

4단계

전사 확대

Pilot에서는 다음을 본다.

업무가 지나치게 막히는가?

필요한 Plugin이 차단되는가?

승인 Prompt가 너무 많은가?

Cloud Agent가 Task를 끝낼 수 있는가?

Telemetry가 충분한가?

비용이 예상 범위인가?

27. 초기 정책은 최소 제한부터 시작한다

처음부터 모든 것을 차단하면 사용자가 정책 우회를 찾게 된다.

28. managed-settings.json 예시

아래는 구조를 이해하기 위한 개념 예시다.

실제 적용 전에는 최신 GitHub Reference의 Key와 Value Type을 확인해야 한다.

{
  "permissions": {
    "disableBypassPermissionsMode": true
  },

  "strictKnownMarketplaces": true,

  "extraKnownMarketplaces": [
    {
      "name": "company-approved",
      "url": "https://example.invalid/marketplace"
    }
  ],

  "enabledPlugins": [
    "company/ios-review",
    "company/security-check"
  ],

  "model": "auto"
}

정책 파일에는 Secret을 넣지 않는다.

Token

Private Key

Marketplace Credential

API Key

는 별도 Secret Store에서 관리한다.

29. JSON Schema 검증을 붙인다

설정 파일의 오타는 전사 Client에 영향을 줄 수 있다.

예:

{
  "disableBypassPermissionMode": true
}

정확한 Key가 아니라면 적용되지 않을 수 있다.

CI에서 Schema를 검증한다.

Pull Request

↓

JSON Parse

↓

Schema Validation

↓

Policy Test

↓

Security Review

↓

Merge

간단한 Node Script를 만들 수 있다.

import { readFile } from "node:fs/promises";

async function main(): Promise<void> {
  const raw = await readFile(
    "copilot/managed-settings.json",
    "utf8"
  );

  const value = JSON.parse(raw);

  if (typeof value !== "object" || value === null) {
    throw new Error("managed-settings.json must be an object");
  }

  console.log("JSON syntax is valid.");
}

main().catch(error => {
  console.error(error);
  process.exit(1);
});

이 코드는 JSON 문법만 확인한다.

실제 Key 검증에는 공식 Schema 또는 조직에서 유지하는 별도 Schema가 필요하다.

30. 조직용 Policy Schema 만들기

GitHub 공식 지원 Key 외에도 조직 정책을 별도 파일로 관리할 수 있다.

policy/
├── copilot-policy.yaml
├── plugin-allowlist.yaml
├── tool-risk.yaml
└── telemetry-policy.yaml

예:

version: 1

clients:
  copilot-app:
    enabled: true

  copilot-cli:
    enabled: true

  cloud-agent:
    enabled: true

permissions:
  bypass: denied

plugins:
  default: deny

cloudAgent:
  directMainPush: denied
  pullRequestRequired: true

production:
  deploy: human-approval

이 파일을 기준으로 managed-settings.json과 GitHub 정책이 일치하는지 CI에서 확인할 수 있다.

31. Policy를 여러 파일에 중복하지 않는다

같은 규칙이 다음에 모두 들어가면 문제가 생긴다.

managed-settings.json

Repository AGENTS.md

Security 문서

Cloud Agent Prompt

Plugin 설정

한 곳은 강제 정책, 다른 곳은 설명이나 작업 지침으로 나눈다.

강제 정책

managed-settings.json

AI Controls

Branch Ruleset

Environment Approval

Agent 행동 지침

AGENTS.md

Custom Agent Instruction

Skill

사람용 설명

Policy Documentation

강제할 수 없는 Prompt 문장을 보안 정책처럼 믿지 않는다.

32. AGENTS.md로 보완한다

관리 설정이 Client 수준의 Guardrail이라면 AGENTS.md는 Repository 작업 규칙을 담당한다.

# Repository Agent Rules

## Scope

- Modify only files required by the assigned task.
- Do not change generated files.
- Ask before adding dependencies.

## Validation

- Run relevant tests after behavior changes.
- Never report a test as passed unless it ran successfully.

## Git

- Never push directly to main.
- Submit changes through a pull request.

## High-risk actions

- Do not modify signing settings.
- Do not deploy production.
- Do not rotate secrets.

역할을 구분한다.

managed-settings.json

→ Client와 Tool 사용 경계

AGENTS.md

→ Repository 안의 작업 방식

33. Plugin Policy와 Tool Policy도 구분한다

Plugin이 허용됐다고 Plugin이 제공하는 모든 Tool을 자동 허용할 필요는 없다.

예:

GitHub Plugin

├── read_pull_request
├── create_issue
├── merge_pull_request
└── delete_repository

Plugin 전체는 승인됐지만 위험 Tool은 별도 제한할 수 있어야 한다.

plugin: github

tools:
  read_pull_request:
    risk: low
    action: allow

  create_issue:
    risk: medium
    action: ask

  merge_pull_request:
    risk: high
    action: deny

  delete_repository:
    risk: critical
    action: deny

Client가 Tool 단위 정책을 직접 지원하지 않으면 MCP Gateway나 Tool Server에서 강제한다.

34. MCP Gateway와 함께 쓰면 더 강해진다

Client Policy는 Plugin과 Marketplace를 통제한다.

MCP Gateway는 실제 Tool 호출을 통제한다.

Copilot Client

↓

Managed Settings

↓

Approved MCP Plugin

↓

MCP Gateway

↓

Tool Authorization

↓

GitHub / Database / Cloud

두 계층이 필요하다.

Client Guardrail

어떤 확장을 연결할 수 있는가

Runtime Guardrail

실제로 무엇을 실행할 수 있는가

35. Cloud Agent Secret은 최소 Scope로 제공한다

Cloud Agent가 사내 Resource를 사용하려면 Credential이 필요할 수 있다.

좋지 않은 방식:

Enterprise-wide Admin Token

권장 방식:

Task별 단기 Credential

Repository 제한 Token

Read-only Scope

만료 시간 설정

가능하면 Agent에게 Secret 값을 직접 보여주지 않는다.

Agent

→ Tool 호출

Tool Server

→ Secret 사용

구조로 둔다.

36. 정책 변경은 코드 리뷰를 거친다

managed-settings.json의 한 줄이 전체 개발 환경을 바꿀 수 있다.

Plugin 허용

Marketplace 추가

승인 우회 설정

모델 기본값 변경

일반 설정 파일보다 엄격하게 관리한다.

Pull Request

↓

AI Platform Review

↓

Security Review

↓

Policy Test

↓

Merge

CODEOWNERS 예시:

/copilot/managed-settings.json @ai-platform @security
/policy/ @ai-platform @security

37. 정책 변경 내역을 Release Note로 남긴다

예:

# Agent Policy 2026-08-01

## Added

- Approved `company/ios-review` plugin.
- Enabled Copilot App for mobile team pilot.

## Changed

- Default model selection set to auto.

## Restricted

- Bypass permission mode disabled.
- Unknown plugin marketplaces blocked.

## Rollback

Revert commit `abc123`.

문제가 생기면 어느 변경 때문인지 추적할 수 있다.

38. Rollback이 가능해야 한다

정책 변경으로 모든 개발자의 Workflow가 막힐 수 있다.

예:

필수 Plugin이 Allowlist에서 빠짐

Marketplace URL 오류

설정 Schema 오류

Rollback 절차를 미리 만든다.

문제 감지

↓

이전 Commit Revert

↓

Client Refresh 확인

↓

영향 사용자 공지

정책도 Deployment처럼 취급한다.

39. Client에 언제 적용되는지도 확인한다

중앙 정책이 Merge됐다고 모든 Client에 즉시 반영된다고 가정하면 안 된다.

일반적인 반영 시점은 다음과 같을 수 있다.

주기적 Refresh

Client 재시작

다시 로그인

다음 Cloud Task

정책 변경 후 검증 Matrix를 사용한다.

VS Code

적용 확인

Copilot CLI

적용 확인

Copilot App

적용 확인

Cloud Agent

새 Task에서 확인

40. 적용 여부를 자동 점검한다

각 Client에서 현재 Effective Policy를 확인할 수 있다면 결과를 수집한다.

{
  "client": "copilot-app",
  "policyVersion": "2026-08-01.1",
  "bypassDisabled": true,
  "marketplaceStrict": true
}

서버 정책 파일과 비교한다.

Expected Policy

vs

Effective Policy

불일치한 Client를 찾는다.

41. Policy Drift를 감지한다

Policy Drift는 중앙 정책과 실제 Client 상태가 달라지는 것이다.

원인:

오래된 Client Version

정책 Refresh 실패

로그인 계정 불일치

MDM 설정 충돌

지원하지 않는 Key

Network 문제

Drift 상태를 다음처럼 관리할 수 있다.

Compliant

Outdated

Unsupported

Unknown

Conflicting

42. Agent 정책도 Eval이 필요하다

보안 정책이 강하다고 무조건 좋은 것은 아니다.

개발 업무를 지나치게 막으면 실패한다.

대표 Task를 만들어본다.

Task 1

일반 Bug Fix

Task 2

Unit Test 실행

Task 3

새 Package가 필요한 기능

Task 4

Cloud Agent PR 생성

각 정책에서 성공하는지 본다.

43. 정책 Eval 항목

Task Completion Rate

Approval Prompt 수

차단된 정상 Tool 수

허용된 위험 Tool 수

평균 완료 시간

Agent Retry 수

Developer Override 요청

Security Incident

예:

{
  "policyVersion": "2026-08-01.1",
  "task": "normal-bug-fix",
  "completed": true,
  "approvalPrompts": 3,
  "blockedTools": [],
  "durationSec": 412
}

정책이 너무 느슨한지, 너무 강한지 조정한다.

44. Break-glass 절차도 필요하다

긴급 장애 상황에서는 평소보다 높은 권한이 필요할 수 있다.

그러나 개발자가 자신의 로컬 설정으로 임의 우회하면 안 된다.

별도의 Break-glass 절차를 둔다.

긴급 요청

↓

승인자 확인

↓

시간 제한 권한

↓

모든 행동 Audit

↓

자동 만료

↓

사후 Review

Agent의 승인 우회 기능을 항상 열어두는 것과 완전히 다르다.

45. 팀별 예외는 최소화한다

팀마다 다른 정책이 필요할 수 있다.

모바일 팀

Xcode Tool 필요

Backend 팀

Kubernetes Tool 필요

하지만 모든 팀에 별도 정책을 만들면 관리가 어려워진다.

구조를 계층화한다.

Enterprise Baseline

↓

Team Extension

↓

Repository Rule

Enterprise Baseline

승인 우회 차단

미승인 Marketplace 차단

Production 직접 실행 금지

Team Extension

허용 Plugin 추가

Repository Rule

AGENTS.md 작업 규칙

46. 처음 도입할 때 권장 구조

.github-private/
│
├── copilot/
│   └── managed-settings.json
│
├── policy/
│   ├── baseline.yaml
│   ├── plugin-allowlist.yaml
│   ├── tool-risk.yaml
│   └── telemetry.yaml
│
├── schema/
│   └── organization-policy.schema.json
│
├── tests/
│   ├── validate-settings.ts
│   ├── validate-plugins.ts
│   └── policy-fixtures/
│
├── docs/
│   ├── permission-matrix.md
│   ├── plugin-review.md
│   └── break-glass.md
│
└── CODEOWNERS

정책, 문서, 검증 코드를 한 Repository에서 관리한다.

47. CI 예시

name: Validate Agent Policy

on:
  pull_request:
    paths:
      - "copilot/**"
      - "policy/**"
      - "schema/**"

jobs:
  validate:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - run: npm ci

      - name: Validate JSON
        run: npm run validate:settings

      - name: Validate plugin allowlist
        run: npm run validate:plugins

      - name: Run policy fixtures
        run: npm run test:policy

이 Pipeline을 실제로 실행하지 않았다면 통과한다고 주장해서는 안 된다.

48. Policy Fixture 만들기

tests/
└── policy-fixtures/
    ├── approved-plugin.json
    ├── unknown-marketplace.json
    ├── bypass-request.json
    └── production-deploy.json

예:

{
  "name": "unknown-marketplace",
  "input": {
    "marketplace": "https://unknown.invalid"
  },
  "expected": {
    "decision": "deny"
  }
}

정책 변경마다 회귀 테스트한다.

49. Agent Policy Decision을 구조화한다

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

  reason: string;

  policyId: string;

  requiresHumanApproval: boolean;
};

예:

{
  "decision": "deny",
  "reason": "Marketplace is not enterprise-approved.",
  "policyId": "PLUGIN-MARKETPLACE-001",
  "requiresHumanApproval": false
}

Agent에게 자연어 한 줄만 주는 것보다 Audit하기 쉽다.

50. 정책을 Prompt에만 적지 않는다

다음 문장을 Agent Prompt에 적을 수 있다.

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

하지만 이것만으로는 강제 정책이 아니다.

Agent가 잘못 판단하거나 Prompt 충돌이 발생할 수 있다.

보안 경계는 다음 위치에서 강제해야 한다.

Client Managed Settings

MCP Gateway

Tool Server

GitHub Ruleset

Environment Approval

Prompt는 행동을 안내하지만 권한 시스템을 대체하지 않는다.

51. 이 변화가 중요한 이유

AI Coding Agent는 이제 IDE 안의 보조 기능 하나가 아니다.

Desktop App

CLI

IDE

Cloud Agent

Issue Automation

PR Review

MCP Tool

여러 Surface에서 동작한다.

Agent가 늘어날수록 개별 개발자의 좋은 판단에만 의존하기 어렵다.

설정 공유

Plugin 검증

권한 통제

비용 관리

Telemetry

Audit

가 Platform 기능이 된다.

52. 앞으로 Agent Platform 팀이 생길 가능성이 높다

기존 Platform Engineering 팀은 다음을 관리했다.

CI/CD

Developer Portal

Cloud Environment

Observability

Security Baseline

앞으로는 여기에 Agent Runtime이 추가된다.

Approved Models

Agent Clients

MCP Registry

Plugin Marketplace

Skills

Permission Policy

Eval

Cost

Trace

Agent Policy as Code는 이 작업의 기본 단위가 될 수 있다.

53. 개인 개발자도 적용할 수 있다

Enterprise 기능을 사용하지 않더라도 같은 원칙을 프로젝트에 적용할 수 있다.

.ai-policy/
├── allowed-tools.yaml
├── allowed-mcp.yaml
├── plugin-lock.json
├── risk-policy.yaml
└── README.md

예:

tools:
  read_file: allow
  run_tests: allow
  install_package: ask
  git_push: ask
  deploy_production: deny

Codex나 Claude Code 자체가 이 파일을 자동 강제하지 않더라도 Wrapper, MCP Gateway, Script에서 활용할 수 있다.

54. 개인용 최소 정책

version: 1

filesystem:
  allowed:
    - "./"

network:
  default: deny

commands:
  safe:
    - git status
    - git diff
    - swift test

  approval:
    - git push
    - npm install

  denied:
    - rm -rf
    - git push --force

production:
  deploy: denied

처음에는 이 정도만 있어도 Agent 사용 경계를 명확하게 만들 수 있다.

55. 마무리

AI Coding Agent가 한 명일 때는 개인 설정으로 충분해 보인다.

하지만 Agent가 여러 Client와 Cloud 환경으로 확장되면 문제가 달라진다.

VS Code

Copilot CLI

Copilot App

Cloud Agent

각 Surface가 서로 다른 Plugin과 권한 정책을 가지면 가장 약한 지점이 전체 보안 경계가 된다.

최근 GitHub의 변화는 Agent 운영이 다음 단계로 넘어가고 있음을 보여준다.

개발자가 Agent를 선택한다.

↓

조직이 Agent의 행동 경계를 코드로 관리한다.

좋은 Agent Policy는 무조건 차단하는 정책이 아니다.

낮은 위험 작업

→ 빠르게 자동화

높은 위험 작업

→ 승인과 검증

으로 나누는 정책이다.

기본 구조는 다음과 같다.

managed-settings.json

→ Client Guardrail

Plugin / Marketplace Policy

→ 확장 공급망 통제

MCP Gateway / Tool Policy

→ 실제 행동 통제

Branch Ruleset / CI

→ 코드 반영 통제

OpenTelemetry / Audit

→ 실행 관찰

한 줄로 정리하면 이렇다.

AI Agent 시대의 Policy as Code는
에이전트에게 무엇을 시킬지 적는 문서가 아니라,

에이전트가 어디까지 행동할 수 있는지를
모든 개발 환경에서 일관되게 강제하는 코드다.

앞으로 Agent를 팀 단위로 운영할수록 좋은 Prompt보다 먼저 필요한 것은 Plugin Allowlist, Permission Gate, Model Policy, Telemetry, Rollback을 포함한 공통 Guardrail이 될 가능성이 높다.

참고 자료

GitHub Changelog — Enterprise managed settings in the GitHub Copilot app and Copilot cloud agent
managed-settings.json의 적용 범위가 Copilot 앱과 Cloud Agent까지 확대된 최신 변경 사항을 설명하는 공식 자료.
GitHub Docs — Configuring enterprise-managed settings
Server-managed, MDM-managed, File-based 배포 방식과 .github-private Repository를 이용한 중앙 설정 방법을 확인할 수 있는 공식 문서.
GitHub Docs — Enterprise managed settings reference
Permission 우회 제한, Plugin, Marketplace, Model, Telemetry 등 현재 지원되는 Key와 Client별 지원 여부를 확인할 수 있는 공식 Reference.
GitHub Changelog — Manage GitHub Copilot app access with a dedicated policy
Copilot 앱과 CLI 접근 정책을 독립적으로 관리하는 방법과 Enterprise·Organization 단위 선택지를 설명하는 공식 자료.
GitHub Changelog — Copilot for JetBrains OpenTelemetry and model management
Agent Workflow의 OpenTelemetry Export, BYOK Token Limit, Model 제어, MCP Server와 Custom Agent 연결 관련 최신 변경을 설명하는 공식 자료.

핵심 참고 포인트

GitHub는 2026년 7월 27일부터 Enterprise Managed Settings를 Copilot 앱과 Copilot Cloud Agent까지 확대했다. 기존 VS Code와 Copilot CLI를 포함해 하나의 정책 파일이 더 많은 Agent Surface에 적용된다.

관리자는 managed-settings.json으로 허용 Plugin, Plugin Marketplace, 승인 우회 제한, Auto Model Selection 같은 설정을 중앙에서 배포할 수 있으며, 지원되는 Key에서는 관리 설정이 사용자 로컬 설정보다 우선한다.

Copilot 앱은 Interactive Client이므로 Permission Prompt 우회 제한을 적용할 수 있지만, Cloud Agent는 매 명령마다 사용자 Prompt를 띄우는 구조가 아니므로 Plugin·Marketplace 제한과 함께 Repository Permission, Branch Ruleset, Required Review, Environment Approval을 별도로 구성해야 한다.

정책은 .github-private Repository의 copilot/managed-settings.json에서 관리할 수 있으며, 지원 Client는 인증·재시작·주기적 Refresh 또는 다음 Cloud Task에서 변경된 설정을 반영한다.

따라서 managed-settings.json 하나를 전체 보안 시스템으로 보기보다, Client Guardrail을 담당하는 첫 번째 계층으로 두고 MCP Gateway·Tool Authorization·GitHub Ruleset·Telemetry와 함께 운영하는 것이 적절하다.

이경규

iOS 앱 개발자

이전 포스트

Long-Horizon Agent 설계: Codex와 Claude가 몇 시간·며칠짜리 작업을 끝까지 이어가는 방법

다음 포스트

AI 코딩 에이전트도 Policy as Code가 필요하다: managed-settings.json으로 권한·플러그인·모델 통제하기

AI 코딩 에이전트도 Policy as Code가 필요하다: managed-settings.json으로 권한·플러그인·모델 통제하기

1. Agent Policy as Code가 뭔가

2. 왜 개인 설정만으로는 부족할까

3. 정책 우선순위를 명확하게 만든다

4. 관리 Repository부터 만든다

5. 첫 managed-settings.json 만들기

6. 승인 우회를 막는 것이 1순위다

7. 모든 명령에 승인받게 하면 생산성이 떨어진다

낮은 위험

중간 위험

높은 위험

치명적 위험

8. Permission Matrix를 따로 만든다

9. Plugin은 Agent의 실행 코드를 확장한다

10. Marketplace를 제한한다

11. Private Marketplace 구조

12. Plugin 검토 절차

13. enabledPlugins는 Allowlist로 운영한다

14. Cloud Agent에는 더 강한 정책이 필요하다

Interactive Agent

Cloud Agent

15. Interactive Client와 Cloud Agent 정책은 완전히 같지 않다

16. Cloud Agent는 GitHub 보호 장치와 함께 쓴다

17. Model 기본값도 정책 대상이다

18. 비용 상한은 별도 계층에서 관리한다

19. Token Limit도 운영 정책이다

20. Telemetry도 중앙에서 관리한다

21. Telemetry에 무엇을 남길까

22. OpenTelemetry Attribute도 Allowlist로 관리한다

23. Cross-client 정책이 중요한 이유

24. 최근 GitHub 변화의 의미

25. Copilot App 사용 여부도 별도 정책으로 나뉜다

26. 처음부터 전사 적용하지 않는다

27. 초기 정책은 최소 제한부터 시작한다

28. managed-settings.json 예시

29. JSON Schema 검증을 붙인다

30. 조직용 Policy Schema 만들기

31. Policy를 여러 파일에 중복하지 않는다

강제 정책

Agent 행동 지침

사람용 설명

32. AGENTS.md로 보완한다

33. Plugin Policy와 Tool Policy도 구분한다

34. MCP Gateway와 함께 쓰면 더 강해진다

35. Cloud Agent Secret은 최소 Scope로 제공한다

36. 정책 변경은 코드 리뷰를 거친다

37. 정책 변경 내역을 Release Note로 남긴다

38. Rollback이 가능해야 한다

39. Client에 언제 적용되는지도 확인한다

40. 적용 여부를 자동 점검한다

41. Policy Drift를 감지한다

42. Agent 정책도 Eval이 필요하다

43. 정책 Eval 항목

44. Break-glass 절차도 필요하다

45. 팀별 예외는 최소화한다

Enterprise Baseline

Team Extension

Repository Rule

46. 처음 도입할 때 권장 구조

47. CI 예시

48. Policy Fixture 만들기

49. Agent Policy Decision을 구조화한다

50. 정책을 Prompt에만 적지 않는다

51. 이 변화가 중요한 이유

52. 앞으로 Agent Platform 팀이 생길 가능성이 높다

53. 개인 개발자도 적용할 수 있다

54. 개인용 최소 정책

55. 마무리

참고 자료

핵심 참고 포인트

Long-Horizon Agent 설계: Codex와 Claude가 몇 시간·며칠짜리 작업을 끝까지 이어가는 방법

CLAUDE.md를 지워도 될까: Claude Code 5의 Context·Output Style·Skill을 다시 나누는 방법

0개의 댓글