나쁜 에이전트 네 개를 인증 게이트에 통과시켜 봤습니다. 전부 차단됐습니다

AI 요약

HivePlane을 만든 글쓴이는 에이전트가 생산 환경에 들어가기 전에 스스로를 증명해야 한다는 설계를 네 가지 공격 시나리오로 시험했습니다. 미인증 에이전트의 생산 실행, 인증받은 모델과 다른 모델로 교체한 실행, 겉보기에는 정상이나 행동이 잘못된 에이전트, 실행 예산을 넘기는 에이전트를 각각 만들어 인증 게이트를 통과하려 했습니다. 네 사례 모두 차단됐습니다.

미인증 에이전트는 실행 전에 거부합니다

첫 번째 시도는 에이전트를 등록한 뒤 인증을 건너뛰고 생산 환경에 실행을 제출하는 방식입니다. HivePlane은 HTTP 403을 반환하며, 해당 작업의 이름과 실행 환경, 현재 인증 상태, 필요한 상태를 오류 메시지에 담았습니다. 글쓴이는 처음에는 단순히 “Forbidden”이라고 응답했지만, 운영자가 다음 조치를 알 수 있도록 현재 상태와 필요한 상태를 함께 보여 주는 편이 낫다고 설명합니다.

거부는 실행 기록을 저장하기 전에 이뤄집니다. 따라서 실행 기록이나 부수 효과가 남지 않아 정리할 작업도 없습니다. 글쓴이는 거부가 가장 값싸게 작동하는 지점, 즉 실행을 받아들이는 단계에서 차단하도록 설계했다고 말합니다.

인증받은 모델과 실행 모델이 다르면 차단합니다

두 번째 에이전트는 omlx/qwen3-4b-instruct-2507/4bit 모델로 인증받은 뒤, 생산 환경에서는 openai/gpt-4o/2024-08-06을 사용하도록 제출됐습니다. 게이트는 실행에 사용된 모델의 정체성을 인증 정보에 묶인 모델과 비교해 요청을 거부했습니다. 매니페스트에 적힌 모델이 아니라 실제 인증 과정에서 승인받은 모델과 비교해야 모델 교체를 잡아낼 수 있다는 설명입니다.

글쓴이는 첫 공격 버전이 201 응답을 받고 통과했던 사례도 언급합니다. 당시 게이트가 잘못 판단한 이유는 후속 글에서 다룰 예정이라고 밝혔습니다.

JSON이 멀쩡해도 잘못된 행동은 인증하지 않습니다

세 번째는 글쓴이가 가장 중요한 시나리오로 꼽은 회귀 테스트입니다. regressed-agent는 이슈를 읽지 않고 답하며, 모르는 주제를 상위 담당자에게 넘기지 않고, 계정 등급을 추측하도록 만들었습니다. 인증 테스트 결과는 통과율 0.40, 즉 5개 중 2개였고 생산 기준인 0.90에 미달했습니다. 치명적인 실패도 하나 있었습니다. p95 지연 시간은 11ms였지만, 빠른 응답은 잘못된 행동을 보완하지 못했습니다.

테스트 사례에서 에이전트는 계정 ACC-999의 등급을 basic 대신 pro라고 추측했습니다. 알 수 없는 주제에는 escalated로 넘겨야 했지만 success라고 답했습니다. 또 mcp.github.read_issue 도구를 호출해야 하는 감사 작업에서 이슈를 읽지 않았습니다. 출력은 올바른 JSON 형식이었지만, 결정론적 action_audit 검사가 필수 행동의 누락을 찾아냈습니다. 글쓴이는 출력만 확인하는 벤치마크는 그럴듯한 답변을 실제 수행으로 오인한다고 지적합니다.

비용은 사용량이 쌓이는 순간 차단합니다

네 번째 budget-probe 에이전트는 실행당 예산을 0.000001달러로 설정하고, 관리되는 모델 호출을 한 번 수행했습니다. 사용량 보고액이 한도를 넘자 실행이 중단됐고 기록된 비용은 2.85달러였습니다. 글쓴이는 실행 전에 확인할 수 있는 팀·일일 예산 여력과, 비용이 발생한 뒤에야 판정할 수 있는 실행별 한도를 구분합니다. 실행별 한도는 사용량이 쌓이는 지점에서 막아야 하며, 너무 이른 단계에서 판정하면 모든 실행을 막거나 아무것도 막지 못할 수 있다고 설명합니다.

로컬 모델은 기본 비용표에서 비용이 0달러로 계산돼 예산 초과를 시험할 수 없었습니다. 현장 테스트에서는 HIVEPLANE_BUDGET__PRICES 설정으로 모델 가격을 토큰 100만 개당 150달러와 600달러로 지정하고, 무료 예외를 제거했습니다. 코드 변경 없이 비용 집계를 시험한 방식입니다.

다른 경계 통제와 남은 과제

같은 현장 테스트에서는 파괴적인 pagerduty.acknowledge 호출이 운영자 승인을 요구해 실행을 멈췄습니다. 글쓴이가 UI에서 승인하자 실행이 재개돼 완료됐습니다. 다만 승인 판단은 글쓴이가 운영자 역할을 맡아 시뮬레이션했습니다. 40KB 도구 페이로드는 에이전트에 전달되기 전에 16,384바이트로 잘렸고, 거부와 개입은 변조 탐지 감사 기록에 남았습니다.

글쓴이는 부정적인 테스트 사례도 정상 경로와 같은 수준으로 설계해야 한다고 강조합니다. 각 통제는 피해를 측정할 수 있는 마지막 지점에 둬야 합니다. 생산 실행은 기록 전에, 예산은 사용량 보고 시점에, 도구 입력 크기 제한은 에이전트의 문맥에 들어가기 전에 적용합니다. 다음 배포에는 재인증 사이에 서서히 성능이 떨어지는 현상을 찾는 드리프트 감지기를 추가할 예정이며, 이번 테스트는 변화는 잡아도 점진적인 저하는 아직 다루지 않는다고 밝혔습니다.

dev.to 반응

• @reidmarlow — 잘못된 결과를 내는 그럴듯한 에이전트가 복구하기 훨씬 어렵습니다. 토큰을 태우는 폭주 루프는 강한 예산 상한이나 요청 제한에 걸려 몇 분 안에 멈추므로 피해 범위가 비용으로 제한됩니다. 반면 필수 읽기 도구를 한 번도 호출하지 않고 깔끔하고 유효한 JSON을 내놓는 에이전트는 하위 데이터베이스와 이슈를 조용히 오염시킵니다. 운영자가 정상 종료 코드를 보고 실제 작업이 끝났다고 믿기 전에 잡으려면, 생성된 텍스트를 보기 전에 필수 도구 호출과 행동 경로를 검증해야 합니다.
• @cailab — 좋은 현장 테스트입니다. 결정이 아직 저렴한 지점에 각 게이트를 두는 경계 모델이 핵심입니다. 허용한 뒤 사후 탐지하는 방식보다 시스템 전체를 감사하기 쉽게 만듭니다. 예산 공격은 특히 흥미롭습니다. 실행 전에 확인할 수 있는 것은 예산 여력이고, 실행별 한도는 비용이 발생한 뒤에야 판정할 수 있다고 했습니다. 중간 방법도 있습니다. 에이전트가 시작 전에 지정된 한도까지 지출을 사전 승인받았음을 증명하는 기능 토큰을 지니게 하는 겁니다. 그러면 게이트가 사용량 보고를 기다리지 않고 실행을 승인할 때 토큰을 확인합니다. 경계가 더 앞당겨집니다. 모델 교체 게이트도 인상적입니다. 인증을 정확한 모델 정체성에 묶으면 많은 사람이 알아채지 못하는 빈틈을 막습니다.
• @hannune — 모델 교체 게이트가 와닿습니다. 저도 프로젝트 중간에 임베딩 모델을 바꿨다가 모든 임계값이 맞지 않게 된 적이 있습니다. 무엇이 바뀌었는지 알려 주는 신호도 없었습니다. 분포가 달라졌다는 사실을 깨닫기까지 시간이 걸렸습니다. 결국 보정 작업을 모델 버전에 묶어 모델을 바꾸면 다시 조정하게 했습니다. 인증 정보가 하는 일과 비슷합니다. 그래도 가장 걱정되는 건 회귀 사례입니다. 여기서는 필수 도구 호출을 미리 지정해 action_audit가 작동했지만, 제가 본 대부분의 파이프라인은 그 조건을 미리 정하지 않습니다. 그럴듯하지만 틀린 결과가 조용히 데이터 품질 문제로 이어집니다.
• @presango — 기억에 남은 문장은 거부 메시지가 제품의 일부라는 말입니다. 저희도 반대쪽에서 같은 점을 배웠습니다. 에이전트가 사람 앞에서 말하거나 답할 때 “자료에 없습니다”라고 하는 순간이 신뢰를 쌓거나 무너뜨립니다. 거부 문구는 주변에 나오는 정답보다 더 중요할 때도 있습니다. 공격자 네 개를 시험한 결과, 게이트의 순서도 알게 됐나요? 운영자에게 가장 유용한 메시지를 주려면 어떤 검사가 먼저 실패해야 하나요?
• @rishita_sharma_b0aa1ff81a — 실행 시점의 거부와 인증을 정확한 모델에 묶는 설계가 좋습니다. 거부 메시지를 일반 오류가 아니라 작업 흐름의 일부로 다룬 점도 마음에 듭니다. 제가 접한 시스템에서는 거부 사실을 기록하면서도 운영자가 빠르게 문제를 해결할 만큼 맥락을 제공하지 않는 경우가 많았습니다. 모델 교체, 오래된 인증 정보, 재전송 시도를 시험하는 방식이 행복 경로 벤치마크보다 실제 운영에 가깝습니다. 에이전트의 자율성을 당연하게 가정하지 않고 자격을 갖추게 만드는 실용적인 패턴입니다.

원문: dev.to / 번역·요약: Trawling