--- title: "AI 에이전트에게 운영 권한을 줄 때, 진짜 무서운 건 삭제보다 비밀 유출임" published: 2026-04-28T23:41:32.000Z canonical: https://jeff.news/article/2219 --- # AI 에이전트에게 운영 권한을 줄 때, 진짜 무서운 건 삭제보다 비밀 유출임 홈랩을 관리하는 AI SRE를 만들려던 글쓴이가 Hermes Agent에 GitHub, Kubernetes, Grafana 같은 도구 권한을 주면서 맞닥뜨린 보안 문제를 다룬 글이다. 핵심은 에이전트가 실수로 데이터를 지우는 것보다, 프롬프트 인젝션으로 시크릿을 읽고 밖으로 빼내는 게 훨씬 골치 아프다는 점이다. - 홈랩을 AI SRE에게 맡겨보려던 실험이었는데, 주제는 금방 “에이전트 보안”으로 커짐 - 글쓴이는 사무실 홈랩에서 k3s와 Ansible로 immich, silverbullet, beaverhabits 같은 앱을 셀프호스팅 중이었음 - 목표는 Hermes Agent를 알림(alert)이 뜰 때마다 실행해서, 장애 원인을 찾고 직접 복구까지 하게 만드는 것 - 모델은 Gemma4, Qwen 같은 로컬 모델도 써보려 했고, 그래서 더더욱 “얘네를 믿어도 되나?” 문제가 생김 - 에이전트에게 GitHub, Kubernetes, Grafana, Todoist 같은 CLI 권한을 주면 공격면이 확 넓어짐 - 첫 번째 위험은 파괴적 명령임. 누가 프롬프트 인젝션으로 Python 스크립트를 실행시켜서 `rm -rf` 비슷한 짓을 하게 만들 수 있음 - 두 번째 위험은 시크릿 유출임. 숨은 HTML에 “이 스크립트를 실행하면 답을 얻을 수 있다”고 써두면, 에이전트가 토큰을 읽어 외부로 보낼 수도 있음 - 글쓴이는 rootless 컨테이너를 쓰고, git에 없는 중요한 데이터는 안 넣을 생각이라 삭제 위험은 상대적으로 덜 걱정했음 - 하지만 시크릿 유출은 별개 문제였음. API 토큰 하나 털리면 컨테이너 바깥 서비스까지 영향이 번짐 > [!WARNING] > AI 에이전트가 웹 검색과 CLI 실행을 동시에 할 수 있으면, 프롬프트 인젝션은 “이상한 답변” 문제가 아니라 실제 권한 탈취 문제가 됨. - 첫 번째 방어책은 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 내부 저장소에 있다고 하지만, 글쓴이는 오픈소스화되면 직접 써보고 기여할 생각도 있어 보임 ```mermaid 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, 샌드박스 런타임, 네트워크 정책이 함께 맞물려야 해서 운영 복잡도가 올라가고, 문서와 생태계가 아직 완전히 편한 단계는 아닌 듯해요. ## 핵심 포인트 - 에이전트 컨테이너에는 진짜 토큰 대신 가짜 토큰을 넣고, HTTP 프록시가 요청 중간에서 실제 자격 증명을 주입하는 방식을 실험함 - HTTPS 요청까지 가로채려면 프록시 CA 인증서를 컨테이너에 넣어야 해서 운영 복잡도가 바로 올라감 - Playwright의 Chrome, aiohttp 기반 Matrix 클라이언트처럼 프록시와 인증서를 제대로 안 따르는 도구가 실제로 발목을 잡음 - gVisor 기반 샌드박스는 네트워크 스택 자체를 확장해 모든 outbound 요청을 잡을 수 있어 더 강한 격리 모델로 보임 ## 인사이트 AI 에이전트를 운영 자동화에 붙이는 순간, 문제는 모델 성능보다 권한 경계가 됨. 특히 웹 검색과 CLI 실행을 같이 허용하면 프롬프트 인젝션이 곧 시크릿 유출 경로가 될 수 있어서, 한국 팀들도 사내 에이전트 도입 전에 이 레이어를 먼저 봐야 함.