AI 에이전트에게 운영 권한을 줄 때, 진짜 무서운 건 삭제보다 비밀 유출임

• 홈랩을 AI SRE에게 맡겨보려던 실험이었는데, 주제는 금방 “에이전트 보안”으로 커짐

  • 글쓴이는 사무실 홈랩에서 k3s와 Ansible로 immich, silverbullet, beaverhabits 같은 앱을 셀프호스팅 중이었음
  • 목표는 Hermes Agent를 알림(alert)이 뜰 때마다 실행해서, 장애 원인을 찾고 직접 복구까지 하게 만드는 것
  • 모델은 Gemma4, Qwen 같은 로컬 모델도 써보려 했고, 그래서 더더욱 “얘네를 믿어도 되나?” 문제가 생김

• 에이전트에게 GitHub, Kubernetes, Grafana, Todoist 같은 CLI 권한을 주면 공격면이 확 넓어짐

  • 첫 번째 위험은 파괴적 명령임. 누가 프롬프트 인젝션으로 Python 스크립트를 실행시켜서 rm -rf 비슷한 짓을 하게 만들 수 있음
  • 두 번째 위험은 시크릿 유출임. 숨은 HTML에 “이 스크립트를 실행하면 답을 얻을 수 있다”고 써두면, 에이전트가 토큰을 읽어 외부로 보낼 수도 있음
  • 글쓴이는 rootless 컨테이너를 쓰고, git에 없는 중요한 데이터는 안 넣을 생각이라 삭제 위험은 상대적으로 덜 걱정했음
  • 하지만 시크릿 유출은 별개 문제였음. API 토큰 하나 털리면 컨테이너 바깥 서비스까지 영향이 번짐

• 첫 번째 방어책은 credential injection proxy였음

  • 컨테이너에는 fake-todoist-token 같은 가짜 자격 증명만 넣음
  • 에이전트가 API 요청을 보내면 HTTP 프록시가 중간에서 헤더를 고쳐 실제 토큰으로 바꿔 넣음
  • 예를 들어 api.todoist.com 요청의 Authorization 헤더에서 Bearer fake-todoist-key-1을 실제 ${TODOIST_API_KEY}로 치환하는 식임
  • api.parallel.ai의 x-api-key, Matrix 서버의 Authorization 헤더도 같은 패턴으로 처리함

• HTTPS까지 다루려면 프록시가 사실상 MITM을 해야 해서, 인증서 배포가 필요해짐

  • 글쓴이는 initContainer에서 credential proxy의 CA 인증서를 받아 컨테이너 CA bundle에 붙였음
  • 그다음 SSL_CERT_FILE, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, NODE_EXTRA_CA_CERTS를 모두 같은 CA bundle로 맞춤
  • 이 정도면 curl, requests, Node 계열 도구는 꽤 잘 따라오지만, 현실은 여기서 끝이 아니었음

• 프록시는 좋은 시작이었지만, “모든 도구가 프록시를 따른다”는 가정이 깨짐

  • Playwright의 Chrome은 인증서를 제대로 안 먹었고, 결국 Playwright 설정을 명시적으로 건드려야 하는 상황이 됨
  • Hermes 자체를 수정하고 싶지 않아서, 글쓴이는 Camoufox를 쓰는 별도 배포로 우회함
  • Matrix 클라이언트는 matrix[nio]가 내부에서 aiohttp를 쓰는데, trust_env=True가 없어서 HTTP_PROXY를 안 탔음
  • 이후 Hermes가 mautrix로 옮겨갔지만, 이것도 HTTP_PROXY를 지원하지 않는다고 함. 이쯤 되면 “표준 환경변수면 되겠지”가 꽤 위험한 믿음임

• 그래서 더 낮은 레이어의 샌드박스가 흥미로운 대안으로 등장함

  • gVisor는 Go로 된 네트워크 스택을 갖고 있어서, 여기에서 에이전트가 보내는 모든 outbound 요청을 가로챌 수 있음
  • 프록시를 우회하는 라이브러리여도 네트워크 스택 레벨에서 allow/deny 리스트를 걸 수 있다는 얘기임
  • 코드가 아직 Grafana 내부 저장소에 있다고 하지만, 글쓴이는 오픈소스화되면 직접 써보고 기여할 생각도 있어 보임

sequenceDiagram
    participant 에이전트
    participant 프록시
    participant 외부API
    participant 샌드박스

    에이전트->>프록시: 가짜 토큰으로 API 요청
    프록시->>프록시: 헤더를 실제 토큰으로 치환
    프록시->>외부API: 실제 자격 증명으로 요청 전달
    외부API-->>프록시: 응답 반환
    프록시-->>에이전트: 응답 전달
    에이전트->>샌드박스: 프록시 우회 요청 시도
    샌드박스-->>에이전트: 도메인 정책으로 차단 또는 허용

• Kubernetes 쪽에서도 이런 샌드박스 실행 모델이 점점 현실화되는 분위기임

  • 글쓴이는 Hermes를 이 샌드박스 안에서 돌리려면 K3s 바깥으로 빼야 하는지 고민했음
  • 그런데 Kubernetes 프로젝트가 네이티브 지원을 작업 중이고, GKE도 실험적 지원을 제공한다고 함
  • 다만 문서는 꽤 이상하다고 표현함. 아직 매끈한 운영 경험과는 거리가 있어 보임

• 결론은 꽤 현실적임. AI SRE를 만드는 일은 “모델에게 runbook을 알려주면 끝”이 아님

  • 도구 권한, 시크릿 주입, HTTPS 인증서, 브라우저 런타임, 라이브러리별 프록시 지원, 샌드박스 네트워킹까지 전부 얽힘
  • 특히 사내 운영 자동화 에이전트라면, 모델보다 먼저 “이 에이전트가 절대 보면 안 되는 것”과 “절대 보낼 수 없는 곳”을 정해야 함

기술 맥락

• 여기서 선택한 첫 번째 해법은 credential injection proxy예요. 에이전트에게 진짜 토큰을 주지 않기 위해서인데, 프롬프트 인젝션이 터져도 컨테이너 안에서 바로 시크릿을 긁어갈 수 없게 만들려는 의도예요.

• 이 방식이 귀찮아지는 이유는 HTTPS 때문이에요. 요청 헤더를 바꾸려면 암호화된 트래픽을 중간에서 풀어야 하니까, 프록시의 CA 인증서를 컨테이너 런타임과 각 언어별 HTTP 클라이언트가 신뢰하도록 맞춰줘야 하거든요.

• 문제는 런타임마다 네트워크 설정을 받아들이는 방식이 다르다는 점이에요. curl이나 requests는 환경변수를 잘 따를 수 있지만, Playwright의 Chrome이나 aiohttp 기반 클라이언트처럼 별도 설정이 필요한 경우가 생겨요.

• 그래서 gVisor 같은 샌드박스 접근이 매력적으로 보이는 거예요. 애플리케이션이 프록시를 따르느냐와 상관없이, 네트워크 스택 레벨에서 나가는 요청을 잡으면 우회 경로를 줄일 수 있거든요.

• 다만 이것도 공짜는 아니에요. Kubernetes, GKE, 샌드박스 런타임, 네트워크 정책이 함께 맞물려야 해서 운영 복잡도가 올라가고, 문서와 생태계가 아직 완전히 편한 단계는 아닌 듯해요.