Mend의 5계층 보안 가이드, 프롬프트 가드레일을 넘어선 프로덕션 AI 위험 겨냥

Mend.io는 Google News에 소개된 5계층 보안 접근법을 공개했지만, 그 핵심 메시지는 많은 팀이 프로덕션 AI를 보호하는 방식에 의문을 제기한다. 자격 증명을 보유하고, 도구를 호출하며, 메모리를 유지하고, 외부 시스템을 변경하는 에이전트는 프롬프트 가드레일만으로 안전하게 보호할 수 없다.

MarkTechPost가 8월 3일 보도한 이 가이드는 공격 표면을 상호작용, 에이전트, 통합, 모델, 코드 계층으로 구분한다. 실질적 가치는 AI 애플리케이션을 특이한 입력 위험을 지닌 챗봇이 아니라 실행 가능한 시스템으로 다룬다는 데 있다.

이 구분이 실제 충돌을 낳는다. 개발자는 에이전트가 더 적은 중단으로 더 많은 작업을 완료하기를 원한다. 보안 팀은 에이전트가 악의적 문서, 오염된 도구, 과도한 권한 또는 예기치 못한 실행 경로를 마주할 때 결정론적 한계를 필요로 한다.

Model Context Protocol의 약자인 MCP는 AI 애플리케이션이 외부 도구를 발견하고 호출할 수 있도록 표준 인터페이스를 제공한다. 이는 모델을 데이터베이스, 파일 시스템, API, 비즈니스 애플리케이션, 개발 환경에 연결할 수 있다.

이 프로토콜은 상호운용성을 개선하지만, 그 편의성은 각 워크플로 내 신뢰 경계의 수를 늘린다. 이제 에이전트는 신뢰할 수 없는 텍스트를 몇 초 안에 중대한 작업으로 전환할 수 있다.

더 이상 문제는 모델이 부적절한 답변을 생성하는지 여부가 아니다. 조작된 모델이 승인된 도구를 승인되지 않은 목적으로 사용할 수 있는지가 핵심이다.

Google News, 프로덕션 AI 보안에 주목

중요한 사건은 모델 행동을 논의하는 데서 벗어나 입력과 실행 사이의 전체 경로를 보호하는 방향으로의 전환이다.

Google News를 통해 조명된 프로덕션 보안 가이드는 에이전트 보안을 5계층의 엔지니어링 문제로 제시한다. 상호작용 계층은 프롬프트, 검색된 문서, 사용자 파일 및 애플리케이션에 유입되는 기타 정보를 다룬다.

에이전트 계층에는 계획, 메모리, 도구 선택, 위임된 작업이 포함된다. 통합 계층은 MCP 서버, API, 데이터베이스, 플러그인 및 에이전트의 결정을 외부 시스템으로 전달하는 기타 연결을 포괄한다.

모델 계층에는 언어 모델, 해당 구성 및 행동상 한계가 포함된다. 코드 계층에는 애플리케이션 로직, 종속성, 인프라, 자격 증명 및 배포 파이프라인이 포함된다.

이러한 프레이밍이 중요한 이유는 실패가 여러 계층을 가로지르는 경우가 많기 때문이다. 악의적 지시문은 문서를 통해 유입되어 모델의 추론에 영향을 미치고, 허용된 MCP 도구를 실행하며, 일반적인 API 요청을 통해 데이터를 노출할 수 있다.

각 구성 요소는 설계된 대로 작동하는 것처럼 보일 수 있다. 보안 실패는 이들이 결합되는 과정에서 발생한다.

전통적인 애플리케이션 보안은 이 스택 안에서도 여전히 중요하다. 팀은 종속성을 패치하고, 비밀 정보를 보호하며, 입력을 검증하고, 워크로드를 격리하고, 코드를 검토해야 한다. 그러나 이러한 통제만으로는 에이전트가 잘못된 시점에 유효한 도구를 선택한 이유를 완전히 설명할 수 없다.

모델은 동일한 기본 매체를 통해 표현된 지시와 데이터를 처리한다. 검색된 페이지에는 사용자의 질문에 답하는 정보, 에이전트를 다른 방향으로 유도하는 지시, 또는 둘 다가 포함될 수 있다.

이로 인해 악의적인 지시가 사용자의 눈에 보이는 프롬프트가 아니라 외부 콘텐츠를 통해 유입되는 간접 프롬프트 인젝션이 발생한다. 이메일, 웹 페이지, 지원 티켓 또는 내부 문서를 읽는 에이전트는 일반적인 작업 중에 이러한 콘텐츠를 마주할 수 있다.

공격은 작업을 시작한 사람에게 보이지 않은 채 진행될 수 있다. 에이전트는 예상된 문서를 요약하면서도 조용히 다른 도구를 호출하거나, 오염된 정보를 메모리에 반영할 수 있다.

따라서 Mend.io의 5계층 프레이밍은 인벤토리 작성 방법으로 기능한다. 이는 팀에 지시, 권한, 코드, 데이터, 상태가 시스템에 들어오거나 나갈 수 있는 모든 지점을 식별하도록 요구한다.

이 인벤토리에는 배포된 모델 이상이 포함되어야 한다. 에이전트 구성, 시스템 프롬프트, MCP 서버, 사용 가능한 도구, 권한 범위, 메모리 저장소, 모델 제공업체, 종속성 및 책임자를 기록해야 한다.

이 지도가 없으면 팀은 하나의 손상된 구성 요소가 다른 구성 요소에 도달할 수 있는지 판단할 수 없다. 또한 통합의 동작이 바뀌었을 때 자신 있게 접근 권한을 철회할 수도 없다.

이 사건은 새로운 프로토콜 출시나 단일 취약점 공개가 아니다. 이는 더욱 명확해진 프로덕션 경계다. 에이전트 보안은 전체 실행 체인을 따라야 한다.

이 경계는 개발자, 플랫폼 팀, 보안 엔지니어 및 AI 공급업체 모두에 동시에 압박을 가한다. 각 그룹은 시스템의 일부만 통제하지만, 가장 심각한 실패는 이러한 조직적 구분을 가로질러 이동한다.

AI 에이전트는 언어를 권한 있는 작업으로 바꾼다

LLM의 출력이 실제 권한을 가진 소프트웨어를 제어할 때, 이는 실질적으로 다른 보안 문제가 된다.

일반적인 챗봇은 사람이 검토할 텍스트를 생성한다. 에이전트는 목표를 해석하고, 도구를 선택하며, 인수를 구성하고, 결과를 검사한 뒤 다른 인간의 판단 없이 계속 행동할 수 있다.

이 루프는 잘못된 모델 응답의 결과를 바꾼다. 조작된 문장은 불편한 수준에 그치지만, 데이터베이스나 배포 도구에 전달된 조작된 지시는 운영 사고로 이어질 수 있다.

벤더 제안서를 비교하도록 요청받은 내부 리서치 에이전트를 생각해 보자. 이 에이전트는 업로드된 문서를 읽고, 공유 스토리지를 검색하며, 조달 기록을 조회하고, 권고안을 작성한다.

악의적인 제안서는 다른 폴더의 기밀 가격 정보를 가져오도록 에이전트에 지시하는 내용을 숨길 수 있다. 스토리지 도구가 광범위한 권한을 가지고 있다면, 모델의 잘못된 결정은 실제 정보 유출 경로가 된다.

코딩 에이전트도 유사한 문제를 만든다. 코딩 에이전트는 리포지토리를 읽고, 종속성을 설치하며, 테스트를 실행하고, 파일을 수정하고, 풀 리퀘스트를 열 수 있다. 신뢰할 수 없는 이슈 텍스트나 패키지 문서는 이러한 기능을 보유한 동일한 모델에 영향을 줄 수 있다.

MCP는 이러한 연결을 일관된 방식으로 더 쉽게 구축하게 한다. 이는 개발자에게 이점이지만, 도구 설명, 도구 응답 또는 원격 서버가 에이전트의 이후 선택에 영향을 미칠 수 있음을 뜻하기도 한다.

OWASP의 에이전트 보안 지침은 프롬프트 인젝션, 도구 오용, 데이터 유출, 메모리 오염, 과도한 자율성 및 연쇄적 실패를 주요 위험으로 식별한다. 이 범주들은 고립된 것이 아니라 연결되어 있다.

메모리는 특히 중요하다. 영구 에이전트 메모리는 이후 세션을 위한 정보를 저장하여, 애플리케이션이 선호도, 이전 작업 또는 축적된 지식을 기억하도록 한다.

신뢰할 수 없는 콘텐츠가 검증 없이 이 저장소에 들어가면, 하나의 공격은 원래 대화가 끝난 뒤에도 지속될 수 있다. 이후 사용자는 오염된 사실을 받거나 이전 문서의 영향을 받은 동작을 촉발할 수 있다.

다중 에이전트 시스템은 가능한 피해 범위를 확대한다. 한 에이전트가 서로 다른 권한을 가진 다른 에이전트에게 지시, 요약, 자격 증명 또는 도구 결과를 전달할 수 있다.

손상된 리서치 에이전트에 데이터베이스 쓰기 권한이 없을 수는 있다. 하지만 쓰기 권한을 가진 운영 에이전트에 조작된 조사 결과를 제공할 수는 있다.

팀은 모든 모델에 악의적 지시를 무시하라고 말하는 것만으로 이 문제를 해결할 수 없다. 모델은 업무를 수행하기 위해 자연어를 처리해야 하며, 공격자는 표현, 맥락, 인코딩 및 전달 채널을 바꿀 수 있다.

따라서 보안의 목표는 작업 경계여야 한다. 도구가 실행되기 전에, 결정론적 소프트웨어가 에이전트, 사용자, 리소스, 작업 및 매개변수가 허용된 조합인지 판단해야 한다.

읽기 작업이 조용히 쓰기 작업으로 바뀌어서는 안 된다. 하나의 리포지토리에 대한 접근 권한이 모든 리포지토리에 대한 접근 권한을 부여해서도 안 된다. 이메일 초안 작성 권한이 자동으로 발송 권한을 허용해서는 안 된다.

영향이 큰 작업에는 더 강력한 처리가 필요하다. 금융 이체, 프로덕션 변경, 계정 관리, 데이터 삭제, 외부 게시 및 자격 증명 접근에는 명시적 승인 또는 사람의 승인이 요구되어야 한다.

승인은 실제 작업과 연결되어야 한다. “계속”과 같은 모호한 확인은 대상, 작업, 영향을 받는 리소스 및 중요한 매개변수를 표시하는 승인보다 약하다.

단기 자격 증명도 노출을 줄인다. 에이전트는 현재 작업에 필요한 최소한의 권한만 받아야 하며, 작업이 끝나면 그 권한을 잃어야 한다.

이 접근법은 특히 개발자가 작업 완료와 속도로 성공을 측정할 때 마찰을 더할 수 있다. 그러나 대안은 확률적 추론이 접근 제어 시스템 역할을 하도록 허용하는 것이다.

언어 모델은 작업을 제안할 수 있다. 하지만 자체 권한을 일방적으로 정의해서는 안 된다.

MCP는 연결을 표준화할 뿐, 완전한 거버넌스를 제공하지는 않는다

MCP는 호환성 문제를 해결하지만, 프로덕션 팀은 여전히 그 주변에 정책 및 책임성 계층을 구축해야 한다.

MCP 클라이언트는 서버에서 사용 가능한 도구 정의를 가져와 모델에 제시할 수 있다. 모델은 이러한 설명과 매개변수 스키마를 사용해 도구를 선택하고 호출한다.

이 구조는 맞춤형 통합 작업을 줄인다. 호환되는 클라이언트는 서비스마다 별도의 인터페이스를 학습하는 대신 공유 프로토콜을 통해 많은 서버에 연결할 수 있다.

하지만 표준화된 검색이 검색된 모든 도구를 신뢰할 수 있게 만드는 것은 아니다. 서버는 초기 보안 검토 후에 손상되거나, 사칭되거나, 잘못 구성되거나, 업데이트될 수 있다.

도구 오염은 이러한 신뢰를 악용한다. 도구 설명 안에 삽입된 악의적 지시는 사용자의 일반적인 상호작용에서는 숨겨진 채 모델에 영향을 줄 수 있다.

도구 응답도 유사한 지시를 담을 수 있다. 에이전트는 응답을 데이터로 취급할 수 있지만, 언어 모델은 삽입된 텍스트를 이후 작업에 영향을 주는 지시로 해석할 수 있다.

최신 MCP 권한 부여 규칙에는 토큰 검증, 대상 바인딩, 토큰 탈취, 통신 보안, 리디렉션 위험 및 혼동된 대리인 공격에 대응하는 요구사항이 포함되어 있다.

이러한 요구사항은 인증 및 권한 부여 기반을 강화한다. 하지만 특정 비즈니스 작업이 사용자의 현재 목표에 적절한지 여부를 판단하지는 않는다.

유효한 액세스 토큰은 그 범위 내에서 인식된 권한을 확립한다. 그러나 신뢰할 수 없는 콘텐츠를 읽은 뒤 모델이 올바른 결정을 내렸음을 증명하지는 않는다.

프로덕션 시스템에는 모델의 의도와 도구 실행 사이에 제어 지점이 필요하다. 이 계층은 신원, 요청된 작업, 리소스, 매개변수, 세션 위험, 데이터 분류 및 이전 작업을 평가할 수 있다.

Microsoft는 오픈소스 런타임 거버넌스 접근법을 소개하면서 이 격차를 설명했다. Microsoft의 내부 거버넌스 벤치마크는 45개의 적대적 사례와 15개의 유효 사례를 포함해 60개의 프롬프트를 테스트했다.

Microsoft는 시스템이 프롬프트 전용 안전 지시에 의존했을 때 정책 위반율이 26.67%였다고 보고했다. 회사는 방법론과 재현 자료를 제공했지만, 이 결과는 여전히 자체 평가 결과다.

그럼에도 이 결과는 중요한 설계 원칙을 보여 준다. 지시 이행 성능을 결정론적 보안 경계로 간주해서는 안 된다.

런타임 제어 플레인은 각 도구 요청을 허용, 거부 또는 상향 조정할 수 있다. 또한 도구 정의를 모델에 노출하기 전에 검사하고, 응답을 에이전트에 반환하기 전에 분석할 수 있다.

이러한 계층은 스키마, 매개변수 제약, 리소스 허용 목록, 속도 제한, 비용 한도, 최대 체인 깊이를 강제해야 합니다. 에이전트가 통제되지 않는 재시도 루프에 빠지도록 내버려 두는 대신, 반복되는 실패를 중단해야 합니다.

예를 들어 고객 지원 에이전트는 계정 기록을 읽고 환불 권고안을 작성해야 할 수 있습니다. 하지만 무제한 데이터베이스 접근 권한이나 자신이 제안하는 모든 환불을 즉시 처리할 권한까지 필요한 것은 아닙니다.

정책 계층은 조회 대상을 현재 고객으로 제한하고, 민감한 필드를 숨기며, 환불 금액에 상한을 두고, 지급 전에 사람의 승인을 요구할 수 있습니다. 모델은 광범위한 운영 권한을 부여받지 않아도 여전히 유용합니다.

격리도 중요합니다. 고권한 도구는 임의의 외부 MCP 서버와 동일한 에이전트 컨텍스트를 공유해서는 안 됩니다.

공개 웹 콘텐츠를 읽는 에이전트가 내부 관리 도구에 접근할 경로까지 자동으로 얻어서는 안 됩니다. 이러한 기능을 분리하면 악의적인 외부 콘텐츠가 민감한 실행 표면에 도달할 가능성을 낮출 수 있습니다.

보안팀은 승인된 서버 레지스트리도 유지해야 합니다. 각 항목에는 서버 소유자, 코드 출처, 배포 위치, 인증 방식, 사용 가능한 도구, 데이터 접근 범위, 버전, 검토 상태가 명시되어야 합니다.

도구 설명, 스키마, 종속성, 권한 또는 네트워크 대상이 변경되면 업데이트는 반드시 검토를 거쳐야 합니다. 몇 달 전에 검토를 통과한 서버라고 해서 영구적인 신뢰를 받아서는 안 됩니다.

MCP 서버에는 기존 서비스 수준의 보호도 필요합니다. 팀은 보안 전송, 인증, 패치 적용, 종속성 관리, 입력 검증, 시크릿 격리, 로깅, 사고 대응을 갖춰야 합니다.

프로토콜이 이러한 통제를 대체하는 것은 아닙니다. 오히려 이를 일관되게 적용해야 하는 지점을 하나 더 만듭니다.

진짜 상충 관계는 자율성과 통제 사이에 있다

기능이 하나 추가될 때마다 에이전트의 유용성은 높아지지만, 조작이 성공했을 때 발생할 수 있는 피해도 커집니다.

이 상충 관계는 에이전트 보안을 배포 직전에 덧붙이는 체크리스트로 만들 수 없는 이유를 설명합니다. 제품 설계는 보안 스캐너가 시스템을 검사하기 훨씬 전에 시스템이 가질 수 있는 최대 권한을 결정합니다.

도구가 없는 에이전트는 유해하거나 부정확한 텍스트를 생성할 수 있습니다. 파일 접근 권한이 있는 에이전트는 문서를 노출할 수 있습니다. 셸 접근 권한이 있는 에이전트는 명령을 실행할 수 있고, 프로덕션 시스템에 연결된 에이전트는 운영 중인 인프라를 변경할 수 있습니다.

광범위한 권한은 편의를 위해 프로토타입에 도입되는 경우가 많습니다. 개발자는 세부적인 권한 부여에 투자하기 전에 에이전트가 엔드투엔드 워크플로를 완료할 수 있는지 시험하고 싶어 합니다.

이러한 프로토타입은 예상보다 빠르게 프로덕션으로 옮겨갈 수 있습니다. 임시 자격 증명은 구성에 남고, 실험용 MCP 서버는 공유 인프라가 되며, 느슨한 도구 스키마는 문서화되지 않은 종속성으로 굳어집니다.

5계층 모델은 이러한 지름길을 드러내는 데 도움이 됩니다. 하지만 목록화만으로 이를 통제할 수는 없습니다.

각 에이전트에는 정의된 신뢰 경계가 필요합니다. 이 경계는 누가 이를 호출할 수 있는지, 어떤 데이터를 받을 수 있는지, 어떤 도구를 사용할 수 있는지, 어떤 리소스에 도달할 수 있는지, 어떤 결과에 승인이 필요한지를 명시해야 합니다.

팀은 읽기, 초안 작성, 권고, 실행 모드를 구분해야 합니다. 이러한 레이블은 단순한 프롬프트 문구가 아니라 강제 가능한 권한에 매핑되어야 합니다.

리서치 에이전트는 승인된 출처를 읽고 조사 결과 초안을 작성할 수 있습니다. 운영 에이전트는 배포 계획을 준비할 수 있습니다. 별도의 통제된 프로세스가 해당 계획을 검증하고 실행할 수 있습니다.

이러한 분리는 자율성을 낮추지만, 검토 가능한 전환 단계를 만듭니다. 조사자는 정보가 언제 권고안이 되었고, 그 권고안이 언제 행동으로 이어졌는지 확인할 수 있습니다.

관측 가능성도 같은 목표를 뒷받침합니다. 로그에는 요청을 시작한 사용자, 에이전트 ID, 모델 버전, 프롬프트 또는 정책 버전, MCP 서버, 도구 이름, 인수, 응답 분류, 승인 기록, 최종 결과가 기록되어야 합니다.

민감한 데이터를 이러한 로그에 부주의하게 복사해서는 안 됩니다. 보안 텔레메트리는 또 다른 노출된 시크릿 저장소를 만들지 않으면서 조사에 충분한 맥락을 제공해야 합니다.

에이전트 ID에는 특히 주의를 기울여야 합니다. 여러 에이전트가 하나의 서비스 계정을 공유하면 책임을 할당하거나 손상된 워크플로 하나의 권한을 철회하기 어렵습니다.

별도의 ID를 사용하면 에이전트별 권한 설정과 더 명확한 감사 추적이 가능합니다. 또한 리서치 에이전트가 갑자기 쓰기 접근을 요청하는 것과 같은 비정상적인 동작을 보안팀이 식별하는 데 도움이 됩니다.

정부 지침은 이제 MCP를 의도적인 보안 설계가 필요한 인프라로 다루고 있습니다. NSA의 2026년 5월 MCP 보안 지침은 인증, 인가, 격리, 서버 검증, 수명 주기 관리, 그리고 프로토콜 구성 요소 전반에 걸친 위험을 다룹니다.

이러한 관심은 성숙도의 변화를 시사합니다. MCP는 더 이상 로컬 데모를 통해 논의되는 개발자 편의 기능에만 머물지 않습니다. 조직들은 손상된 도구가 민감한 데이터와 운영에 영향을 미칠 수 있는 환경에서 이를 평가하고 있습니다.

Google Cloud의 에이전트 보안 통제도 비슷한 점을 강조합니다. 이 지침은 별도의 에이전트 ID, 최소 권한 역할, 프로덕션 리소스에 대한 읽기-쓰기 도구 접근을 막는 제한을 권고합니다.

이는 익숙한 보안 원칙입니다. 하지만 에이전트는 행동을 동적으로 선택하고 개발자가 열거하지 않은 워크플로로 개별적으로 유효한 도구들을 결합하기 때문에, 이를 적용하기가 더 어려워집니다.

안전하지 않은 도구 체이닝은 하나의 허용된 작업 결과가 유해한 연속 작업을 가능하게 할 때 발생합니다. 검색 도구, 파일 리더, 외부 메시징 도구는 각각 따로 검토하면 위험이 낮아 보일 수 있습니다.

그러나 이들이 결합되면 데이터 유출 경로가 만들어질 수 있습니다. 에이전트는 민감한 정보를 검색하고, 읽은 뒤, 조직 외부로 전송합니다.

따라서 정책은 개별 호출뿐 아니라 연속된 작업도 검토해야 합니다. 요청 하나만 보면 유효할 수 있지만, 같은 세션의 다른 이벤트 이후에는 의심스러울 수 있습니다.

컨텍스트 인식 통제는 신뢰할 수 없는 입력과 고권한 출력을 포함하는 조합을 차단할 수 있습니다. 또한 에이전트가 정보 수집에서 외부 행동으로 넘어갈 때 재승인을 요구할 수 있습니다.

이 설계는 사용자 프롬프트 주변에 필터를 추가하는 것보다 더 까다롭습니다. 제품, 플랫폼, ID, 애플리케이션 보안, 운영팀 간의 조율이 필요합니다.

이러한 조직적 비용도 상충 관계의 일부입니다. 기업은 보안 책임을 모델 제공업체에만 맡기면서 광범위한 자율 기능을 주장할 수 없습니다.

프로덕션 보안이 여전히 보장할 수 없는 것

다층 통제는 노출을 줄이지만, 현재의 어떤 프레임워크도 모든 모델, 도구, 컨텍스트 조합에서 에이전트가 안전하게 유지된다고 증명하지는 못합니다.

첫 번째 불확실성은 평가 품질입니다. 보안 테스트는 알려진 공격을 측정할 수 있지만, 프로덕션 입력은 계속 바뀌고 공격자는 공개된 방어책에 적응합니다.

레드팀 테스트 모음에는 직접 및 간접 프롬프트 인젝션, 무단 도구 사용, 권한 상승, 메모리 오염, 데이터 유출, 승인 우회, 재귀적 실행, 멀티 에이전트 전파가 포함되어야 합니다.

팀은 배포 전과 중대한 변경 후에 이러한 테스트를 실행해야 합니다. 새 모델, 시스템 프롬프트, 메모리 설계, MCP 서버, 도구 스키마, 검색 소스 또는 정책은 공격 표면을 바꿀 수 있습니다.

테스트 통과가 영구적인 안전을 의미하지는 않습니다. 이는 특정 조건에서 정의된 통제가 정의된 공격을 견뎌냈음을 보여줄 뿐입니다.

오탐은 또 다른 문제를 만듭니다. 통제가 너무 많은 정상 작업을 중단하면 사용자는 우회 방법을 찾거나 더 광범위한 권한을 요구합니다.

미탐은 더 위험하지만 관찰하기 어렵습니다. 에이전트는 요청된 작업을 완료하면서도 데이터를 유출하거나, 오염된 메모리를 저장하거나, 불필요한 행동을 취할 수 있습니다.

사람의 승인이 완전한 해결책은 아닙니다. 특히 애플리케이션이 빈번하거나 불명확한 프롬프트를 제시할 경우 사용자는 확인 절차에 익숙해져 무감각해질 수 있습니다.

공격자는 승인자에게 표시되는 정보도 조작할 수 있습니다. 승인 인터페이스는 모델의 설명만이 아니라 신뢰할 수 있는 실행 데이터에서 작업 세부 정보를 가져와야 합니다.

공급망 위험 역시 해결되지 않은 상태입니다. MCP 배포에는 서로 다른 주체가 유지 관리하는 서버, SDK, 레지스트리, 패키지, 모델, 컨테이너, 호스팅 서비스가 포함될 수 있습니다.

서명된 패키지는 출처와 무결성을 확립할 수 있습니다. 그러나 서명된 동작이 안전하다는 보장이나 원격 서비스가 변경되지 않는다는 보장을 제공하지는 못합니다.

조직은 재현 가능한 배포, 고정된 버전, 검토된 소스 코드, 통제된 레지스트리, 문서화된 업데이트 프로세스를 선호해야 합니다. 원격 서버에는 일회성 승인만이 아니라 지속적인 검증이 필요합니다.

긴급 권한 철회는 실질적으로 가능해야 합니다. 팀은 애플리케이션 릴리스를 기다리지 않고 에이전트, 서버, 도구, 자격 증명 또는 권한을 비활성화할 수 있어야 합니다.

메모리 시스템에도 이에 상응하는 통제가 필요합니다. 운영자는 조사 증거를 보존하면서 의심스러운 항목을 검사, 격리, 만료, 제거할 수 있는 방법을 갖춰야 합니다.

이러한 회의적 시각은 벤더의 주장에도 적용됩니다. 보안 제품은 점점 프롬프트 보호, 자동화된 레드팀 테스트, 에이전트 탐지, 보안 태세 관리 또는 런타임 강제를 약속합니다.

이러한 기능은 방어에 기여할 수 있지만, 구매자는 각 통제가 어디에 위치하는지와 실패 시 어떤 일이 발생하는지를 물어야 합니다. 의심스러운 텍스트만 표시하는 탐지기는 그에 따른 행동에 대한 인가를 대체할 수 없습니다.

팀은 측정 가능한 증거를 요구해야 합니다. 유용한 질문에는 어떤 공격 유형을 테스트했는지, 평가 데이터를 이용할 수 있는지, 우회를 어떻게 처리하는지, 강제가 실패 시 차단 방식으로 작동하는지가 포함됩니다.

지연 시간과 가용성도 검토해야 합니다. 모든 도구 호출 전에 배치되는 정책 서비스는 핵심 인프라가 됩니다.

해당 서비스가 실패 시 허용 방식으로 작동하면 에이전트는 통제 없이 행동할 수 있습니다. 실패 시 차단 방식으로 작동하면 종속 워크플로가 멈춥니다. 프로덕션 설계는 두 결과를 모두 명시적으로 다뤄야 합니다.

따라서 5계층 접근 방식은 보장이 아니라 토대입니다. 이는 모델만 검토했다면 놓쳤을 위험을 팀이 찾아내는 데 도움이 됩니다.

그 성공은 이러한 계층을 소유권, 강제 가능한 정책, 반복 가능한 테스트, 운영 대응으로 전환하는 데 달려 있습니다. 이 단계들이 없으면 프레임워크는 노출을 줄이지 못한 채 노출만 문서화하는 또 하나의 다이어그램이 됩니다.

에이전트 보안의 성숙도를 보여줄 세 가지 신호

다음 단계는 강제 가능한 기본값, 독립적인 테스트, 실제 배포 환경의 증거로 평가될 것입니다.

첫 번째 신호는 MCP 클라이언트와 서버가 기본적으로 더 좁은 인가를 채택하는지 여부입니다. 현대적인 인가 표준 지원도 중요하지만, 안전한 배포에는 리소스별 스코프와 읽기 및 쓰기 작업의 명확한 분리도 필요합니다.

더 강력한 생태계에서는 광범위한 권한이 명백히 예외적인 것으로 드러날 것입니다. 클라이언트는 각 서버가 접근할 수 있는 대상을 사용자에게 보여주고, 서버는 다른 리소스용으로 발급된 토큰을 거부할 것입니다.

기본 제한은 표준화된 연결성이 통제와 공존할 수 있다는 주장을 강화할 것입니다. 주변 자격 증명과 과도하게 넓은 스코프에 계속 의존한다면 그 주장은 약화될 것입니다.

두 번째 신호는 런타임 거버넌스에 대한 독립적인 평가입니다. 벤더 벤치마크는 유용한 출발점이지만, 구매자에게는 여러 모델, 도구, 공격 방식에 걸친 반복 가능한 테스트가 필요합니다.

평가자는 공격 방지뿐 아니라 정상 작업 완료 여부도 보고해야 합니다. 모든 도구 호출을 차단하는 시스템은 좁은 의미에서는 안전하지만, 운영 목적을 달성하지 못합니다.

결과는 프롬프트 탐지와 행동 강제도 구분해야 합니다. 의심스러운 언어를 탐지하는 것은 금지된 파일 읽기, 데이터베이스 업데이트 또는 외부 요청을 막는 것과 다릅니다.

세 번째 신호는 기업이 완전한 에이전트 목록과 사고 기록을 생성할 수 있는지 여부입니다. 조직은 어떤 에이전트가 배포되어 있는지, 누가 소유하는지, 어떤 모델을 사용하는지, 어떤 MCP 서버에 도달할 수 있는지 알아야 합니다.

또한 인증된 로그를 통해 중요한 작업을 재구성할 수 있어야 합니다. 누락된 신원 정보, 불완전한 도구 기록 또는 설명되지 않은 권한 변경은 도입 속도가 거버넌스를 앞질렀음을 시사합니다.

바로 이 지점에서 지식 관리와 보안 운영이 맞닿습니다. 팀에는 요구사항, 에이전트 구성, 테스트 결과, 승인, 사고 및 시정 조치 결정을 연결하는 검색 가능한 기록이 필요합니다.

통제된 기술 지식 기반은 엔지니어가 이러한 기록을 조회하는 데 도움이 될 수 있지만, 동일한 접근 권한 및 데이터 처리 경계를 준수해야 합니다.

Google News 노출은 5계층 보안 모델의 가시성을 더 넓힙니다. 그러나 그 지속적인 중요성은 팀이 이 가시성을 더 세분화된 권한과 더 강력한 실행 통제로 전환하는지에 달려 있습니다.

개발자는 하나의 프로덕션 워크플로부터 시작해 모든 입력, 모델 결정, 메모리 쓰기, 통합, 자격 증명, 도구 호출 및 출력을 매핑해야 합니다. 그런 다음 그 지점들 사이에서 발생하는 안전하지 않은 이동을 결정론적 정책이 어디에서 차단하는지 파악해야 합니다.

조직은 모든 프로덕션 에이전트가 무엇을 할 수 있는지, 어떤 신원이 이를 승인하는지, 그리고 하나의 손상된 문서가 어떻게 격리될 수 있는지를 설명할 수 있습니까? 답이 불완전하다면, 다음 조치는 또 하나의 프롬프트 규칙이 아닙니다. 더 좁은 실행 경계, 검증된 승인 경로, 그리고 에이전트의 추론 과정 이후에도 남는 감사 추적이 필요합니다.