MCP 대 CLI: AI 에이전트가 커넥터를 찾지 못할 때 발생하는 일

AI 에이전트가 기계에서 작업해야 할 때, 깔끔한 경로는 Model Context Protocol (MCP)입니다. MCP 서버는 정의된 도구 세트를 노출하며, 에이전트가 이를 호출하고 허용된 작업을 판단할 수 있습니다. 목록이 짧고 문서화되어 있기 때문입니다. 그다음 에이전트가 커넥터가 없는 내부 티켓 시스템이나 2012년 이후 아무도 건드리지 않은 업무용 앱 같은 것이 필요할 때 상황이 달라집니다. 작업을 완료하려는 에이전트는 다른 문을 찾고, 그 문은 거의 항상 명령줄입니다.

온라인에서 MCP 대 CLI 논의의 대부분은 토큰 비용, OAuth, 그리고 자격 증명 처리에 집중되어 있습니다. 이는 타당한 논쟁거리입니다. 에이전트가 MCP 경로를 벗어난 후 실제로 엔드포인트가 무엇을 실행할지에 대해서는 거의 다루지 않으며, 이 부분은 IT 관리자들이 담당하게 됩니다.

MCP vs CLI

두 가지 접근 방식은 에이전트에게 매우 다른 수준의 권한을 부여합니다. MCP에서는 에이전트가 정의된 도구 목록만 받고 그 외에는 아무것도 받지 않습니다. CLI에서는 에이전트가 셸을 제어하며, 셸은 로그인한 사용자의 모든 권한을 가집니다. 아래에서 다루는 최신 방식인 코드 모드는 관리되는 데스크톱에서 실행될 때 CLI 쪽과 유사하게 동작하는데, 에이전트가 자체 프로그램을 작성하고 기계가 이를 실행하기 때문입니다.

이 차이가 개발자들이 CLI를 선호하는 이유를 설명합니다(토큰 소모가 적고 에이전트가 git, docker 같은 도구에 익숙함) 그리고 보안팀이 MCP를 선호하는 이유(짧은 목록이 감사하기 쉽고 OAuth가 중앙 인증을 제공함). 양측 모두 일리가 있습니다. 하지만 어느 쪽도 해결하지 못한 것은 agent가 아무도 승인하지 않은 것을 실행하지 못하게 막는 것이 무엇인지입니다. 도구 목록을 벗어나면 말이죠.

에이전트가 CLI로 대체됩니다

개발자가 에이전트에게 해당 티켓팅 시스템에서 데이터를 가져오라고 요청한다고 가정해 보세요. 커넥터가 없으면 에이전트가 스크립트를 작성하고, 도우미 바이너리를 다운로드하며, 몇 가지 명령을 연결하는데, MCP 거버넌스가 이를 전혀 보지 못했기 때문에 아무도 승인하지 않았습니다. 에이전트는 MCP 세계를 완전히 벗어났습니다. 이는 보안 팀이 앞 금고를 몇 달 동안 지키는 동안 팀이 하역장으로 들어오는 강도 영화와 같습니다. 여기서 팀은 선의의 소프트웨어이고, 하역장은 똑같이 열려 있습니다.

대체 수단도 조용한데, MCP 로그에는 에이전트가 자체적으로 실행한 PowerShell command 기록이 없기 때문입니다.

MCP를 사용한 코드 실행은 에이전트가 작성한 코드를 엔드포인트에 배치합니다

MCP 자체가 변화하고 있습니다. 한 번에 하나의 도구만 호출하고 모든 결과를 모델로 다시 보내는 대신, 에이전트는 코드 모드로 전환하고 있습니다. 에이전트가 MCP 도구를 호출하고, 반환된 결과를 필터링 및 결합한 후 전체를 실행하는 작은 프로그램을 작성합니다. Anthropic은 이 패턴을 자신의 엔지니어링 블로그에서 설명했으며, 한 스크립트가 각 결과를 모델에 전달하지 않고도 20개의 도구 호출을 할 수 있기 때문에 매력이 분명합니다. 토큰을 절약하고 에이전트를 더 유능하게 만들어 점점 확산되고 있습니다.

또한 실제 에이전트 작성 코드를 엔드포인트에 배치합니다. MCP를 통한 코드 실행은 에이전트가 호출할 수 있는 도구에서 엔드포인트가 실행할 프로그램으로 제어 문제를 전환하며, 프로그램은 작성자만큼만 신뢰할 수 있습니다. 일부 설정은 해당 코드를 샌드박스에서 실행하며, 샌드박스는 큰 도움이 됩니다. 그러나 관리되는 Windows 또는 Mac 데스크톱은 일반적으로 샌드박스가 아니며, 기기가 전달받은 모든 것을 실행한다면 승인된 도구 목록은 단지 제안일 뿐입니다. 에이전트 코드는 MCP 서버를 통과하듯 쉽게 우회할 수 있기 때문입니다.

로컬 관리자 권한으로 악성 셸 또는 에이전트 스크립트가 할 수 있는 일

피해는 에이전트가 빌리는 권한에 따라 다릅니다. 로컬 관리자 권한에서는 CLI 폴백이 기계를 완전히 제어할 수 있어, 누구에게도 묻지 않고 소프트웨어를 설치하거나 보호 기능을 끌 수 있습니다. 일반 사용자의 에이전트도 실수로 또는 프롬프트 인젝션이 숨겨진 문서에 의해 실행 파일을 실행할 수 있습니다.

코드가 실행되는 위치에서 제한 적용

많은 팀이 시스템 프롬프트, 가드레일, 쉬운 언어 정책으로 에이전트 자체를 제어하려고 합니다. 이는 도움이 되지만 AI 측면에서 작동하며, 에이전트는 혼란스럽거나 조작될 수 있습니다. 신뢰할 수 있는 방법은 코드가 실행되는 곳에서 제한을 적용하여 에이전트가 무엇을 시도하든 결과가 안전하게 유지되도록 하는 것입니다. 엔드포인트는 IT가 이미 소유한 스택의 일부이며, 바로 그곳에서 PolicyPak이 작동합니다.

PolicyPak이 MCP와 CLI를 처리하는 방법: 최소 권한 및 허용 목록

PolicyPak은 문제를 두 방향에서 접근하며, 첫 번째는 최소 권한입니다. PolicyPak Least Privilege Manager는 사용자로부터 로컬 관리자 권한을 제거하고 Windows와 Mac에서 필요한 특정 애플리케이션과 작업에만 관리자 권한을 부여합니다. 표준 사용자로 CLI에 접근하는 에이전트는 드라이버를 설치하거나 보안 도구를 조작할 수 없으며, 부여한 예외는 지정한 앱에만 적용됩니다.

두 번째는 허용 목록입니다. PolicyPak SecureRun은 파일 소유권을 기반으로 작동합니다. 표준 사용자가 도입한 실행 파일이나 그와 같은 역할을 하는 에이전트가 만든 실행 파일은 신뢰할 수 있는 계정(예: 소프트웨어 배포 도구나 관리자)이 소유하지 않는 한 실행되지 않습니다. 이는 코드 모드에서 중요합니다. 에이전트가 스크립트를 작성하거나 보조 바이너리를 배치할 때 SecureRun은 해당 파일을 신뢰하지 않고 차단합니다. 이것이 바로 원클릭 랜섬웨어 방지 기능으로 작동하는 이유이기도 합니다. 해시별 유지 관리 없이 포괄적인 허용 목록을 얻고 이미 사용하는 도구를 제거하지 않아도 됩니다.

에이전트는 커넥터가 있는 곳 어디서나 MCP를 계속 사용할 수 있습니다. 커넥터가 없는 경우 CLI 폴백은 사용자가 관리자 권한이 없는 머신에서 실행되며, 에이전트가 방금 작성한 파일에는 신뢰할 수 있는 소유자가 없으며, MCP로 코드 실행이 일반적인 경우에도 이 상태가 유지됩니다.