기업이 AI 에이전트를 실험 단계에서 실제 업무로 옮길 때 가장 먼저 확인해야 할 것은 모델의 정확도만이 아니다. 에이전트가 어떤 시스템에 접근할 수 있는지, 누구의 권한으로 행동하는지, 잘못된 판단을 내렸을 때 어디까지 피해가 번질 수 있는지가 더 직접적인 운영 위험이 된다.

Docker가 Snyk, Keycard와 함께 제안한 Agent Baseline은 이런 문제를 다루기 위한 공개 보안 청사진이다. 현재 공개된 v1.0 문서는 기업용 에이전트 배포가 충족해야 할 최소 보안 결과를 여섯 영역, 35개 통제로 정리한다. 특정 모델의 안전성을 인증하는 규격이라기보다 에이전트의 실행 환경, 권한, 네트워크, 기록, 검증, 사고 대응을 하나의 운영 체계로 연결하려는 접근에 가깝다.

에이전트 보안이 기존 애플리케이션 보안과 다른 이유

기업은 이미 계정과 권한을 관리하고, 워크로드를 격리하고, 네트워크를 제한하며, 로그를 수집하고, 사고에 대응한다. 에이전트 환경에서도 이 통제들은 그대로 필요하다. 달라지는 점은 에이전트가 자연어 지시를 실행 중에 받아 행동을 바꾸고, 목표를 달성하기 위해 여러 도구와 자격 증명을 연속해서 사용할 수 있다는 것이다.

예를 들어 코딩 에이전트가 버그 하나를 수정하는 과정에서 소스 코드와 내부 문서를 읽고, 패키지를 설치하고, 외부 API를 호출하고, 다른 에이전트에 작업을 위임한 뒤 변경 사항을 커밋할 수 있다. 각각의 행동만 보면 정상적인 개발 절차처럼 보인다. 그러나 하나의 실행 주체가 위임받은 권한으로 여러 시스템을 빠르게 이동하면 개별 통제만으로 전체 위험을 파악하기 어려워진다.

고객 지원 에이전트도 마찬가지다. 티켓 첨부 파일 안에 고객 데이터베이스를 조회한 뒤 결과를 외부 주소로 전송하라는 악성 지시가 숨겨져 있다고 가정해 보자. 모델이 그 지시를 공격으로 판별하기만 기대해서는 충분하지 않다. 판별에 실패하더라도 허용되지 않은 외부 주소로 연결할 수 없어야 하고, 데이터베이스 권한은 해당 업무에 필요한 범위로 제한되어야 하며, 시도한 행동은 하나의 실행 기록으로 남아야 한다.

여섯 가지 보안 결과

영역 목표 개발자가 확인할 사항
Discover 운영 중인 에이전트와 실제 권한을 식별한다. 소유자, 목적, 모델, 도구, 의존성, 자격 증명, 하위 에이전트, 접근 가능한 데이터가 현재 실행 상태를 기준으로 기록되는지 확인한다.
Constrain 실행 환경과 접근 범위를 필요한 수준으로 제한한다. 파일시스템, 네트워크, 도구, 데이터, 연산 자원, 실행 시간이 업무 목적보다 넓게 허용되지 않았는지 점검한다.
Authorize 중요한 행동에 구체적이고 제한된 권한을 부여한다. 권한이 특정 신원, 작업, 대상, 범위, 유효 기간에 묶여 있는지, 다른 에이전트에 위임할 때 권한이 확대되지 않는지 본다.
Observe 의도부터 결과까지 하나의 흐름으로 추적한다. 프롬프트, 신원, 정책 결정, 도구 호출, 외부 요청, 결과를 안정적인 실행 ID나 추적 ID로 연결할 수 있는지 확인한다.
Validate 실제 운영 구성에서 동작과 결과를 검증한다. 개발용 모의 환경만이 아니라 배포될 모델, 프롬프트, 도구, 권한, 네트워크 정책 조합으로 테스트하는지 살핀다.
Respond 문제가 생겼을 때 실행과 권한을 신속히 차단한다. 실행 중지, 활성 권한 회수, 영향 구성요소 격리, 증거 보존, 영향 범위 확인, 수동 대체 절차가 준비되어 있는지 확인한다.

이 여섯 영역은 서로 따로 작동해서는 효과가 제한된다. 네트워크 정책이 외부 전송을 막더라도 어떤 에이전트가 어떤 권한으로 요청했는지 연결되지 않으면 조사 시간이 길어진다. 반대로 로그가 충분해도 광범위한 상시 자격 증명을 그대로 제공했다면 사고 발생 전 피해 범위를 줄이지 못한다. Agent Baseline의 핵심은 기존 통제를 새로 발명하는 데 있지 않고, 한 에이전트의 한 작업과 한 번의 실행을 기준으로 통제를 연결하는 데 있다.

개발 환경에 적용할 때 볼 세 가지 경계

에이전트가 침해되거나 잘못된 지시를 따를 때 피해는 크게 세 방향으로 퍼질 수 있다. 첫째는 호스트에서 실행하거나 변경할 수 있는 범위, 둘째는 증명하고 사용할 수 있는 신원과 권한, 셋째는 외부 또는 다른 내부 시스템에 연결할 수 있는 네트워크 범위다. 적용 검토에서는 이 세 경계를 따로 기록하는 편이 좋다.

  • 실행 경계: 저장소 전체 쓰기, 임의 명령 실행, 패키지 설치, Docker 소켓 접근, 배포 환경 변경이 정말 필요한지 확인한다.
  • 권한 경계: 개발자 개인 토큰이나 장기 자격 증명을 전달하는지, 특정 작업에만 유효한 단기 권한으로 바꿀 수 있는지 점검한다.
  • 통신 경계: 인터넷 전체가 기본 허용인지, 승인된 패키지 저장소와 API만 허용할 수 있는지, 차단된 요청이 증거로 남는지 확인한다.

특히 하위 에이전트를 만드는 기능을 사용할 때는 권한 상속 규칙이 중요하다. 작업을 위임받은 에이전트가 원래 에이전트보다 더 넓은 데이터나 도구에 접근해서는 안 된다. 모델과 프롬프트만 검토하고 위임된 자격 증명이나 도구 서버의 권한을 빠뜨리면 실제 실행 능력을 과소평가할 수 있다.

개인 개발자와 학생도 확인할 부분

Agent Baseline은 기업 운영을 주요 대상으로 하지만 개인 서버, 연구 프로젝트, 학습용 저장소에서도 판단 기준으로 활용할 수 있다. 모든 통제를 한꺼번에 구축하기보다 에이전트가 만지는 자산과 복구하기 어려운 행동부터 범위를 줄이는 방식이 현실적이다.

  • 개인 API 키, 클라우드 자격 증명, SSH 키가 에이전트 실행 환경에 그대로 노출되는지 확인한다.
  • 과제, 논문, 실험 데이터처럼 외부 전송이 곤란한 자료가 프롬프트나 도구 호출에 포함되는지 점검한다.
  • 저장소 쓰기와 커밋은 허용하더라도 기본 브랜치 병합이나 운영 배포는 별도 승인 단계로 분리한다.
  • 패키지 설치가 필요하다면 출처와 버전을 기록하고, 격리된 환경에서 먼저 실행한다.
  • 실패했을 때 변경 파일, 생성된 리소스, 사용된 권한을 확인하고 되돌릴 방법을 준비한다.

연구자라면 결과 재현성도 관찰 항목에 포함할 필요가 있다. 사용한 모델과 도구, 프롬프트 구성, 입력 데이터 범위가 바뀌면 같은 이름의 에이전트라도 실제 능력과 위험이 달라질 수 있다. 민감한 연구 자료를 사용한다면 데이터 보존, 외부 전송, 학습 사용 여부는 이용 중인 서비스의 최신 정책과 계약 조건을 별도로 확인해야 한다.

도입 전에 수행할 작은 검증

처음부터 전체 CI/CD나 개발 워크플로를 이전하기보다는 실패해도 복구하기 쉬운 저장소와 제한된 작업으로 시험하는 편이 안전하다. 테스트 과제는 단순 성공 여부뿐 아니라 공격 또는 오작동 상황에서 경계가 실제로 작동하는지 확인할 수 있어야 한다.

  1. 에이전트의 목적을 “테스트 저장소의 특정 오류 수정”처럼 좁게 정의한다.
  2. 읽기 가능한 디렉터리, 수정 가능한 파일, 호출 가능한 도구와 네트워크 목적지를 목록으로 만든다.
  3. 운영 자격 증명 대신 범위와 수명이 제한된 시험용 권한을 제공한다.
  4. 프롬프트 인젝션이 포함된 문서나 의존성 설치 요청처럼 예상 가능한 악성 입력을 시험한다.
  5. 차단된 요청과 허용된 행동이 동일한 실행 ID 아래 연결되는지 확인한다.
  6. 작업 종료 후 권한이 만료되거나 회수되는지, 생성된 변경을 쉽게 되돌릴 수 있는지 검증한다.

평가 기록에는 작업 완료 시간만 적지 말고 사람이 수정한 횟수, 잘못된 도구 호출, 권한 거부 횟수, 외부 통신 대상, 롤백 소요 시간도 함께 남기는 것이 좋다. 에이전트가 반복 작업을 줄이더라도 검토와 사고 대응 비용이 더 커진다면 운영상 이점이 약해질 수 있다.

제품 도입 판단에서 빠뜨리기 쉬운 조건

Agent Baseline 자체는 보안 결과를 정의하는 청사진이므로 이를 채택했다는 표현만으로 특정 제품이나 배포가 안전하다고 단정할 수 없다. 실제 제품이 35개 통제를 어느 범위까지 구현하는지, 통제가 기본값인지 별도 설정인지, 증거를 외부 감사나 사고 조사에 사용할 수 있는지 확인해야 한다.

검토 항목 확인할 질문 판단 기준
적용 범위 로컬 코딩 에이전트, CI 실행기, 운영 에이전트, 하위 에이전트 중 어디까지 관리하는가? 실제 사용하는 실행 경로가 빠짐없이 포함되어야 한다.
권한 장기 자격 증명 없이 작업별·대상별 권한을 발급하고 회수할 수 있는가? 권한의 범위와 유효 시간이 명확하고 위임 시 확대되지 않아야 한다.
관찰성 모델 요청, 정책 판단, 도구 호출과 최종 변경을 하나의 실행으로 추적할 수 있는가? 여러 로그를 수작업으로 맞추지 않아도 사건의 흐름을 재구성할 수 있어야 한다.
운영 대응 실행 중지와 자격 증명 회수가 즉시 가능한가? 자동 차단뿐 아니라 조사 중 업무를 이어갈 수동 대체 절차가 필요하다.
호환성 현재 저장소, CI/CD, 도구 서버, 인증 체계와 연결되는가? 새 통제 도입 때문에 우회 권한이나 별도 비밀값이 늘어나지 않아야 한다.
비용 격리 환경, 로그 보존, 정책 관리, 실행량에 따라 어떤 비용이 발생하는가? 공식 가격과 계약 조건을 확인하고 기존 도구의 운영 비용까지 함께 비교해야 한다.
대안 현재의 컨테이너 격리, 네트워크 정책, 비밀 관리, 감사 로그로 같은 결과를 낼 수 있는가? 새 제품의 전환 비용보다 통제 연결과 반복 작업 절감 효과가 클 때 검토 가치가 높다.

가격, 지원 계정, 지역별 제공 범위와 데이터 보존 정책은 제공 방식에 따라 달라질 수 있으므로 발표 내용만으로 판단해서는 안 된다. 공식 문서와 실제 계약 조건을 확인한 뒤 작은 환경에서 검증해야 한다. Docker는 에이전트 격리와 중앙화된 거버넌스 관련 제품도 소개하지만, 제품 사용 여부와 별개로 여섯 결과가 현재 스택에서 충족되는지를 먼저 보는 것이 핵심이다.

실무에서 사용할 최종 질문

보안 검토를 복잡한 체크리스트로 시작하기 어렵다면 모든 에이전트에 다음 세 질문부터 적용할 수 있다. 지금 무엇이 실행되고 있으며 실제로 무엇을 할 수 있는가? 승인된 경계 안에서 행동하고 있음을 확인할 수 있는가? 문제가 생겼을 때 발생 경위를 증명하고 즉시 멈출 수 있는가?

세 질문 중 하나라도 답이 모호하다면 모델 성능이나 자동화 속도보다 실행 범위와 증거 수집 방식을 먼저 정리해야 한다. 에이전트 도입의 목표는 사람의 검토를 완전히 없애는 것이 아니라, 모델이 잘못 판단하더라도 권한과 시스템 경계가 피해를 제한하도록 만드는 데 있다.

출처와 검증

이 글은 Docker Blog가 2026년 8월 12일 공개한 설명과 제공된 Agent Baseline v1.0 정보를 기준으로 재구성했다. 문서는 현재 초안 상태로 소개되어 있으므로 실제 적용 전에는 통제 항목의 최신 버전, 지원 범위, 제품별 구현 방식, 가격과 데이터 처리 조건을 공식 자료에서 다시 확인해야 한다.

Docker Blog 원문: A new security baseline for enterprise agentic adoption