Agent Security
AI 에이전트에게 API 키를 직접 주는 방식은 생각보다 위험합니다. 에이전트는 API, CLI, SDK, MCP를 넘나들며 작업하지만, 동시에 프롬프트 인젝션과 비결정적 실행에 노출됩니다. 핵심은 단순합니다. 에이전트가 서비스를 호출하게 하되, 비밀키 자체는 보지 못하게 해야 합니다.
문제
비밀키 유출
패턴
Credential Brokering
구현
Egress Proxy
Overview
에이전트 보안은 프롬프트 문제가 아니다
많은 팀이 에이전트 보안을 “위험한 답변을 막는 문제”로 봅니다. 하지만 실제 제품에서는 더 직접적인 문제가 먼저 나옵니다. 에이전트가 업무를 하려면 외부 시스템을 호출해야 하고, 외부 시스템을 호출하려면 자격 증명이 필요합니다.
그런데 에이전트는 전통적인 서버 코드처럼 고정된 경로로만 움직이지 않습니다. 사용자 입력, 도구 응답, 웹 페이지, 파일 내용을 읽고 다음 행동을 정합니다. 이 구조에서는 프롬프트 인젝션이 곧 도구 권한 문제로 이어집니다.
Core Idea
키를 주지 말고 요청만 중개한다
Hacker News에서 논의된 Agent Vault의 핵심은 credential brokering입니다. 에이전트에게 실제 API 키나 장기 토큰을 넘기지 않고, 프록시가 대신 자격 증명을 붙여 요청을 전달합니다. 에이전트는 서비스를 쓸 수 있지만 비밀값은 읽지 못합니다.
구현 방식은 egress proxy에 가깝습니다. 에이전트 실행 환경의 HTTPS_PROXY를 프록시로 향하게 만들고, 프록시가 요청을 검사한 뒤 필요한 인증을 붙입니다. API, CLI, SDK, MCP처럼 호출 방식이 달라도 네트워크 계층에서 통제할 수 있다는 점이 장점입니다.
Why It Matters
“키를 모른다”는 속성은 강하다
스코프가 좁은 키라도 에이전트가 값을 읽을 수 있으면 유출 가능성이 남습니다. 반대로 키를 전혀 보지 못하면 장기 자격 증명을 빼내 재사용하는 경로가 사라집니다. 보안 사고의 형태가 달라집니다. 키 유출 사고가 아니라, 제한된 프록시 요청 남용 문제로 바뀝니다.
이 차이는 운영에서 큽니다. 프록시 토큰을 짧게 만들고, 실행 단위로 발급하고, 네트워크 정책과 감사 로그를 붙이면 통제 지점이 생깁니다. 모델을 더 믿는 것이 아니라, 모델이 볼 수 있는 권한의 실체를 줄이는 방식입니다.
Limits
하지만 데이터 유출까지 해결하진 않는다
credential exfiltration과 data exfiltration은 다릅니다. 에이전트가 비밀키를 훔치지 못해도, 허용된 프록시를 통해 민감 데이터를 읽고 외부로 보낼 수 있습니다. 그래서 credential brokering은 전체 보안이 아니라 계층형 방어의 한 조각입니다.
- 프록시는 공개 인터넷에 노출하지 않는다.
- 에이전트 실행 환경 가까이에 두고, 접근 토큰은 짧게 만든다.
- 허용 도메인, 메서드, 인증 방식을 정책으로 선언한다.
- sandbox, 파일 접근 제한, egress policy, 감사 로그를 함께 둔다.
Takeaway
에이전트 시대의 보안 단위가 바뀌고 있다
좋은 에이전트 시스템은 프롬프트만 잘 쓰는 시스템이 아닙니다. 도구 권한, 네트워크, 자격 증명, 실행 격리, 감사 가능성을 함께 설계한 시스템입니다. Agent Vault는 아직 연구 프리뷰 성격이 강하지만, 방향은 분명합니다. 에이전트에게 권한을 주되, 비밀키는 주지 않는 것.
Thread Draft
쓰레드용 요약
1/ AI 에이전트에게 API 키를 직접 주는 방식은 위험합니다. 문제는 모델이 똑똑한가가 아니라, 모델이 외부 시스템을 호출할 권한을 갖는다는 점입니다.
2/ 에이전트는 API, CLI, SDK, MCP를 넘나들며 작업합니다. 그런데 동시에 프롬프트 인젝션과 비결정적 실행에 노출됩니다.
3/ 그래서 중요한 패턴이 credential brokering입니다. 에이전트에게 키를 주지 않고, 프록시가 대신 인증을 붙여 요청을 전달합니다.
4/ 에이전트는 서비스를 쓸 수 있지만 비밀값은 읽지 못합니다. “스코프가 좁은 키”보다 “키를 아예 모르는 구조”가 더 강합니다.
5/ 구현은 egress proxy에 가깝습니다. HTTPS_PROXY로 트래픽을 프록시에 보내고, 프록시가 요청을 검사한 뒤 필요한 인증을 붙입니다.
6/ 단, 이건 데이터 유출까지 해결하진 않습니다. credential exfiltration과 data exfiltration은 다른 문제입니다.
7/ 그래서 sandbox, 네트워크 egress 제한, 짧은 프록시 토큰, 감사 로그가 같이 필요합니다.
8/ 결론: 에이전트 보안은 프롬프트 문제가 아니라 운영 아키텍처 문제입니다. 에이전트에게 권한을 주되, 비밀키는 주지 않는 구조가 필요합니다.
Reference
참고한 논의
Hacker News의 “Show HN: Agent Vault – Open-source credential proxy and vault for agents” 논의를 출발점으로 삼았습니다. 핵심 쟁점은 credential brokering, HTTPS_PROXY 기반 egress proxy, 프록시 접근 토큰, credential exfiltration과 data exfiltration의 구분입니다.