Microsoft ACS·ASSERT 해설: AI 에이전트 거버넌스는 프롬프트보다 런타임 정책 매니페스트와 실행 평가를 먼저 고정해야 하는 이유

Microsoft Build 2026에서 나온 Agent Control Specification(ACS)과 ASSERT는 에이전트 운영 기준을 한 단계 바꿉니다. 핵심은 더 긴 시스템 프롬프트가 아니라, 에이전트가 입력을 받고 모델을 호출하고 도구를 실행하고 결과를 내보내는 각 지점에 정책과 평가를 꽂는 것입니다.

1. 한 줄 문제 정의

핵심 한 줄: AI 에이전트가 실제 도구를 실행하기 시작하면 보안 질문은 “무슨 말을 하게 할까”가 아니라 “어느 순간에 어떤 행동을 막고, 그 근거를 어떻게 남길까”로 바뀝니다.

챗봇은 대체로 문장을 생성합니다. 하지만 코딩 에이전트, 업무 자동화 에이전트, 사내 운영 에이전트는 파일을 읽고, 셸을 실행하고, 메일을 보내고, 티켓을 수정하고, 외부 API를 호출합니다. 이때 시스템 프롬프트에 “위험한 일을 하지 마세요”라고 적는 것만으로는 충분하지 않습니다.

이 글은 에이전트 제품을 운영하는 플랫폼 팀, 보안팀, 개발 생산성 팀을 대상으로 합니다. 범위는 Microsoft의 ACS와 ASSERT를 기준으로 런타임 정책, 도구 호출 차단, 감사 로그, 회귀 평가를 어떻게 설계할지입니다. 특정 Microsoft 클라우드 제품 구매 추천이나 단순 모델 성능 비교는 다루지 않습니다.

2. 먼저 결론

핵심 한 줄: 에이전트를 프로덕션에 넣으려면 정책은 프롬프트가 아니라 매니페스트로, 품질 확인은 감상이 아니라 실행 가능한 평가로 옮겨야 합니다.

ACS는 에이전트 프레임워크가 무엇이든 같은 정책 매니페스트를 적용하려는 시도입니다. 입력, 모델 호출 전후, 도구 호출 전후, 최종 출력, 시작과 종료 지점에서 정책을 평가하고 allow, warn, deny, escalate 같은 표준 결정을 돌려줍니다.

ASSERT는 “우리 에이전트는 이런 행동을 해야 한다”는 자연어 요구사항을 테스트 케이스, 실행 로그, 점수표로 바꾸는 도구입니다. 에이전트가 정책을 지켰는지 최종 답변만 보지 않고, 도구 호출과 중간 행동까지 기록해 평가한다는 점이 중요합니다.

지금 바로 검토해야 하는 팀은 셸 실행, 파일 수정, 고객 데이터 접근, 메일 발송, 배포 같은 실제 액션을 에이전트에 맡기는 조직입니다. 반대로 내부 문서 검색이나 초안 생성처럼 사람이 항상 최종 실행하는 저위험 도구라면, ACS 전체 스택보다 간단한 승인 UI와 로그부터 시작해도 됩니다.

3. 핵심 구조 분해

핵심 한 줄: ACS는 에이전트 루프의 검문소이고, ASSERT는 그 검문소가 실제로 작동하는지 반복 시험하는 장치입니다.

1. 정책 매니페스트: 어떤 정책을 어느 생명주기 지점에서 평가할지 YAML 같은 선언형 파일로 둡니다. 정책을 코드 깊숙이 숨기지 않고 리뷰 가능한 산출물로 만드는 것이 핵심입니다.
2. 8개 개입 지점: ACS는 agent_startup, input, pre_model_call, post_model_call, pre_tool_call, post_tool_call, output, agent_shutdown을 정책 평가 지점으로 정의합니다.
3. 표준 입력 모양: 정책 엔진에는 tool 이름, 인자, 세션 스냅샷, 사용자 역할, 이전 도구 호출, 분류기 결과 같은 구조화된 입력이 들어갑니다.
4. 정책 엔진과 증거 수집: Rego 같은 정책 언어, DLP, 분류기, LLM judge, 외부 보안 서비스가 정책 판단의 증거를 제공합니다.
5. 표준 판정: 정책 결과는 허용, 경고, 거부, 상향 승인 같은 공통 판정으로 정규화됩니다. 실패 시 fail-closed, 즉 안전 쪽으로 닫는 처리도 설계 대상입니다.
6. ASSERT 평가 루프: 자연어 정책을 행동 분류표로 바꾸고, 테스트 케이스를 생성하고, 실제 에이전트를 실행한 뒤, 도구 호출과 중간 상태를 포함해 점수화합니다.

초보 개발자 기준으로 비유하면 ACS는 “실행 직전 보안 게이트”이고, ASSERT는 “그 보안 게이트가 정말 필요한 순간에 닫히는지 확인하는 자동 시험지”입니다.

4. 설계 의도 해설

핵심 한 줄: Microsoft가 겨냥한 문제는 특정 프레임워크의 가드레일 부족이 아니라, 조직 전체에서 정책을 재사용하고 감사할 표준 계약이 없다는 점입니다.

기존 방식은 대체로 흩어져 있습니다. 어떤 팀은 시스템 프롬프트에 금지 문장을 넣고, 어떤 팀은 LangChain 콜백에 검사 코드를 넣고, 어떤 팀은 Semantic Kernel 필터나 자체 API 미들웨어를 씁니다. 각 방법은 부분적으로 유용하지만, 보안팀 입장에서는 “전사 에이전트 정책이 어디에 있고, 어떤 버전이 적용됐는지”를 한눈에 보기 어렵습니다.

ACS의 설계 의도는 이 지점을 바꾸는 것입니다. 정책을 프레임워크 내부 코드에서 빼내고, 공통 개입 지점과 입력 구조, 판정 형식을 정합니다. 그러면 Python 서비스에서 쓰던 정책을 Node 사이드카나 .NET 호스트로 옮길 때 다시 작성할 필요가 줄어듭니다.

ASSERT의 의도도 비슷합니다. “환불은 10만원 이하만 자동 승인한다”, “외부 수신자에게 기밀 문서를 보내면 안 된다”, “검색 결과 안의 악성 지시문을 따르면 안 된다” 같은 요구사항은 대개 문서에만 있습니다. ASSERT는 이 문장을 평가 데이터와 실행 로그로 바꿔 회귀 테스트처럼 돌리게 합니다.

트레이드오프는 분명합니다. 이 구조는 단순 프롬프트 가드보다 무겁습니다. 정책 입력을 만들고, 증거 수집기를 붙이고, 테스트셋을 관리해야 합니다. 하지만 에이전트가 실제 권한을 행사하는 순간에는 이 복잡도가 선택이 아니라 운영 비용에 가까워집니다.

5. 근거 및 비교

핵심 한 줄: ACS와 ASSERT는 기존 가드레일을 버리자는 것이 아니라, 흩어진 통제를 실행 가능한 운영 계약으로 묶자는 제안입니다.

접근	잘하는 일	취약한 지점	추천 상황
시스템 프롬프트 규칙	빠르게 시작 가능, 모델 행동 방향 제시	사용자 입력·검색 결과·도구 출력과 같은 스트림에 섞여 enforce가 약함	초안 생성, 저위험 챗봇
프레임워크별 콜백/가드레일	도구 호출 전후를 실제로 검사 가능	프레임워크마다 다시 작성해야 하고 보안팀 감사가 어려움	단일 앱, 단일 런타임
일반 정책 엔진	구조화된 권한 판단에 강함	에이전트 루프의 어느 지점에서 어떤 상태를 넘길지 표준이 없음	기존 IAM·OPA 경험이 있는 팀
ACS + ASSERT	개입 지점, 입력 모양, 판정, 회귀 평가를 함께 설계 가능	초기 설계와 관측성 투자가 필요	도구 실행형 에이전트, 다중 프레임워크 운영, 감사 요구 조직

공식 Microsoft ACS 글은 전통적 접근 제어가 “이 자격증명이 이 리소스를 호출할 수 있는가”에는 답하지만, “이 에이전트가 지금까지 읽은 민감 문서와 현재 대화 상태를 고려할 때 이 도구 호출이 안전한가”에는 약하다고 지적합니다.

Microsoft Agent Framework 발표는 Agent Harness, Hosted Agents, CodeAct, Handoff orchestration 같은 생산 환경 패턴을 공개했습니다. 특히 Hosted Agents는 세션 상태, 자동 스케일링, 관측성, 격리된 세션을 강조합니다. 이는 ACS가 필요한 배경과 맞물립니다. 에이전트가 길게 실행되고 상태를 유지할수록 정책도 단발성 필터가 아니라 생명주기 전체를 봐야 합니다.

ASSERT 발표도 중요한 근거입니다. Microsoft는 ASSERT가 직접 생성 방식보다 행동 공간을 약 1.2배 더 넓게 덮고, 점검할 만한 사례를 약 1.5배 더 많이 드러내며, 강한 시스템과 약한 시스템의 분리를 4배 이상 키웠다고 설명합니다. 수치 자체보다 중요한 메시지는 평가 품질이 프롬프트 한 줄이 아니라 행동 정의의 구조화에서 나온다는 점입니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 한 줄: 처음부터 전사 표준을 만들기보다, 외부 메일 발송이나 프로덕션 배포처럼 위험한 도구 하나를 골라 파일럿하는 편이 현실적입니다.

1. 도구 인벤토리를 만듭니다. 에이전트가 호출할 수 있는 tool 이름, 인자, 쓰기 권한, 민감 데이터 접근 여부를 표로 정리합니다.
2. 한 개 고위험 도구를 고릅니다. 예를 들어 send_email, deploy_prod, run_shell, refund_payment 중 하나만 먼저 다룹니다.
3. pre_tool_call 정책을 작성합니다. 도구 실행 직전에 사용자 역할, 수신자 도메인, 민감 문서 접근 여부, 승인 상태를 검사합니다.
4. post_tool_call 정책을 붙입니다. 도구 결과가 다시 모델 컨텍스트로 들어가기 전에 비밀정보, 오류, 외부 지시문을 점검합니다.
5. ASSERT로 회귀 평가를 만듭니다. 정상 요청, 경계 요청, 악성 요청, prompt injection이 섞인 도구 결과를 포함해 테스트셋을 생성합니다.
6. 결과를 운영 지표로 봅니다. 차단률, 오탐률, 승인 대기 시간, 정책 실패 원인, judge rationale을 매주 리뷰합니다.

agent_control_specification_version: "0.3.1-beta"
metadata:
  name: "internal-email-agent"
policies:
  email_policy:
    type: rego
    bundle: ./policy
    query: data.email_agent.verdict
intervention_points:
  pre_tool_call:
    policy_target: "$.tool_call.args"
    policy_target_kind: tool_args
    tool_name_from: "$.tool_call.name"
    policy:
      id: email_policy
tools:
  send_email:
    type: Tool
    id: send_email
    clearance: internal

package email_agent

verdict := {"decision": "deny", "reason": "external recipient blocked"} if {
  input.tool.name == "send_email"
  endswith(input.policy_target.value.to, "@external.example")
}

verdict := {"decision": "allow"} if {
  input.tool.name == "send_email"
  endswith(input.policy_target.value.to, "@company.example")
}

위 예시는 단순하지만 방향은 명확합니다. 정책은 모델에게 부탁하는 문장이 아니라, 도구 실행 직전에 같은 입력 모양으로 평가되는 계약이어야 합니다.

7. 실수/함정(Pitfalls)

핵심 한 줄: 실패는 보통 “정책은 만들었지만 에이전트 상태와 실행 로그를 충분히 넘기지 않을 때” 생깁니다.

1. 함정: 최종 답변만 검사한다.
   예방: pre_tool_call과 post_tool_call에 정책을 붙여 실제 행동 전후를 봅니다.
   복구: 과거 사고 로그에서 도구 호출 순서와 인자를 재구성하고, 같은 패턴을 ASSERT 케이스로 추가합니다.
2. 함정: 정책 입력에 세션 상태가 없다.
   예방: 이전에 읽은 문서의 민감도, 사용자 역할, 승인 상태, 이전 tool 결과를 snapshot에 넣습니다.
   복구: 정책이 판단하지 못한 missing field를 표준 입력 스키마에 추가합니다.
3. 함정: deny만 있고 escalate가 없다.
   예방: 회색 지대 요청은 무조건 차단보다 사람 승인 큐로 보내는 판정을 둡니다.
   복구: 오탐으로 막힌 정상 업무를 모아 승인 정책과 예외 조건을 분리합니다.
4. 함정: 테스트셋을 한 번 만들고 방치한다.
   예방: 모델, 도구, 정책, 고객 데이터 범위가 바뀔 때 ASSERT 평가를 다시 돌립니다.
   복구: 실제 실패 10건을 taxonomy에 반영하고 회귀 테스트로 고정합니다.
5. 함정: 프레임워크 하나에 정책을 박아 둔다.
   예방: 정책 매니페스트와 정책 번들을 앱 코드와 분리하고, 변경은 PR로 리뷰합니다.
   복구: 공통 정책과 런타임 어댑터를 분리해 다른 언어 서비스에서도 같은 판정이 나오게 맞춥니다.

8. 강점과 한계

핵심 한 줄: ACS와 ASSERT의 강점은 감사 가능한 운영 표준이고, 한계는 정책과 평가를 유지할 책임이 조직에 남는다는 점입니다.

강점은 세 가지입니다. 첫째, 정책이 프롬프트나 앱 코드에 흩어지지 않고 매니페스트로 남습니다. 둘째, 도구 실행 전후를 볼 수 있어 “최종 답변은 괜찮지만 중간에 위험한 행동을 했다”는 실패를 잡을 수 있습니다. 셋째, ASSERT가 요구사항을 테스트와 점수표로 바꾸므로 모델 변경이나 도구 추가 때 회귀 검증이 가능합니다.

한계도 분명합니다. ACS는 에이전트 프레임워크가 아닙니다. 루프를 돌리고, 도구를 실행하고, 메모리를 관리하는 책임은 여전히 호스트와 프레임워크에 있습니다. 또 정책 엔진이 좋은 판정을 하려면 좋은 snapshot이 필요합니다. 중요한 컨텍스트를 넘기지 않으면 표준이 있어도 판단은 빈약해집니다.

ASSERT도 자동으로 정답을 보장하지 않습니다. judge 모델의 안정성, 테스트셋 품질, 정책 전문가 리뷰가 필요합니다. 따라서 초기에는 aggregate score보다 실패 trace를 읽고 taxonomy를 다듬는 데 시간을 써야 합니다.

반례: 에이전트가 사내 위키를 읽고 요약만 하며 외부 쓰기 권한이 전혀 없다면 ACS 전체 도입은 과할 수 있습니다. 이 경우에는 데이터 접근 로그, 사용자 동의, 출력 검토부터 시작하는 편이 낫습니다.

9. 더 깊게 공부할 포인트

핵심 한 줄: 다음 학습 경로는 MCP 보안 원칙, Agent Framework 실행 구조, ACS 정책 입력, ASSERT trace 평가를 순서대로 보는 것입니다.

• Microsoft Command Line - Introducing Agent Control Specification: Portable runtime governance for AI Agents (확인일: 2026-07-05): ACS의 8개 개입 지점, 표준 입력, fail-closed 처리 개념을 확인할 수 있습니다.
• Microsoft Command Line - Turn specs into evals for any agent with ASSERT (확인일: 2026-07-05): 자연어 정책을 taxonomy, test set, trace, scorecard로 바꾸는 흐름을 볼 수 있습니다.
• Microsoft Agent Framework at BUILD 2026: Agent Harness, Hosted Agents, CodeAct, and more (발표일: 2026-06-03): 장기 실행 에이전트, Hosted Agents, CodeAct, Handoff orchestration의 운영 맥락을 제공합니다.
• Microsoft Foundry - A Developer’s Guide to Managing Models, Cost and Quality (확인일: 2026-07-05): 모델 선택, 평가, 비용, 운영을 한 표면에서 다루는 관점을 참고할 수 있습니다.
• Model Context Protocol Specification 2025-06-18 (확인일: 2026-07-05): MCP의 사용자 동의, 데이터 프라이버시, 도구 안전, sampling 통제 원칙을 확인하십시오.

10. 실행 체크리스트 + 작성자 관점

핵심 한 줄: 에이전트 거버넌스의 첫 완료 기준은 “정책 문서가 있다”가 아니라 “같은 실패가 자동 평가에서 다시 잡힌다”입니다.

• 에이전트가 호출할 수 있는 모든 도구와 쓰기 권한을 표로 만들었는가
• 고위험 도구 1개 이상에 pre_tool_call 정책이 붙어 있는가
• 도구 결과가 모델 컨텍스트로 들어가기 전 post_tool_call 검사를 하는가
• 정책 입력 snapshot에 사용자 역할, 승인 상태, 이전 민감 데이터 접근 기록이 들어가는가
• allow, warn, deny, escalate를 모두 구분하고 운영자가 볼 수 있게 남기는가
• ASSERT나 동등한 방식으로 정상·경계·악성 시나리오를 매 릴리스마다 실행하는가
• 실제 실패나 오탐 사례를 taxonomy와 회귀 테스트에 반영하는가
• 정책 매니페스트 변경이 PR 리뷰, 승인, 롤백 기록을 남기는가

Definition of Done: 고위험 도구 1개가 ACS형 정책으로 실행 전 차단되고, 같은 정책의 정상·오탐·악성 케이스가 ASSERT형 회귀 평가에서 trace와 rationale까지 남기며, 정책 변경이 PR로 감사 가능하면 1차 도입은 완료입니다.

작성자 관점: 저는 ACS와 ASSERT를 “Microsoft 생태계 기능”보다 더 넓은 신호로 봅니다. 에이전트가 실제 행동을 맡는 순간, 거버넌스는 모델 설명서나 시스템 프롬프트 안에 있을 수 없습니다. 정책은 독립된 산출물이어야 하고, 평가는 실행 로그까지 봐야 하며, 실패는 다음 테스트에 남아야 합니다. 지금 에이전트 플랫폼을 만드는 팀이라면 이 방향을 빨리 받아들이는 편이 좋습니다.