AI 분야에서는 배포 전 고급 모델의 거버넌스 및 평가 메커니즘에 대한 광범위한 논의가 이루어지고 있습니다. 그러나 이러한 거대 담론들은 AI 에이전트가 이메일 전송, 암호화 키 수정, 소프트웨어 브랜치 병합 또는 자금 이체와 같은 민감한 작업을 수행할 수 있는지 여부를 결정하는 실제 프로그래밍 코드를 종종 간과합니다. 이러한 결정은 거대 연구소나 규제 텍스트가 아니라, 참 또는 거짓 값을 반환하는 단순한 프로그래밍 함수에 의해 내려집니다.
에이전트 작업 검증을 위한 오픈 소스 프로토콜인 'PIC'에 대한 스트레스 테스트 결과, 문제는 반드시 암호화 실패에서 발생하는 것이 아니라 프로토콜이 겉으로는 올바르지만 해석의 여지가 있는 다양한 형식을 수용하는 데서 발생한다는 점이 드러났습니다. 예를 들어, 구조적 스키마는 해시 코드를 대문자나 소문자로 모두 허용할 수 있지만, 인터프리터는 명시된 표준 사양을 위반하지 않으면서도 시스템마다 서로 다른 결과를 도출하는 방식으로 이를 처리할 수 있습니다.
데이터 검증에서 JSON 스키마의 한계
JSON 스키마는 데이터 구조를 검증하는 데 필수적이지만 제한적인 역할을 합니다. 즉, 필수 필드의 존재 여부, 값 유형의 정확성, 일반 규칙 준수 여부를 확인합니다. 그러나 스키마는 특정 증거 참조가 중복이나 혼동 없이 소스 배열 내의 단일 요소를 가리키도록 보장하는 것과 같은 복잡한 관계형 규칙을 강제할 수 없습니다.
서로 다른 프로그래밍 언어 간의 검색 작업이나 식별자 매칭 구현의 차이는 '파서 불일치(parser differential)'로 알려진 현상을 초래합니다. 이는 과거 HTTP 및 JWT와 같은 프로토콜에서 나타났던 오래된 보안 취약점 유형으로, 두 구성 요소가 동일한 입력을 서로 다르게 읽는 상황입니다. 현대의 에이전트 프로토콜에서 이러한 미묘한 차이는 동일한 정책과 사양을 사용하는 서비스임에도 불구하고 특정 서비스에서는 작업을 수용하고 다른 서비스에서는 거부하는 결과를 낳습니다.
정규화 작업이 프로토콜 보안에 미치는 영향
개발자들은 일반적으로 불필요한 공백 제거, 소문자 변환, Base64 패딩 수정 등 복구 가능한 데이터를 거부하지 않기 위해 입력을 정규화하는 경향이 있습니다. 그러나 이러한 관행은 인증 경계에서 심각한 위험을 초래합니다. 예를 들어, 인터프리터가 허용 목록과 대조하기 전에 도구 이름을 정규화하거나 공백을 제거하면, 시스템은 서명 당사자가 승인하지 않은 작업을 실행하거나 개발자 모르게 실행 권한을 조작할 수 있습니다.
또한, 에이전트가 자신의 신뢰성을 입증하기 위해 스스로 보내는 필드에 의존하는 것은 디지털 형태의 '혼란스러운 대리인(confused deputy)' 문제를 야기합니다. 신뢰는 요청 페이로드에 포함된 주장과 관계없이, 디지털 서명을 확인하고 운영자가 직접 신뢰하는 암호화 키와 대조하는 법 집행 및 검증 경계 내에서만 도출되어야 합니다.
3계층 구조 및 실행 매칭 벡터
이러한 취약점을 방지하려면 다음 세 가지 계층을 명확하게 구분하는 구조가 필요합니다:
- 스키마 검증: 손상된 구조 및 네트워크에 부합하지 않는 표현을 거부합니다.
- 의미론적 검증: 참조를 해결하고, 관계를 확인하며, 실제 신뢰를 도출합니다.
- 정책 평가: 작업 실행 허용 또는 차단에 대한 최종 결정을 내립니다.
문서화된 주석만으로는 충분하지 않습니다. 모호한 상황을 처리하기 위해 정확한 입력, 예상 결과, 안정적인 오류 코드를 포함하는 명확한 실행 적합성 테스트 도구가 필요합니다. 이러한 벡터는 모든 구현체 전반에서 일관된 동작을 보장하며, 다양한 소프트웨어 브리지의 서로 다른 기본 구성에 보안을 의존하는 것을 방지합니다.