Microsoft run-assert-eval, 에이전트 위험 발견을 검증된 런타임 제어로 전환

Microsoft는 9월 24일 run-assert-eval을 공개하며, 그동안 분리돼 있던 네 가지 에이전트 안전성 작업을 하나의 안내형 워크플로로 연결했다. Microsoft run-assert-eval 스킬은 위험을 발견하고, 실패를 측정하며, 런타임 제어를 초안으로 작성한 뒤, 해당 제어를 추가한 후 동일한 평가를 반복한다. 긴장은 즉각적이다. 더 빠른 안전성 루프는 그 측정 결과가 신뢰할 수 있을 때에만 유용하다.

Microsoft의 사례는 이 발표에 구체성을 더한다. 회사에 따르면 청구 지원 에이전트는 적용 가능한 기준 대화 40건 중 12건에서 다른 고객의 데이터를 공개했다. 런타임 정책을 도입한 뒤 Microsoft는 적용 가능한 대화 34건에서 위반 2건을 관찰했다. 이에 따라 보고된 비율은 30.0%에서 5.9%로 낮아졌다.

결과는 단정적으로 들리지만, 이는 프로젝트 개발자가 관리한 실행 사례에서 나온 것이다. Microsoft는 독립적인 재현 연구나 프로덕션 배포 연구를 제시하지 않았다. 따라서 중요한 진전은 하나의 긍정적 점수가 아니라 그 메커니즘이다. 이 스킬은 발견된 실패를 집행 가능한 정책으로 전환한 뒤, 평가를 조용히 변경하지 않고 개입 효과를 테스트한다.

Microsoft run-assert-eval은 발견, 테스트, 집행을 연결한다

이번 공개는 안전성 프로젝트 모음을, 알려지지 않은 위험에서 검증된 런타임 제어에 이르는 하나의 검토 가능한 경로로 전환한다.

Microsoft의 출시 게시물은 호환되는 코딩 환경에서 프롬프트로 시작되는 워크플로를 설명한다. 개발자는 에이전트, 의도된 목적, 도구, 그리고 준수해야 할 경계를 정의하며 시작한다.

이 스킬은 Clarity를 사용해 에이전트의 위협 모델을 만들 수 있다. 위협 모델링은 테스트를 선택하기 전에 발생 가능한 실패, 영향을 받는 자산, 원인 및 결과를 식별하는 작업을 의미한다. 팀은 제품 요구사항, 사고 보고서, 테스트 계획 또는 기존 평가에서 이미 알려진 위험을 제공할 수도 있다.

이 구분은 중요하다. 위험 발견은 권장되지만 필수는 아니다. 청구 에이전트가 고객 기록을 노출한다는 사실을 이미 알고 있는 팀은 발견 작업을 반복하는 대신 해당 행동부터 시작할 수 있다.

발견이 필요한 경우 Clarity 위협 모델러는 에이전트의 더 넓은 운영 맥락을 검토한다. 이는 원래 요구사항에 전혀 명시되지 않았던 실패를 찾아내기 위한 것이다.

Microsoft의 청구 사례에서 Clarity는 네 가지 후보 실패 모드를 식별했다. 팀은 위험도가 심각으로 평가된 두 가지 위험, 즉 검증되지 않은 고위험 작업과 고객 간 데이터 노출을 선택했다.

첫 번째 위험은 발신자의 신원을 확인하지 않은 상태에서 청구 변경을 수행하는 경우를 다뤘다. 두 번째는 발신자 소유가 아닌 계정과 관련된 정보 공개를 다뤘다.

이 스킬은 선택된 각 위험을 Microsoft의 요구사항 기반 평가 프레임워크인 ASSERT로 전달했다. 각 위험은 하나의 구성, 하나의 행동, 하나의 평가 스위트가 됐다.

이 좁은 구조는 처음 보이는 것보다 더 큰 의미를 지닌다. 평가가 권한 부여, 개인정보 보호, 정확성, 에스컬레이션 실패를 함께 섞는다면, 종합 점수만으로는 어떤 제어가 필요한지 설명할 수 없다.

대신 Microsoft run-assert-eval은 이러한 행동을 분리한다. 각 스위트 내에서는 액세스 방식, 사용자 구실, 권한 주장, 다중 턴 범위 이탈과 같은 차원을 통해 변이를 도입한다.

이 스킬은 관련 테스트 차원을 찾기 위해 기존 연구와 안전성 프레임워크도 검색한다. Microsoft는 이러한 출처에 NIST 지침, OWASP 자료, 벤치마크, 규제 자료, 모델 제공업체 정책이 포함될 수 있다고 밝혔다.

그런 다음 ASSERT는 사례를 생성하고, 대상 에이전트를 실행하며, 캡처된 대화 기록을 평가한다. 핵심 측정값 두 가지는 의도적으로 분리돼 있다.

“Impermissible behavior violated”는 에이전트가 금지된 행동을 수행한 사례를 기록한다. “Permissible behavior violated”는 허용됐음에도 에이전트가 지원하지 못한 사례를 측정한다.

이 분리는 익숙한 안전성 착시를 막는다. 모든 요청을 거부하는 에이전트는 많은 유해 행동을 피할 수 있지만, 동시에 자신의 업무도 수행하지 못하게 된다.

워크플로는 이어서 측정된 실패를 바탕으로 Agent Control Specification 정책 초안을 생성한다. ACS는 에이전트 실행의 정의된 지점에 제어를 배치하기 위한 이식 가능한 형식이다.

마지막으로 이 스킬은 동일한 사례를 사용해 거버넌스가 적용된 버전의 에이전트를 평가한다. 기준 실행과 거버넌스 적용 실행은 동일한 행동 정의, 테스트 세트, 판정 방식을 유지한다.

그 결과는 단순히 또 하나의 안전성 점수가 아니다. 정책을 변경 변수로 분리하도록 설계된 통제 비교다.

주요 가드레일로 프롬프트를 사용하는 팀에 압박이 가해진다

Microsoft는 서면 지시만으로 도구를 사용하는 에이전트에 적절한 제어 경계를 제공할 수 있다는 생각에 이의를 제기하고 있다.

시스템 프롬프트는 역할과 기대 행동을 정의하는 데 여전히 유용하다. 그러나 이는 모델이 해석하는 확률적 지시이며, 주변 소프트웨어가 집행하는 결정론적 권한 확인이 아니다.

에이전트가 기록을 조회하고, 계정을 업데이트하며, 환불을 처리하거나 관리 도구를 호출할 수 있을 때 이 약점은 실질적인 문제가 된다. 설득력 있는 요청이 데이터베이스 조회나 비즈니스 작업으로 이어질 수 있기 때문이다.

Microsoft의 청구 사례는 이 간극을 보여준다. 에이전트는 ACME-1001 계정과 연결된 발신자를 위해 작동했다. 다른 고객의 계정을 조회하거나 수정해서는 안 됐다.

평가된 한 요청은 다른 고객 소유인 BPS-447와 연결된 연락처 정보를 요구했다. Microsoft에 따르면 기준 에이전트는 전체 기록을 반환했다.

코드 리뷰는 조회 함수가 올바르게 작동한다는 점을 확인할 수 있다. 단위 테스트는 유효한 계정 식별자가 예상 레코드를 반환하는지 확인할 수 있다. 그러나 어느 쪽도 현실적인 대화 중 모델이 권한 없는 식별자를 선택하는지 반드시 테스트하지는 않는다.

이 문제는 청구 지원을 넘어선다. 리서치 에이전트는 부적절한 출처에 접근할 수 있고, 변경 관리 에이전트는 승인 절차를 우회할 수 있다. 여행 에이전트는 저장된 신원 또는 결제 정보를 오용할 수 있다.

OWASP 지침은 이러한 더 넓은 상태를 과도한 에이전시라고 부른다. 이는 AI 애플리케이션이 작업에 필요한 수준보다 더 많은 기능, 권한 또는 자율성을 가질 때 발생한다.

프롬프트 인젝션은 이런 실패를 촉발할 수 있지만 유일한 원인은 아니다. 모호한 요청, 환각된 계획, 손상된 도구, 단순한 모델 오류도 안전하지 않은 행동을 초래할 수 있다.

영향을 받는 팀은 보안 그룹에만 국한되지 않는다. 제품 관리자는 허용 및 금지되는 결과를 정의해야 한다. 개발자는 적절한 제어 지점을 노출해야 한다. 위험 책임자는 측정된 감소가 충분한지 판단해야 한다.

평가 팀 역시 압박을 받는다. 이들의 결과물은 더 이상 실패 목록을 담은 보고서에 그칠 수 없다. Microsoft 워크플로는 발견 사항이 구체적인 제어와 반복 가능한 검증 실행을 뒷받침할 것을 요구한다.

일반적인 모델 벤치마크를 사용하는 조직은 또 다른 문제에 직면한다. 광범위한 벤치마크는 모델의 평균적 경향을 설명할 수 있지만, 각 기업의 계정 규칙, 에스컬레이션 경계 또는 내부 승인 절차를 모두 포착할 수는 없다.

Microsoft의 접근 방식은 애플리케이션 자체의 요구사항과 발견된 위험에서 시작한다. 이는 평가의 관련성을 높이지만, 동시에 조직 간 비교를 더 어렵게 만든다.

이번 공개는 관찰을 최종 단계로 취급하는 공급업체에도 압박을 가한다. 위험한 도구 호출을 실행 후 기록하면 조사에는 도움이 될 수 있다. 하지만 피해를 초래한 행동을 막지는 못한다.

Run-assert-eval은 개입을 에이전트의 런타임 경로로 옮긴다. 이는 권한 확인, 최소 권한, 정책 집행 지점과 같은 익숙한 보안 개념에 더 가깝게 만든다.

이는 프롬프트를 없애지 않는다. 대신 더 좁은 역할을 부여한다. 모델은 계획을 세우고 언어를 해석할 수 있으며, 결정론적 제어는 민감한 작업을 진행해야 하는지 결정한다.

에이전트가 로컬 파일과 내부 지식에 접근하게 되면서 이 구분은 점점 더 중요해진다. 검색 가능한 지식 베이스를 구축하는 팀도 같은 경계 문제에 직면한다. 검색은 사용자의 실제 권한 범위를 존중해야 한다.

Microsoft run-assert-eval은 개발자가 더 이른 단계에서 실행할 수 있는 워크플로로 이 문제를 패키징한다. 그 부담은 모델이 규칙을 따르기를 기대하는 데서, 소프트웨어가 어디에서 이를 집행하는지 보여주는 데로 옮겨간다.

핵심 메커니즘은 통제된 전후 비교 테스트다

run-assert-eval에서 가장 강력한 개념은 자동화된 정책 생성이 아니라, 제어만 변경하면서 평가를 보존하는 데 있다.

팀이 수정을 적용한 후 테스트 세트를 다시 생성하면 안전성 비교는 신뢰할 수 없게 된다. 서로 다른 프롬프트 그룹은 약한 정책을 성공한 것처럼 보이게 하거나, 건전한 정책을 실제보다 나쁘게 보이게 할 수 있다.

판정자를 바꾸는 것 역시 또 다른 교란 변수를 만든다. 특히 허용 가능한 행동이 맥락에 따라 달라질 때, 두 평가자는 같은 대화 기록을 다르게 해석할 수 있다.

Run-assert-eval은 기준 시스템화와 테스트 사례를 캐시한다. 이후 거버넌스 적용 에이전트는 동일한 행동 정의, 사례, 판정 접근법을 마주한다.

Microsoft는 이를 평가를 동결하는 것으로 설명한다. 정책은 의도된 독립 변수가 되고, 측정된 위반율은 관찰 결과가 된다.

이 원칙은 기존 소프트웨어의 회귀 테스트와 닮았다. 개발자가 구현을 수정하는 동안 실패한 테스트는 고정돼 있어야 한다. 그렇지 않으면 통과 결과는 수정된 행동이 아니라 다시 작성된 테스트를 반영할 수 있다.

모델 출력이 가변적이기 때문에 에이전트 테스트는 더 어렵다. 판정자 역시 모델 기반일 수 있으며, 생성된 사례에는 자체적인 모호성이 포함될 수 있다.

이러한 요소를 일정하게 유지한다고 해서 모든 불확실성이 사라지는 것은 아니다. 하지만 전후 차이를 더 해석 가능하게 만든다.

Microsoft는 이전 ASSERT 평가에서 자동화된 판정자와 인간 검토자 사이에 80%~90%의 일치율을 확인했다고 밝혔다. 이는 인간 검토자 간 약 90%의 일치율과 비교된다.

이 수치는 Microsoft가 보고한 결과이며, 보편적인 정확도 보장은 아니다. 판정 일치율은 행동, 모델, 루브릭, 언어, 기저 정책의 복잡성에 따라 달라질 수 있다.

기저 평가는 여전히 검토 가능하다. ASSERT 저장소는 실행 결과가 로컬 아티팩트, 생성된 사례, 모델 출력, 판정 근거, 지표를 저장한다고 설명한다.

로컬 아티팩트는 검토자가 대화 기록이 왜 위반으로 분류됐는지 살펴볼 수 있으므로 감사를 지원할 수 있다. 또한 평가자가 정책을 오해한 사례도 식별할 수 있다.

ASSERT의 이중 비율 설계는 또 다른 보호 장치를 더한다. 유해 행동을 차단하는 정책도 과도한 거부를 유발한다면 실패할 수 있다.

고객 간 스위트에서 Microsoft는 기준선의 허용 불가 위반율이 30.0%였다고 보고했다. 거버넌스 적용 결과는 다른 적용 가능 분모에서 5.9%였다.

Microsoft는 결과를 프롬프트와 시나리오 분할로도 나눴다. 프롬프트 사례는 더 직접적인 상호작용을 테스트하며, 시나리오 사례는 더 풍부한 워크플로와 대화 맥락을 포착한다.

고객 간 프롬프트 사례에서 보고된 허용 불가 비율은 20.8%에서 8.7%로 하락했다. 해당 시나리오 비율은 43.8%에서 0.0%로 하락했다.

검증되지 않은 행동 유도 프롬프트 사례에서 보고된 비율은 4.0%에서 0.0%로 떨어졌다. 시나리오별 분류에서는 8.7%에서 4.5%로 낮아졌다.

허용 가능한 행동 위반은 4개의 모든 거버넌스 적용 분할에서 0.0%에 도달한 것으로 보고됐다. Microsoft는 이를 통제가 이 표본에서 정당한 업무를 보존했다는 증거로 해석한다.

남아 있는 비허용 위반도 중요하다. 이는 통제된 예시 안에서도 정책이 모든 실패를 제거하지는 못했다는 점을 보여준다.

이는 워크플로의 반복적 설계와 일치한다. 팀은 남아 있는 실패를 검토하고, 위험 정의나 정책을 개선한 뒤 같은 과정을 반복할 수 있다.

따라서 이 방법은 소수의 수동 데모보다 더 강력한 증거를 제공한다. 하지만 모든 미래 프롬프트, 모델 업데이트, 도구 또는 환경에서 에이전트가 어떻게 행동할지를 입증하지는 않는다.

실질적인 이점은 더 좁지만 더 유용하다. 팀은 에이전트를 단순히 침묵시키지 않으면서 특정 통제가 정의된 평가에서 성능을 바꿨다는 추적 가능한 증거를 받는다.

런타임 정책은 모델이 완료하기 전에 행동을 차단한다

청구 수정은 모델에 의도를 재고하도록 요청하는 대신, 도구 경계에서 계정 범위를 확인해 작동한다.

고객 간 노출을 측정한 뒤, run-assert-eval은 정책 초안과 ACS 매니페스트를 생성했다. 정책은 의사결정 로직을 표현했고, 매니페스트는 해당 로직이 적용될 위치를 지정했다.

Microsoft는 정책 엔진과 흔히 연관되는 선언형 정책 언어인 Rego를 사용했다. 생성된 자료는 사람의 검토가 필요한 초안으로 남았다.

이 검토 게이트는 중요하다. Microsoft는 생성이 승인을 의미하지는 않는다고 명시한다. 개발자는 정책, 개입 지점, 매니페스트 및 대상 에이전트와의 연결을 점검해야 한다.

선택된 정책은 요청된 계정 식별자가 호출자의 계정과 다를 때 도구 호출을 거부했다. 이 규칙은 요청이 의심스러워 보이는지 판단하기 위해 다른 모델을 필요로 하지 않았다.

Microsoft는 에이전트가 도구를 실행하기 전에 도달하는 가로채기 지점인 pre_tool_call에 검사를 배치했다. 따라서 식별자가 일치하지 않으면 검색이 발생하기 전에 거부된다.

팀은 post_tool_call도 사용했다. 이 두 번째 검사는 모델의 컨텍스트에 절대 들어가서는 안 되는 불일치 결과를 보류했다.

두 지점을 함께 사용하면 심층 방어가 구축된다. 첫 번째는 무단 작업을 방지하려 한다. 두 번째는 앞선 통제가 우회되거나 잘못 연결된 경우 노출을 제한한다.

ACS policy engine은 이러한 통제를 하나의 에이전트 프레임워크와 분리하도록 설계됐다. 따라서 팀이 모델이나 오케스트레이션 라이브러리를 바꿔도 정책은 이식성을 유지할 수 있다.

이러한 이식성은 실제 유지보수 문제를 해결한다. 프롬프트나 프레임워크별 콜백에 내장된 통제는 여러 에이전트 구현 전반에서 감사하기 어려워질 수 있다.

공유 사양은 보안 검토자가 일관되게 검사할 수 있는 대상을 제공할 수 있다. 또한 개발자가 애플리케이션 코드와 함께 정책 변경 사항을 버전 관리할 수 있게 한다.

하지만 이식성이 올바른 통합을 보장하지는 않는다. 모든 런타임은 관련 컨텍스트를 노출하고, 신원을 보존하며, 올바른 지점에서 정책을 호출해야 한다.

계정 범위 규칙은 신뢰할 수 있는 계정 정보에 의존한다. 호출자 신원이 잘못되었거나 누락됐다면, 완벽하게 작성된 비교도 잘못된 권한 부여 결과를 낳는다.

같은 우려는 도구 인수에도 적용된다. account_id를 검사하는 정책은 요청된 리소스가 해당 필드로 정확히 표현된다고 가정한다.

복잡한 도구는 쿼리, 문서, URLs 또는 중첩된 작업 내부에 민감한 대상을 숨길 수 있다. 그러면 좁은 규칙은 동일한 보호 리소스로 향하는 동등한 경로를 놓칠 수 있다.

런타임 정책도 모든 실패 유형을 해결할 수는 없다. 통제는 무단 환불이나 데이터베이스 읽기를 차단할 수 있다. 하지만 생성된 모든 설명이 정확하거나 공정한지를 자동으로 판단할 수는 없다.

일부 고영향 작업에는 사람의 승인이 계속 적절하다. 모델이 잘못된 결정을 내리더라도 최소 권한 도구 설계는 피해를 줄일 수 있다.

더 넓은 AI risk framework는 위험 관리를 수명주기 활동으로 다룬다. 여기에는 단일 출시 전 테스트가 아니라 거버넌스, 매핑, 측정 및 지속적인 관리가 포함된다.

Run-assert-eval은 이 더 큰 패턴 안에 들어맞는다. 위험을 매핑하는 일과 하나의 행동을 측정하고 관리하는 일 사이에 구체적인 연결 고리를 제공한다.

워크플로의 단일 프롬프트 진입점이 그 아래의 작업을 가려서는 안 된다. 위협 모델링, 테스트 설계, 정책 검토, 시스템 통합 및 결과 해석에는 여전히 정보에 기반한 의사결정이 필요하다.

Microsoft가 줄인 것은 그러한 의사결정 사이의 수동 인계다. 이 스킬은 구조화된 산출물을 한 단계에서 다음 단계로 전달하고, 그 관계를 계속 보이게 한다.

이는 위험 설명이 제품, 평가 및 보안 팀 사이에서 전달될 때 의미를 잃을 가능성을 낮출 수 있다.

또한 실패를 발견한 시점과 완화 조치를 확인하는 시점 사이의 간격을 줄일 수 있다. 이 간격은 해결되지 않은 에이전트 위험이 흔히 축적되는 곳이다.

초기 결과는 증거이지 일반적인 안전 보장은 아니다

Microsoft의 예시는 워크플로의 논리를 뒷받침하지만, 에이전트·조직·공격 전반의 프로덕션 효과를 입증하지는 않는다.

가장 분명한 한계는 출처다. Microsoft와 프로젝트 기여자는 도구를 설계하고, 예시를 선택하고, 통제를 적용하고, 그에 따른 측정 결과를 보고했다.

그렇다고 결과가 무효가 되는 것은 아니다. 다만 독자는 투명하게 공개된 작업 예시와 독립 벤치마크 또는 현장 연구를 구분해야 한다는 의미다.

표본 규모도 주의가 필요하다. 헤드라인 기준선에는 적용 가능한 대화 40건이 포함됐고, 거버넌스 적용 실행에는 34건이 포함됐다.

특정 행동 비율에는 적용 가능한 사례만 기여하므로 이 분모는 다르다. 그럼에도 작은 표본은 불안정한 비율을 만들 수 있다.

위반이 12건에서 2건으로 바뀐 것은 이 예시에서 운영상 의미가 있다. 이를 다른 에이전트에도 적용되는 보편적 80% 감소로 해석해서는 안 된다.

보고된 0.0%의 허용 행동 위반율은 해당 표본에서 위반이 나타나지 않았다는 뜻이기도 하다. 정책이 정당한 행동을 절대 차단할 수 없다는 의미는 아니다.

더 큰 테스트 세트에서는 드문 오탐 거부가 드러날 수 있다. 프로덕션 트래픽에는 예시에 빠진 계정 관계, 위임 규칙 또는 지원 예외가 포함될 수 있다.

평가 누수도 또 다른 우려다. 정책을 하나의 고정된 테스트 세트에 맞춰 반복적으로 조정하면, 개발자는 결국 알려진 사례에 과적합할 수 있다.

테스트를 고정하면 하나의 개입 기간 동안 신뢰할 만한 비교가 가능하다. 장기 프로그램에는 별도로 보류한 사례, 새로운 적대적 변형 및 변화하는 행동에 대한 모니터링이 여전히 필요하다.

모델 변경도 이전 결론을 무효화할 수 있다. 새 모델은 도구 인수를 다르게 형식화하거나, 거부를 다르게 해석하거나, 보호된 정보로 향하는 다른 경로를 찾을 수 있다.

도구 변경도 유사한 위험을 만든다. 내보내기 기능이나 일반 검색 엔드포인트를 추가하면 원래 계정 검사에서 다루지 않은 접근 경로가 생길 수 있다.

평가 판정기도 지속적인 검토가 필요하다. Microsoft가 보고한 일치율 범위는 고무적이지만, 불일치 사례는 가장 모호하고 중대한 경계에 집중될 수 있다.

팀은 이견이 있는 사례에 대해 사람의 검토를 유지하고, 겉보기에 성공한 결과도 주기적으로 표본 조사해야 한다. 안정적인 자동 판정기는 비교에 유용하지만 오류가 없는 권위자는 아니다.

“스킬”이라는 단어에는 공급망 문제도 내재해 있다. 에이전트 스킬에는 계획, 실행 및 검증에 영향을 미치는 지침이 포함된다.

Microsoft Research는 최근 두 가지 벤치마크 환경에서 스킬로 유발된 실패 307건을 보고했다. 여기에는 기능 실패 125건과 효율성 저하 182건이 포함됐다.

이 연구는 run-assert-eval을 구체적으로 평가하지는 않는다. 그러나 어떤 스킬이든 지침, 스크립트, 권한 및 운영 가정을 점검해야 하는 더 폭넓은 이유를 제시한다.

Run-assert-eval은 가시적인 산출물과 사람의 게이트를 통해 이 우려를 부분적으로 해결한다. 팀은 거버넌스 적용 실행을 수행하기 전에 생성된 평가 구성과 정책을 검토할 수 있다.

문헌 기반 테스트 생성은 또 다른 검증 의무를 만든다. 인용된 프레임워크는 차원을 안내할 수 있지만, 관련성은 스킬이 그 출처를 사례로 얼마나 정확히 번역하는지에 달려 있다.

번역이 부실하면 의미 있는 범위 없이도 인상적인 커버리지 레이블이 생길 수 있다. 따라서 검토자는 첨부된 프레임워크 이름뿐 아니라 시나리오도 점검해야 한다.

운영 비용도 또 다른 미해결 문제다. 생성된 사례 실행, 추적 기록 캡처, 대화록 판정 및 평가 반복에는 모델 호출과 엔지니어링 시간이 소요된다.

프로젝트는 이 비용을 수동 평가 워크플로와 폭넓게 비교한 결과를 발표하지 않았다. 조직은 어떤 위험이 더 심층적인 평가를 정당화하는지 결정해야 한다.

가장 합리적인 해석은 신중하지만 긍정적이다. Microsoft는 어려운 통합 문제를 위해 일관된 프로세스를 구성했다.

이번 출시는 에이전트의 안전성을 입증하지 않는다. 대신 팀이 구체적인 안전 주장를 세우고, 그에 증거를 연결하며, 하나의 개입이 정의된 결과를 개선했는지 테스트하도록 돕는다.

접근 방식의 지속성을 보여 줄 세 가지 신호

다음 시험대는 독립 팀이 유용한 에이전트 행동을 희생하거나 숨은 유지보수 부담을 만들지 않고 이 워크플로의 성과를 재현하는지 여부다.

첫 번째 신호는 제3자 재현이다. 개발자는 묶음 예시 외부의 에이전트에 Microsoft run-assert-eval을 적용하는 공개 평가를 주시해야 한다.

설득력 있는 재현은 위험 정의, 사례, 정책, 추적 기록, 판정기 구성 및 사람 검토 결과를 공개할 것이다. 또한 거버넌스 이후에도 남은 실패를 공개할 것이다.

서로 다른 모델과 프레임워크에서 나온 결과는 Microsoft의 이식성 주장을 강화할 것이다. 중대한 통합 차이는 ACS가 여전히 개별 런타임에 의존하는 지점을 드러낼 것이다.

두 번째 신호는 더 폭넓은 프로덕션 증거다. 팀은 고정된 평가가 실제 트래픽에서 사고, 거부 및 정책 우회를 예측하는지 알아야 한다.

유용한 증거에는 배포 후 위반 추이와 통제에 의해 차단된 정당한 요청이 포함될 것이다. 또한 모델, 도구 또는 프롬프트 변경 후 도입된 실패도 추적해야 한다.

가장 강력한 배포는 평가 산출물을 지속적인 모니터링에 연결할 것이다. 프로덕션 텔레메트리가 같은 행동 경계를 확인할 때 출시 전 개선은 더 큰 의미를 갖는다.

세 번째 신호는 프로젝트가 회피와 정책 드리프트에 대응하는 방식이다. 공격자와 일반 사용자는 원래 스위트에 없는 경로를 통해 보호된 작업에 도달할 수 있다.

간접 프롬프트 인젝션, 위임 권한, 충돌하는 신원, 상태 조작 및 다중 에이전트 인계를 다루는 새 스위트를 주시해야 한다. 또한 프로젝트가 고정된 사례에 대한 과적합을 어떻게 방지하는지도 살펴봐야 한다.

버전 관리되는 정책과 회귀 실행은 필수적이다. 모델, 도구, 권한 또는 비즈니스 규칙이 바뀔 때마다 평가를 반복할 명확한 트리거가 팀에 필요하다.

이번 출시는 검토 경험으로도 평가돼야 한다. 생성된 정책은 개발자와 보안 팀이 왜 존재하는지, 무엇을 차단하는지 이해할 수 있을 때에만 유용하다.

따라서 로컬 산출물, 인용된 대화록 및 좁게 정의된 행동은 구현 세부 사항 이상의 의미를 갖는다. 이들은 승인을 뒷받침하는 증거 사슬을 이룬다.

그러므로 Microsoft run-assert-eval은 스킬로 패키징된 엔지니어링 규율로 보는 것이 가장 적절하다. 위협 모델링, 행동별 평가, 런타임 집행 및 통제된 재테스트를 연결한다.

개발자는 이 워크플로가 전체 에이전트의 안전성을 인증하는지 물어서는 안 됩니다. 대신 하나의 중요한 위험을 측정 가능하게 만들고, 하나의 통제를 검토 가능하게 하며, 하나의 개선을 재현 가능하게 하는지를 물어야 합니다.

이는 일반적인 안전성을 입증하겠다는 것보다 더 작은 약속입니다. 동시에 에이전트 거버넌스가 시작하기에 더 신뢰할 수 있는 지점이기도 합니다.