에이전트 판단과 실행 통제

공식 자료의 역할을 나눈 개념도입니다. 실제 공격 시험이나 모든 하드웨어 조합의 배포 완료를 뜻하지 않습니다.

2026년 9월 28일 Anthropic과 NVIDIA는 Claude Managed Agents와 OpenShell을 연결하는 에이전트 실행 통제 구상을 각각 공식 채널에서 설명했습니다. Anthropic은 관리형 에이전트의 실행 환경과 자격 증명 분리를, NVIDIA는 모델 밖에서 적용하는 런타임 정책을 소개했습니다. 두 글이 협력을 서로 확인한다는 점이 이번 사건의 근거입니다. 이 글은 10월 2일 확인한 공식 자료를 바탕으로 각 계층의 역할과 제공 범위를 정리합니다. 실제 설치나 공격 재현 시험을 수행한 결과는 아닙니다. Anthropic 설명, NVIDIA 발표

모델의 판단과 실행 권한을 구분하는 구조

에이전트가 어떤 명령을 제안할지와 그 명령을 실행 환경이 허용할지는 서로 다른 문제입니다. 모델에 주는 지침은 행동을 유도하고, 실행 정책은 접근 가능한 자원을 정합니다. Anthropic은 모델 차원의 보호, Managed Agents의 구조, OpenShell의 외부 통제를 상호 보완적인 계층으로 설명합니다. 이번 발표를 모델 내부의 보호가 없어지거나 모든 기존 보안이 대체됐다는 뜻으로 읽을 근거는 없습니다.

NVIDIA 개발자 본문은 OpenShell 0.1.0을 에이전트 실행에 권한 제어를 더하는 계층으로 소개합니다. 핵심은 파일, 네트워크, 데이터와 도구 접근 규칙을 에이전트 밖에서 적용하는 방식입니다. 모델이 접근을 요청하더라도 설정된 경계가 허용해야 실행할 수 있다는 설계입니다. 정책이 보호하는 범위는 작성한 규칙과 실제 실행 환경에 달려 있으므로, 어떤 명령이나 공격도 예외 없이 막는다는 보장으로 확대하지 않습니다. OpenShell 기술 설명

아키텍처 심층 분석: Managed Agents와 OpenShell의 2중 방어선

이번 협력 구조는 Anthropic의 Claude Managed Agents 아키텍처와 NVIDIA OpenShell 런타임이 상호 보완적인 2중 방어선을 형성하는 형태로 설계되었습니다.

Anthropic에 따르면 Managed Agents는 에이전트 루프를 작업 샌드박스와 분리된 서버에서 실행하고 자격 증명을 별도 금고에 둡니다. 에이전트가 인증 정보를 직접 보지 않도록 하는 것은 제공자가 설명한 설계입니다. 작업 코드의 실행 공간과 인증 정보의 저장 공간을 나누는 역할을 합니다. 이를 모든 종류의 메모리 탈취나 인증 정보 유출이 불가능하다는 독립 검증 결과로 읽어서는 안 됩니다. 실제 운영에서는 사용하는 연결과 권한 설정을 함께 확인해야 합니다. Managed Agents 구조

OpenShell은 Apache 2.0으로 공개된 런타임입니다. Anthropic 설명의 기본 원칙은 허용 규칙이 없으면 접근을 거부하는 default-deny입니다. 파일, 네트워크, 데이터와 도구에 대한 정책을 밖에서 검사하고 허용 및 거부 기록을 남긴다고 설명합니다. 관리자는 필요한 업무만 허용하고 기록을 보면서 규칙을 조정할 수 있습니다. 이 자료만으로 모든 환경에서 같은 정책 파일을 그대로 적용할 수 있다거나 특정 IP 목록과 셸 명령 목록만으로 충분하다고 단정하지 않습니다.

정책과 감사 기록이 담당하는 역할

실행 환경을 설계하는 팀은 에이전트가 읽어야 할 자료, 바꿔도 되는 파일, 호출해야 할 서비스를 구분할 수 있습니다. 예를 들어 조회 업무에 필요한 접근과 데이터 변경 업무에 필요한 접근은 다릅니다. 이는 활용을 설명하기 위한 예시이며 특정 기업에서 이미 검증된 배포 사례가 아닙니다. 자체 인프라와 관리형 샌드박스 중 무엇을 쓰더라도 실제 업무의 도구와 연결이 그 경계 안에서 동작하는지 확인할 필요가 있습니다.

NVIDIA 개발자 글은 Codex, Claude Code 등을 기존 에이전트 도구의 예로 설명합니다. OpenShell이 Claude 전용 제품은 아니라는 제공자의 설명입니다. 그러나 이름이 목록에 있다는 사실이 모든 버전, 운영체제와 사용자 설정의 호환성을 보장하지는 않습니다. 이번 글은 해당 도구를 설치하거나 조합을 시험하지 않았습니다. 도입 판단에서는 공식 지원 범위와 실제 사용할 버전, 실행 방식 및 서비스 연결을 함께 대조해야 합니다.

접근 기록은 어떤 요청이 허용되거나 거부됐는지 검토하는 자료가 됩니다. 정책 검사와 기록은 다른 역할을 담당합니다. 검사 단계는 실행 경계를 적용하고, 기록 단계는 그 결과를 되짚게 합니다. 로그가 있다는 사실만으로 모든 사고 원인이 자동 규명되거나 모든 감사 기준을 충족한다고 말할 수 없습니다. 또한 기존 모니터링 제품이 전부 사후 분석만 했다는 비교는 이번 세 자료로 입증되지 않습니다.

기업 업무에서 검토할 수 있는 항목

보안 담당자에게는 에이전트가 도달할 수 있는 자원을 명시하고 실제 요청 기록을 확인하는 구조가 검토 대상입니다. 자연어 지침에 적은 제한과 실행 환경이 적용하는 권한은 같지 않을 수 있습니다. 예컨대 특정 데이터에 접근하지 말라는 지침을 넣었다면, 그 데이터가 실행 환경에서도 차단되는지 별도로 확인할 수 있습니다. 이 구조의 유용성은 그러한 대조가 가능하다는 데 있으며, 규제나 인증을 자동 충족한다는 의미는 아닙니다.

플랫폼 팀은 업무에 필요한 최소한의 연결로 시작하고 허용 및 거부 기록을 검토하는 방식으로 적용 범위를 조정할 수 있습니다. Anthropic 글도 좁은 접근 범위에서 시작해 규칙을 강화하는 흐름을 설명합니다. 정책을 엄격하게 만들면 정당한 업무가 막힐 수 있으므로 권한 축소와 실제 작업 성공 여부를 함께 살펴야 합니다. 보호를 위해 둔 경계가 어떤 작업을 허용하는지 설명할 수 있어야 운영상 판단에 도움이 됩니다.

공식 글은 정책 증명기가 작성된 규칙 아래에서 도달 가능한 범위를 분석한다고 설명합니다. 이는 규칙에 표현된 권한의 분석입니다. 실제 소프트웨어의 모든 결함, 외부 서비스의 동작이나 조직 전체의 보안 상태를 증명한 것과는 구분해야 합니다. 독자는 모델의 답변 품질, 정책의 허용 범위, 실행 환경의 구현을 서로 다른 확인 대상으로 볼 수 있습니다. 정책 분석 설명

OpenShell 제공과 Sentry 참조 설계의 구분

NVIDIA는 OpenShell과 함께 Sentry를 참조 설계로 제시했습니다. 보도자료는 BlueField-4 DPU와 DOCA를 활용하는 별도 감시 계층을 설명합니다. 소프트웨어 런타임과 하드웨어를 사용하는 감시 구상은 역할과 제공 단위가 다릅니다. 따라서 OpenShell 소스가 공개됐다는 사실을 모든 하드웨어 조합의 배포 완료로 바꿔 쓰면 안 됩니다. 플랫폼 구성 설명

Sentry에 관한 처리 시간이나 격리 성능은 NVIDIA가 제시한 설명입니다. 이 글에서 현장 부하나 공격 조건을 재현해 측정하지 않았으므로 독립 벤치마크 결과로 사용하지 않습니다. 별도 감시 계층이라는 구조만으로 호스트 운영체제가 침해된 모든 상황에서 유출이 차단된다고 추론할 수도 없습니다. 실제 제품 제공 범위와 적용 조건은 소프트웨어의 공개 여부와 별도로 확인해야 합니다.

확인된 제공 범위와 남는 검증

Anthropic은 발표 당일 Managed Agents를 사용할 수 있으며 자체 인프라 또는 관리형 제공자의 샌드박스를 활용할 수 있다고 적었습니다. OpenShell은 GitHub와 개발자 자료에서 제공된다고 설명합니다. NVIDIA도 OpenShell의 제공을 알리는 한편 일부 기능과 제품의 일정은 바뀔 수 있다고 밝혔습니다. 이 발표는 소프트웨어의 가용성을 확인하는 근거이며, 모든 참조 설계가 모든 고객 환경에서 완성됐다는 근거는 아닙니다.

정책 검사에 따른 지연, 실제 업무의 성공률과 보호 효과는 이번 자료만으로 수치화할 수 없습니다. 제공자가 설명한 구조를 확인하는 일과 사용 환경에서 이를 검증하는 일은 다른 단계입니다. 향후 비교를 한다면 같은 작업, 같은 권한 범위와 같은 도구를 기준으로 해야 차이를 해석할 수 있습니다. 이번에는 독립 시험 수치가 없으므로 성능 향상이나 지연 비용을 숫자로 제시하지 않습니다.

다른 기업의 도입 사례나 파트너 참여 수를 협력의 성과로 추가하지 않았습니다. 이번 사건에서 직접 대조한 것은 Anthropic과 NVIDIA의 두 발표 및 NVIDIA 기술 본문입니다. 개발자 페이지 상단의 AI 생성 요약도 기술 본문과 구분했습니다. 제3자 인용이 있더라도 해당 기업이 별도로 발표한 내용까지 확인했다는 뜻은 아닙니다.

0.1.0이라는 버전 표시는 읽은 개발자 글이 다루는 버전을 식별합니다. 버전 숫자만으로 제품이 안전하거나 불안전하다고 평가할 수는 없습니다. 실제 도구 연결, 정책 작성 방식, 업무별 실패 처리와 운영 기록을 검토하는 것이 별도의 확인 항목입니다.

이번 발표를 읽는 기준

핵심은 에이전트의 판단, 실제 작업 공간, 자격 증명과 실행 정책을 나누어 설명했다는 점입니다. 이 분리는 모델 보호와 외부 실행 통제가 함께 필요한 이유를 보여줍니다. 발표의 설계 의도와 현재 제공된 소프트웨어, 아직 검증하지 않은 성능을 구분하면 과도한 보안 보장 없이도 도입 검토의 출발점을 잡을 수 있습니다.

실행 정책과 기록은 검토의 출발점입니다. 실제 운영에서 필요한 권한을 정의하고 정당한 작업이 완료되는지 확인하는 단계는 별도로 남습니다. 이번 기사는 제공자의 설계 설명을 대조한 것으로 보안 인증이나 독립 성능 검증을 대신하지 않습니다.

출처 목록