ASSERT·ACS 공개, 에이전트 정책을 테스트와 차단으로 나눈 Microsoft

AI 요약

• 무슨 일: Microsoft가 Build 2026에서 ASSERT와 ACS를 공개했습니다.
  • ASSERT는 자연어 요구사항을 평가 데이터와 scorecard로 바꾸고, ACS는 agent loop의 여덟 지점에서 정책을 강제합니다.
• 개발자 영향: 에이전트 안전장치가 system prompt와 SDK callback에서 manifest, trace, policy artifact로 내려옵니다.
• 주의점: Microsoft도 LLM judge 안정성, synthetic test 한계, GA 전 breaking change 가능성을 명시했습니다.

Microsoft가 2026년 6월 2일 Build 2026 발표 묶음 안에서 에이전트 거버넌스를 두 갈래로 공개했습니다. 하나는 자연어 정책과 제품 요구사항을 실행 가능한 평가로 바꾸는 오픈소스 프레임워크 ASSERT입니다. 다른 하나는 Agent Control Specification, 줄여서 ACS입니다. ACS는 에이전트가 입력을 받고, 모델을 호출하고, 도구를 실행하고, 결과를 내보내는 런타임 지점마다 정책을 검사하는 manifest와 SDK 계약을 정의합니다.

이번 발표가 단순한 보안 제품 추가로 보이지 않는 이유는 Microsoft가 두 도구를 같은 문장 안에 배치했기 때문입니다. 6월 2일 Microsoft Foundry Build recap은 ASSERT, ACS, Guided Guardrail Setup, Rubric, tracing, Agent Optimizer, Agent ROI를 “trust, evaluation, observability” 개발 루프 항목으로 묶었습니다. 즉 에이전트가 잘 작동하는지 측정하는 평가와, 잘못된 행동을 실행 전에 막는 통제를 같은 운영 문제로 다룹니다.

이 글에서 볼 부분은 제품 이름보다 구조입니다. 지금까지 많은 팀은 system prompt에 금지사항을 쓰고, framework callback에 custom check를 붙이고, classifier로 input과 output을 검사했습니다. Microsoft의 ACS 글은 이 접근이 framework별로 흩어지고, 감사하기 어렵고, 정책 엔진이 agent loop의 어느 순간을 봐야 하는지 모른다고 지적합니다. 에이전트가 데이터베이스를 읽은 뒤 Slack에 요약을 보내는 상황에서 기존 IAM은 “이 credential이 Slack API를 호출할 수 있나”는 답하지만 “이 대화에서 confidential 문서를 읽은 뒤 외부 멤버가 있는 채널에 보내도 되나”는 답하지 못합니다.

ASSERT는 이 문제의 평가 쪽을 맡습니다. Microsoft Responsible AI 팀은 Command Line 블로그에서 ASSERT를 “natural language behavior requirements”를 executable evaluations로 바꾸는 오픈소스 프레임워크라고 설명했습니다. 입력은 제품 요구사항, 정책 문서, system prompt, launch checklist, review note처럼 팀이 이미 작성한 문서입니다. 출력은 taxonomy, test set, inference trace, scores, metrics 같은 로컬 artifact입니다.

ASSERT의 파이프라인은 네 단계로 나뉩니다. 먼저 넓은 행동 명세를 concept specification으로 만들고, 이를 허용·비허용 행동 taxonomy로 세분화합니다. 다음 단계에서는 개발자가 지정한 task type, persona, tool availability, request class, environment configuration 같은 dimension에 맞춰 stratified test case를 생성합니다. 세 번째로 target model, agent, application workflow에 test case를 실행합니다. 마지막으로 각 trace를 taxonomy와 policy stance에 맞춰 채점하고, verdict, rationale, policy citation을 남깁니다.

Microsoft가 든 예시는 여행 계획 에이전트입니다. 이 에이전트는 search_flights, search_hotels, check_weather, check_travel_advisories, validate_budget 다섯 도구를 사용하고, 여섯 turn budget 안에서 itinerary를 만듭니다. 평가 항목은 잘못되거나 생략된 tool use, 조작된 항공편·호텔·가격, 예산 위반, stereotyping, tool output prompt injection, unsafe itinerary에 대한 sycophantic agreement로 나뉩니다. 단일 QA benchmark보다 agent trace가 필요한 이유가 여기서 드러납니다. 최종 답변이 그럴듯해도 실패 위치를 알아야 수정이 가능합니다. 확인 대상은 tool call argument, tool result, routing decision입니다.

ASSERT 발표에서 눈에 띄는 수치는 내부 검증 결과입니다. Microsoft는 다섯 행동 범주와 세 target model을 대상으로 coverage study를 진행했습니다. 이 연구에서 ASSERT는 comparable in-house baseline보다 intended behavior space를 약 1.2배 더 다뤘고, inspect-worthy case를 약 1.5배 더 드러냈습니다. 강한 시스템과 약한 시스템을 가르는 separation은 4배 이상이었다고 밝혔습니다. 모든 모델이 같은 방식으로 답해버리는 saturated case는 절반 수준으로 줄었다고 설명했습니다. failure pattern은 약 2배 더 많이 나왔지만, Microsoft는 failure-type labeling이 coverage나 model separation보다 안정화하기 어렵다며 directional result로 다뤘습니다.

두 번째 검증은 judge입니다. Microsoft는 10개 이상 behavior concept에서 LLM judge가 전체 평가셋을 먼저 채점하고, risk별 sample을 human review와 independent review로 검증했다고 설명했습니다. LLM judge와 human annotator agreement는 보통 80-90% 범위였고, human inter-annotator agreement는 약 90%였습니다. 이 숫자는 ASSERT가 compliance certification이라는 뜻이 아닙니다. Microsoft도 judge model의 strictness, boundary sensitivity, 가까운 행동을 구분하는 안정성이 달라질 수 있다고 적었습니다.

ACS는 평가가 아니라 실행 차단 쪽입니다. Microsoft는 ACS를 framework, runtime, policy engine과 독립적인 open, vendor-neutral standard라고 소개했습니다. 핵심 artifact는 portable manifest입니다. 이 manifest는 어떤 intervention point에서 어떤 policy를 실행할지와 host runtime이 어떤 snapshot을 넘길지를 정의합니다. classifier·DLP·LLM judge 같은 evidence provider 결과를 붙이는 방식도 포함합니다. allow·warn·deny·escalate verdict와 redaction effect를 host가 어떻게 적용할지도 manifest의 범위에 들어갑니다.

ACS가 지정한 interception point는 여덟 개입니다. agent_startup은 에이전트가 시작하기 전 configuration과 environment를 검사합니다. Input은 user input이 model로 들어가기 전에 봅니다. pre_model_call은 모델에 보내는 전체 context를 검사하고, post_model_call은 runtime이 model response를 실행하기 전에 봅니다. pre_tool_call은 tool name과 parameter를 실행 전에 검사하며, post_tool_call은 tool output이 다시 model context로 들어가기 전에 봅니다. output은 최종 응답이 user에게 나가기 전에 검사하고, agent_shutdown은 session 종료 조건과 audit를 다룹니다.

이 구조가 기존 guardrail과 다른 지점은 policy input의 모양입니다. ACS 예시의 canonical input에는 intervention_point, policy_target, snapshot, annotations, tool이 들어갑니다. snapshot은 actor, roles, conversation state, prior tool calls, data sensitivity, approval status 같은 host context를 담을 수 있습니다. annotations에는 classifier, DLP system, LLM judge, external service의 증거가 들어갑니다. policy engine은 이 구조화된 입력을 받아 verdict를 내리고, host는 표준화된 결과를 실행합니다.

Microsoft가 공개한 예시는 이메일 에이전트입니다. 하나의 manifest가 Rego policy를 pre_tool_call에 연결하고, send_email tool의 argument를 평가합니다. 외부 수신자가 있으면 policy가 deny를 반환합니다. 같은 manifest와 같은 snapshot을 Python host와 Node host가 읽어 같은 verdict를 낼 수 있다는 것이 Microsoft의 설명입니다. .NET과 Rust SDK는 같은 snapshot에 대해 같은 verdict를 내는 conformance fixture도 둔다고 밝혔습니다.

여기서 “표준”이라는 표현은 조심해서 읽어야 합니다. ACS는 2026년 6월 현재 Microsoft가 공개한 open specification과 reference implementation입니다. 업계 컨소시엄이 합의한 표준이라고 보기는 이릅니다. 그러나 Microsoft가 CrewAI, LangChain, AutoGen, Semantic Kernel, OpenAI Agents SDK, Anthropic tool-use callback 같은 이름을 같은 문제 공간에 올려놓은 것은 개발자에게 실용적인 신호입니다. 에이전트 framework는 바뀔 수 있고, 기업은 같은 정책을 여러 runtime에 재사용하고 싶어합니다.

Agent Governance Toolkit 저장소는 ACS가 들어갈 실행 환경을 보여줍니다. GitHub README는 Public Preview라고 적고, Python 3.10 이상에서 pip install agent-governance-toolkit[full]로 시작하는 예시를 둡니다. Python, TypeScript, .NET, Rust, Go 예시도 나열되어 있습니다. 저장소 문장은 더 노골적입니다. OAuth scope와 IAM role은 agent가 어떤 service에 닿을 수 있는지 제어하지만, 연결된 뒤 무엇을 하는지는 통제하지 못한다고 설명합니다. 그리고 prompt-level safety를 enforceable control surface가 아니라 stochastic system에 대한 정중한 요청이라고 부릅니다.

이 문장은 에이전트 보안 논의에서 실제 분기점입니다. prompt injection 방어를 prompt 안에서만 해결하려는 방식은 user input, retrieved content, tool result, attacker-controlled text가 같은 token stream에 섞이는 순간 약해집니다. ACS가 하려는 일은 모델이 어떤 intent를 생성했든 tool call이 wire로 나가기 전에 deterministic application code에서 멈추는 것입니다. delete_file, drop_table, 외부 이메일 발송, confidential data 재전송 같은 행동은 모델이 설득당했는지와 무관하게 host runtime에서 차단됩니다.

개발 팀 입장에서 ASSERT와 ACS의 조합은 release process를 바꿀 수 있습니다. ASSERT는 “이 에이전트는 환불 한도 아래에서만 자동 승인한다”, “내부 문서와 공개 정보를 섞되 restricted finding을 인용하지 않는다”, “change-control agent는 approval boundary를 넘지 않는다” 같은 요구사항을 test set과 scorecard로 바꿉니다. ACS는 같은 조직 정책을 runtime manifest로 내려보내 pre_tool_call 또는 output 단계에서 deny, warn, escalate를 실행합니다. 하나는 배포 전 실패를 찾고, 다른 하나는 배포 후 행동을 막습니다.

보안 팀과 플랫폼 팀의 언어도 달라집니다. 이전에는 agent owner가 SDK callback 내부에 custom logic을 넣고, security reviewer가 pull request에서 그 logic을 읽어야 했습니다. ACS식 접근에서는 security team이 policy bundle과 manifest를 versioning하고, host runtime이 canonical input과 evidence를 남기며, audit log가 어떤 policy가 어떤 tool call을 허용하거나 거부했는지 보관합니다. 규제나 내부 감사가 요구하는 질문은 “모델이 안전하다고 판단했나”보다 “어떤 정책이 어느 시점에 어떤 증거로 실행됐나”에 가까워집니다.

Microsoft Security 블로그도 같은 날 발표에서 agentic risk detection과 정책 통제를 개발 lifecycle 안으로 넣었습니다. 특히 Microsoft Purview controls, Data Security Posture Management, Claude Code·GitHub Copilot·OpenAI Codex·OpenClaw 같은 coding agent risk detection을 언급했습니다. Windows 쪽에서는 MXC SDK가 OS-level containment를 맡고, Foundry 쪽에서는 hosted agents, toolboxes, memory, tracing, Agent Optimizer, ROI dashboard가 운영면을 채웁니다. ACS와 ASSERT는 이 큰 묶음 안에서 “정책이 어떤 파일과 trace로 남는가”를 담당합니다.

경쟁 구도에서는 OpenAI와 Anthropic이 빠질 수 없습니다. OpenAI Agents SDK에는 guardrails가 있고, Anthropic의 tool-use 흐름에도 callback과 정책 적용 지점이 있습니다. LangChain callback handler, Semantic Kernel filter, OPA/Rego 직접 통합도 이미 현장에 있습니다. ACS 글은 이들을 부정하지 않고, 각 extension point 위에 표준화된 hook, input shape, enforcement contract가 없다는 점을 짚습니다. Microsoft의 제안이 성공하려면 framework adapter가 실제로 유지되고, policy author가 Microsoft stack 밖에서도 같은 manifest를 쓸 수 있어야 합니다.

ASSERT도 기존 eval 도구와 경쟁합니다. OpenAI Evals, LangSmith, Arize Phoenix, OpenInference 기반 tracing, 사내 benchmark가 이미 있습니다. ASSERT의 차별점은 behavior specification을 first-class input으로 삼는다는 점입니다. 단순히 generic helpfulness, relevance, groundedness, toxicity를 채점하는 것이 아니라, product requirement와 policy boundary에서 test taxonomy를 생성합니다. 저장소 README는 LiteLLM을 통해 100개 이상 model endpoint를 지원하고, OpenInference auto-instrumentation으로 33개 이상 framework trace를 두 줄로 캡처할 수 있다고 설명합니다.

실무 caveat도 분명합니다. ASSERT는 synthetic interaction을 만들기 때문에 production에서만 나타나는 실패를 놓칠 수 있습니다. 정책 문서가 애매하면 taxonomy와 test case도 애매해집니다. LLM judge는 모델별로 엄격함과 경계 판정이 흔들릴 수 있습니다. ACS는 manifest와 SDK가 있어도 host runtime이 snapshot을 정확히 넘겨야 하고, evidence provider가 늦거나 실패할 때 fail-closed를 어떻게 적용할지 제품 UX가 필요합니다. 저장소가 Public Preview인 만큼 GA 전 breaking change도 감수해야 합니다.

그럼에도 이번 발표가 AI 개발자에게 남기는 기준은 선명합니다. 에이전트가 도구를 호출하는 순간부터 안전 요구사항은 문장으로만 남아 있으면 부족합니다. 배포 전에는 요구사항이 평가 dataset, trace, score로 바뀌어야 하고, 배포 후에는 같은 정책이 runtime checkpoint에서 allow, warn, deny, escalate로 실행되어야 합니다. Microsoft가 ASSERT와 ACS를 같은 Build 2026 무대에 올린 이유는 모델 성능 경쟁보다 이 artifact 계층이 기업 도입의 병목이 되고 있기 때문입니다.

커뮤니티 반응은 아직 크지 않습니다. Hacker News와 GeekNews에서 ACS나 ASSERT 자체를 두고 큰 토론은 확인하지 못했습니다. TechCrunch는 ACS를 기업이 agent policy를 여러 환경에서 granular하게 제어하려는 시도로 보도했습니다. Reddit r/AI_Agents에는 Microsoft ACS, Noma, Netskope, Immuta, Outreach 발표를 함께 놓고 agent governance가 agent capability만큼 중요해지는지 묻는 글이 올라왔습니다. 규모는 작지만 질문은 정확합니다. 에이전트가 API를 호출하고 record를 바꾸는 제품이 늘면, 시장은 “누가 승인했고 어떤 증거가 남았나”를 묻기 시작합니다.

개발 팀이 지금 확인할 일은 세 가지입니다. 첫째, 에이전트 요구사항을 policy document나 PRD 문장으로만 두지 말고 평가 artifact로 변환할 수 있는지 봐야 합니다. 둘째, tool call과 output 직전에 정책을 적용할 runtime hook이 있는지 확인해야 합니다. 셋째, 감사가 필요한 action에 대해 trace, policy citation, verdict rationale이 남는지 점검해야 합니다. ASSERT와 ACS가 그대로 표준이 되지 않더라도, 이 세 질문은 2026년 에이전트 제품의 release checklist에 들어갈 가능성이 높습니다.