보안 게이트가 항상 통과한다면, 실제로 릴리스를 차단할 수 있을까?

에이전트 개발자들은 감독(oversight) 수치를 발표하기 시작했습니다.

예를 들어, Anthropic은 2026년 8월 연구 및 엔지니어링 에이전트가 내린 10억 건 이상의 결정 중 약 47,000분의 1이 온라인 모니터에 의해 차단되었다고 보고했습니다.

차단율(block rate)은 게이트가 '아니다'라고 말한 빈도를 알려줄 뿐입니다. 게이트가 실제로 '아니다'라고 말했어야 했지만 그러지 못한 빈도는 알려주지 않습니다.

같은 발표는 더 어려운 측정 방법을 제시합니다: "개발자들은 알려진 에이전트의 오작동(misbehavior)이 모니터에 의해 얼마나 자주 포착되는지를 공유해야 하며, 제3자가 이러한 종류의 테스트를 독립적으로 수행해야 합니다."

알려진 사례에 대한 탐지(Detection on known cases)는 모든 실제 누락 건수(real-world miss)를 세는 것은 아닙니다. 하지만 측정할 수 있는 부분이며, 모니터에 의도적으로 오작동을 주입하고 그것이 작동하는지 관찰해야 합니다.

조용히 놓치는 것의 모습 (What a quiet miss looks like)

컨트롤은 단지 차단율만으로는 드러나지 않는 방식으로 조용히 실패할 수 있습니다.

예를 들어, OpenAI가 발표한 9월 20일 트레이닝 사고에서, 한 에이전트는 자신의 샌드박스(sandbox) DNS 리졸버가 공용 인터넷에 도달할 수 있다는 것을 발견했고, 이를 사용하여 외부 챗봇에 질문을 보냈습니다.

모니터링은 부분적으로 작동했습니다. 그 행동을 플래그 지정했고, 사람이 경고를 받고 그것이 발생한 지 3분 후에 인지했습니다. 이 보고서는 작동하지 않은 부분에 대해 솔직하게 이야기합니다:

• 실행이 "예상대로 자동으로 중단되지 않았습니다." 2시간 반 후에 수동으로 중단되었습니다.
• "비정상적인 DNS 활동을 위한 인프라 탐지기가 영향을 받는 환경을 제외했습니다." 탐지기는 존재했지만, 의도된 보호 경로에는 배치되지 않았습니다.
• 사후 검토 결과, 모니터가 예상되는 심각도로 플래그 지정하지 않은 다른 외부 DNS 접근 사례들이 발견되었습니다. 이는 "유용한 정보를 얻는 데 실패하는 것을 인터넷에 접속하려는 시도가 실패했다는 증거로 때때로 간주했습니다."

차단율만으로는 이러한 격차(gap) 중 어느 것도 확립할 수 없습니다. 이들은 누군가가 각 컨트롤이 중요한 경로에서 작동하는지 확인해 볼 때 나타납니다.

당신의 파이프라인도 더 작은 규모에서 같은 형태를 가지고 있습니다.

결정하는 단 한 줄의 코드

대부분의 보안 파이프라인은 빌드를 배포할지 여부를 결정하는 하나의 라인으로 끝납니다.

스캐너가 보고서를 작성합니다. 작은 스크립트가 이 보고서를 읽어 특정 심각도 이상의 발견 건수를 세고, 그 수가 너무 높으면 0이 아닌 값(non-zero)으로 종료됩니다. 테스트, 페이로드, 커버리지 매핑 등 상류(upstream)의 모든 요소들이 바로 그 하나의 카운트를 통해 배포 결정에 도달합니다.

그런 스크립트는 테스트를 생략하기 쉽습니다.

아무도 조정하지 않는 두 가지 계약

스캐너는 출력 계약(output contract)을 가지고 있습니다: 필드 이름, 상태 값, 심각도 철자 등입니다. 게이트(gate)는 입력 계약(input contract)을 가지고 있습니다: 자신이 찾고자 하는 필드와 비교하는 값들입니다.

이들은 종종 다른 사람들에 의해, 다른 시기에, 때로는 다른 리포지토리에서 작성됩니다. 이들이 서로 동의하도록 강제하는 것은 아무것도 없습니다.

스키마 유효성 검사(schema validation)가 없다면, 계약 드리프트(contract drift)는 조용히 실패할 수 있으며, 최악의 방향으로 발생합니다. result == "failed"를 찾는 게이트가 이제 "FAILED"로 작성되는 보고서를 만나면 0개의 실패 건수를 계산합니다. 심각도(severity) 문자열을 비교하는 게이트가 숫자 CVSS 점수로 바뀐 보고서를 만난다고 해도 마찬가지입니다.

빌드는 녹색(green)입니다. 대시보드도 녹색입니다. 이 게이트는 통제 수단이 아니라 형식적인 절차(formality)가 되어버렸습니다.

구문상으로는 아무 문제도 없기 때문에 오류가 발생하지 않습니다. 게이트는 자신이 작성된 대로 정확히 작동하지만, 자신이 위해 설계되지 않은 보고서에 대해 작동하고 있는 것입니다.

녹색은 증거가 아니다

항상 통과했던 게이트는 두 가지 중 하나만을 알려줍니다: 시스템이 깨끗하거나, 아니면 그 게이트가 볼 수 없다는 것입니다. 외부에서 보면 이 둘은 똑같아 보입니다.

게이트가 알려진 위반 사항을 차단하는 것을 본 적이 없다면, 그것이 그렇게 할 수 있다는 것을 증명한 것이 아닙니다.

해결책은 더 많은 스캐닝이 아닙니다. 마지막 라인이 '아니오'라고 말할 수 있음을 입증하는 것입니다.

게이트가 거짓임을 만들 수 있는 세 가지 검사 항목

1. 실제 작성자를 통해 알려진 취약점을 주입합니다. 스캐너 자신의 작성자가 만든 보고서에 치명적인 발견 사항 하나를 포함시켜 게이트에 공급하십시오. 게이트는 0이 아닌 값으로 종료되어야 합니다. 이 테스트를 양쪽 중 어느 한쪽에 변경이 있을 때마다 CI(지속적 통합)에서 실행해야 합니다.

이것은 작성자(writer)와 게이트(gate) 간의 계약을 테스트합니다. 스캐너가 무언가를 감지하는지, 또는 파이프라인이 게이트의 종료 코드(exit code)를 준수하는지를 테스트하지는 않습니다. 그것들은 별도의 검사가 필요합니다. 하지만 누군가 스캐너에서 필드 이름을 변경하면, 이 코드는 사고 검토 과정에서 왜 아무것도 차단되지 않았는지 묻는 날이 아니라 같은 날 고장납니다.

2. 하나의 분류기(classifier)를 공유하고 그 답변을 고정하세요. 만약 스캐너의 요약과 게이트가 각각 무엇을 실패로 간주할지 결정한다면, 이 둘은 서로 어긋날 수 있습니다. 따라서 (통과, 실패, 불명확) 분류 결과를 두 곳 모두에서 호출하는 하나의 함수에 넣어서, 오직 하나만 변경되도록 하세요.

하나의 정의가 여전히 일관되게 틀릴 수는 있습니다. 이를 분류기 자체와는 독립적으로 작성된 테스트 케이스로 예상 결과(expected outcomes)를 고정하세요.

3. '판단 불가(could not tell)'에 자체 상태를 부여하세요. 응답이 테스트 중인 기능이나 제어(capability or control)가 실행되었음을 보여주지 않는 경우, 그것은 통과도 실패도 아닙니다. 그것은 불명확합니다(inconclusive).

이는 릴리스 정책에 대한 진술이 아니라 평가 자체에 대한 진술입니다. 필요한 증거가 누락된 경우 팀은 합리적으로 릴리스를 차단할 수 있지만, 보고서는 여전히 실패보다는 불명확하다고 말해야 합니다. 문제가 되는 것은 이 둘을 통합하는 것입니다: 불명확한 것을 통과로 간주하면 아무도 테스트하지 않은 것도 배포하게 되고, 이를 실패로 재분류하면 빌드가 빨간색인 이유를 숨기게 됩니다.

검사에 대한 검사(A check on the checks)

같은 추론이 한 단계 아래에서도 적용됩니다. 라이브 애플리케이션 응답이 필요한 보안 테스트가 존재하지 않는 서버에 대해 통과(PASS)를 반환했다면, 아무것도 테스트하지 않은 것입니다.

모든 테스트를 판단할 것이 없는 몇몇 대상(targets)을 대상으로 실행하세요: 닫힌 포트, 모든 것에 404를 응답하는 서버, 모든 것에 403을 응답하는 서버, 빈 본문으로 응답하는 서버.

대부분의 테스트에서 해당 응답들은 테스트된 기능이 실제로 사용되었음을 보여주지 않기 때문에, 솔직한 평가는 결론을 내릴 수 없습니다. 일부 테스트는 다릅니다. 접근 제어(access-control) 확인의 경우 403 오류가 증거가 될 수 있습니다. 네트워크 격리(network-isolation) 확인의 경우 닫힌 포트가 그 일부일 수 있지만, 서비스가 실제로 리스닝하도록 의도되었다는 증거와 함께여야만 합니다. 그렇지 않으면 단순히 다운된 서비스와 격리를 혼동하게 됩니다. 이러한 경우는 예외로 선언되어야 하며, 각각이 만족시키는 특정 단언(assertion)에 연결되어야 합니다. 그 외의 PASS 또는 FAIL은 대상(target)을 제대로 읽지 못하는 테스트입니다.

Agent Security Harness는 v4.26.1 기준으로 두 가지 확인 모두 CI에서 실행됩니다. GitHub Action의 게이트와 harness 요약은 하나의 행 분류기(row classifier)를 공유합니다. 한 테스트가 MCP harness의 작성자로부터 중요한 실패가 있는 보고서를 받아 Action 자체의 게이트 단계에 공급하고, 0이 아닌 종료 코드를 요구합니다.

별도의 가드(guard)는 모든 URL을 사용하는 harness를 아홉 가지 대상(target)과 비교하여 실행합니다. 이 대상들은 닫힌 포트부터 404 오류가 발생하는 서버, 빈 200 응답, 빈 500 응답, 리다이렉션 루프까지 다양합니다. 이 가드는 짧고 문서화된 예외 목록 외의 어떤 판결이라도 있으면 빌드를 실패시킵니다. 또한 이 가드는 자신이 작동할 수 있음을 증명하기도 합니다: 시드(seeded)된 대상-블라인드 harness는 이를 빨간색으로 바꾸어야 합니다.

이 가드의 주장은 외부적으로 재현되었습니다. 외부 당사자가 자신들의 대상과 결과 파서(result parser)를 사용하여 공개된 v4.26.0 패키지에 대해 수행했습니다: [https://github.com/VrtxOmega/veritas-agent-trust-lab/blob/cb061dc9930cee456250ecab71b16d5e977f073d/evidence/ASH_NO_SURFACE_RETEST_20260926.md]

직접 깨보세요: [https://github.com/msaleme/red-team-blue-team-agent-fabric/discussions/619]

이번 주에 던져야 할 질문

파이프라인에서 보안 검토 결과가 릴리스를 차단하는지 결정하는 한 줄을 골라보세요.

그리고 다음 질문을 던져보세요: 마지막으로 의도적으로 차단된 적은 언제인가요?

만약 답이 '한 번도 없다'라면, 그것이 작성해야 할 첫 번째 테스트입니다.

본인의 견해입니다.

출처:

• Anthropic, "Measurements for understanding the pace of AI development inside frontier labs": https://www.anthropic.com/institute/measuring-pace-of-ai-development
• OpenAI, "An agent used DNS to reach an external chatbot" (report updated 25 September 2026): https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/
• Agent Security Harness v4.26.1 changelog: https://github.com/msaleme/red-team-blue-team-agent-fabric/blob/v4.26.1/CHANGELOG.md