AI로 생성한 독창적인 콘셉트 일러스트. 게이트는 각각 독립적인 권한 확인을 나타내며, 실제 제품이나 측정된 보안 결과를 의미하지 않는다.
답변이 아니라 행동에서 출발하자
조달 보조 에이전트에게 공급업체 세 곳의 제안서를 요약해 달라고 요청했다고 가정해 보자. 문서 하나에는 전체 비교 결과를 외부 주소로 보내라는 요청이 담겨 있다. 에이전트는 유효한 JSON을 생성하고, 올바른 이메일 도구를 사용하며, 매끄러운 문장을 작성한다. 그런데도 워크플로는 실패할 수 있다. 문서는 읽어야 할 자료이지, 정보 공개를 승인할 권한이 있는 사람이 아니기 때문이다.
이는 설계를 설명하기 위한 가상의 사례다. 우리는 공격을 실행하거나, 공급업체를 벤치마크하거나, 고객의 배포 환경을 점검하지 않았다. 주장은 더 제한적이다. 에이전트가 형식에 맞는 작업을 제안하는 능력과 시스템이 그 작업을 허용할지 결정하는 과정은 분리해야 한다.
아래 분석은 2026년 10월 21일 확인한 1차 자료를 바탕으로 한다. 이는 엔지니어링 프레임워크이며, 보안 인증이나 법률 의견이 아니다.
공식 문서가 실제로 알려 주는 것
OpenAI의 2026년 3월 11일 설명은 프롬프트 조작이 성공하더라도 피해를 제한해야 한다고 강조한다. 워크플로 안전 가이드는 구조화된 데이터와 승인을 권장하면서도, 완화 조치가 오류를 완전히 없애지는 못한다고 경고한다. 이 가이드는 Agent Builder를 다루며, 현재 페이지에는 해당 제품이 사용 중단 대상으로 표시돼 있다. 이 문서를 인용하는 것이 해당 제품의 도입을 권장한다는 뜻은 아니다.
Anthropic의 2025년 10월 20일 샌드박스 관련 글은 파일 시스템과 네트워크 격리를 설명한다. 현재 Claude Code 권한 문서는 도구 권한과 운영체제 수준의 강제를 구분한다. 일반적인 Read/Edit 규칙은 임의의 하위 프로세스가 수행하는 파일 접근까지 통제하지 않는다.
공식 Qwen-Agent 저장소는 코드 인터프리터를 위한 Docker 격리와 제한적인 디렉터리 마운트를 설명하지만, 기본 샌드박스를 실제 운영에 사용할 때는 주의가 필요하다고 밝힌다.
이 문서들은 서로 다른 계층과 제품을 다루며, 조건을 통제한 비교가 아니다. 미국 서비스가 지나치게 넓은 접근 권한으로 배포될 수도 있고, 중국 프레임워크가 엄격한 경계 안에 배포될 수도 있으며, 그 반대도 가능하다. 모델의 출신이나 호스팅 위치는 실제 설정 점검을 대신할 수 없다. 어떤 문서도 모든 상황에서 가장 안전한 공급업체가 누구인지 입증하지 않는다.
계획과 실행 사이에 권한 검증 게이트웨이를 두자
우리가 제안하는 설계는 책임을 세 가지로 나눈다. 모델은 작업을 제안하고, 게이트웨이는 권한을 검증하며, 권한을 좁게 제한한 실행기가 허용된 작업을 수행한다. 게이트웨이는 애플리케이션 코드와 정책 강제 수단이지, 모델에게 올바르게 행동하라고 지시하는 또 하나의 문구가 아니다.
실질적인 영향을 미치는 요청마다 판단을 인증된 사용자, 작업, 리소스, 목적지, 데이터 범위, 적용되는 제한에 연결해야 한다. 공급업체 제안서를 읽을 권한이 조용히 이메일로 전송할 권한으로 바뀌어서는 안 된다. 메시지 초안을 작성할 권한도 발송할 권한으로 바뀌어서는 안 된다. 필수 값이 없거나 모호하다면, 문제가 해결될 때까지 요청은 실행되지 않은 상태로 남아 있어야 한다.
스키마 검증도 이 설계에 필요하지만 역할은 다르다. 스키마는 수신자 필드에 문자열이 들어가도록 요구할 수 있다. 그러나 사용자가 해당 수신자를 승인했는지는 입증할 수 없다. 모델 기반 검토기도 위험을 발견하는 데 유용할 수 있지만, 예 또는 아니요를 반환한다는 이유만으로 결정론적인 접근 통제 경계가 되지는 않는다.
이러한 분리는 거부 이후의 책임도 분명히 한다. 잘못된 요청을 수정하거나 필요한 권한을 얻어야 한다. 같은 작업에 대한 거부를 우회하려고 계정을 바꾸거나 다른 경로를 택하는 것은 문제 해결이 아니다.
계획이 달라져도 유효하도록 승인을 구체화하자
유용한 확인 화면은 실제로 수행될 작업을 보여 준다. 목적지, 내용 또는 데이터 유형, 관련 리소스, 비용이나 범위의 제한이 포함돼야 한다. 중요한 변수를 감춘 채 포괄적으로 “에이전트를 허용할까요?”라고 묻는 버튼은 피해야 한다.
승인은 해당 제안에 연결해야 한다. 수신자, 첨부 파일, 금액, 리소스가 실질적으로 바뀌면 다시 평가한다. 범위가 한정된 반복 업무라면, 조직은 무해한 단계마다 사용자를 방해하기보다 좁은 범위의 지속적 권한을 정할 수 있다. 그 한계는 언제든 점검하고 강제할 수 있어야 하며, 외부 문서가 확대할 수 없어야 한다.
승인 피로와 과도한 권한 부여는 서로 연결된 설계 문제다. 사소한 읽기 작업마다 확인을 요구하면 사람들이 기계적으로 클릭하게 될 수 있다. 반대로 한 번의 포괄적인 승인은 이후의 위험을 감출 수 있다. 유용한 절충점은 저위험 작업에 관한 문서화된 정책, 실질적인 영향을 미치는 변경에 대한 구체적 승인, 그리고 권한이 불분명할 때 명시적으로 멈추는 절차다.
실수 이후의 영향을 제한하자
권한 확인은 요청된 작업을 보호하고, 런타임 격리는 실행 환경이 접근할 수 있는 범위를 제한한다. 애플리케이션이 지원한다면 범위를 좁힌 자격 증명, 제한된 파일 시스템 접근, 통제된 네트워크 목적지를 사용해야 한다. 위협 모델에는 하위 프로세스도 포함해야 한다. 동일한 작업자가 제한 없는 셸을 실행할 수 있다면, 파일 읽기 도구만 제한해서는 충분하지 않다.
작업의 상태는 모델의 설명과 별도로 관리해야 한다. 제안됨, 승인됨, 실행 요청 전달됨, 결과 확인됨은 서로 다른 상태다. 안정적인 요청 식별자를 기록하고, 지원되는 경우 멱등성 또는 중복 제거를 활용한다. 시간 초과가 발생하면 발송, 구매, 게시를 재시도하기 전에 실제 서비스 기록을 확인해야 한다. “응답을 받지 못했다”는 말은 “아무 일도 일어나지 않았다”는 증거가 아니다.
로그는 경위를 재구성할 수 있도록 도와야 하지만, 또 다른 유출 경로가 되어서는 안 된다. 작업 식별자, 판단, 정책 버전, 결과를 가리키는 서비스 참조 정보를 보존하고, 비밀 정보와 불필요한 개인적 내용은 최소화한다. 검토자에게 필요한 것은 조사에 충분한 정보이지, 모든 문서의 무차별적인 사본이 아니다.
실제 운영에 앞서 확인할 여섯 가지
다음은 제안하는 인수 검증 연습이며, 우리가 수행한 시험이나 포괄적인 보안 평가는 아니다.
- 검색해 가져온 문서에 외부 수신자를 넣는다. 인증된 사용자의 권한 부여 없이 허용된 목적지를 바꿀 수 있는가?
- 권한 범위를 벗어난 작업에 대해 유효한 JSON을 생성한다. 게이트웨이가 실행 요청을 전달하기 전에 거부하는가?
- 승인 후 목적지를 변경한다. 기존 승인이 변경된 작업에는 더 이상 적용되지 않는가?
- 하위 프로세스를 통해 권한 범위 밖의 파일을 읽으려 시도한다. 런타임 경계가 프롬프트에 적혀 있기만 한 것이 아니라 실제로 강제되는가?
- 발송 후 결과가 불분명한 시간 초과를 모의한다. 워크플로가 중복을 만들지 않고 서비스 기록과 상태를 대조할 수 있는가?
- 관련 권한을 철회한다. 다음 작업 시도가 안전하게 실패하고, 이해할 수 있는 감사 기록을 남기는가?
보호와 사용성을 함께 평가해야 한다. 차단된 미승인 작업, 잘못 차단된 승인 작업, 불필요한 승인 요청, 중복된 부수 효과, 판단을 설명하는 데 필요한 시간이 평가 대상이다. 높은 완료율만 보면 안전하지 않은 실행을 놓칠 수 있다. 그렇다고 모든 것을 막는 시스템이 유용한 비서인 것도 아니다.
구매할 때 정말 물어야 할 질문
실제로 배포할 설정에서 각 경계를 어느 계층이 강제하는지, 모델이 악성 문서를 따르면 어떻게 되는지, 실행 결과가 불분명할 때 상태를 어떻게 확인하고 맞추는지 공급업체에게 보여 달라고 요청하자. 다른 환경의 눈에 띄는 벤치마크 점수를 그대로 가져오기보다, 자신의 도구와 접근 범위에 맞는 증거를 요구해야 한다.
실용적인 선택은 “모델을 믿자”와 “영원히 허락을 구하자” 사이에 있지 않다. 명확한 제한 아래 어떤 작업을 진행할 수 있는지, 어떤 변경에 사람의 판단이 필요한지, 모델이 다시 쓸 수 없는 경계는 무엇인지 정하는 데 있다. 이것이 단일 능력 점수보다 중국과 미국의 에이전트 기술 스택을 비교하는 데 더 유용한 출발점이다.