에이전트에게 셸 접근 권한을 줄 때 보안 정보(secrets)는 어떻게 관리하시나요?
How are you handling secrets when an agent has shell access?
핵심 요약
에이전트가 셸에 접근할 때 보안 정보가 유출되는 문제를 해결하기 위한 로컬 도구와 보안 아키텍처에 대한 논의입니다.
- 보안 정보 유출 — 에이전트가 환경 변수나 설정 파일을 읽어 대화창에 노출하는 문제 발생
- 로컬 보안 도구 — KeePassXC와 같은 로컬 볼트를 활용해 보안 정보를 격리하고 주입하는 방식
- 보안 아키텍처 — 에이전트가 직접 보안 정보를 다루지 않고 브로커를 통해 단기 권한을 부여받는 방식
- 현실적 한계 — 로컬 환경에서 에이전트가 사용자와 동일한 권한으로 실행될 때 발생하는 보안 경계의 모호함
Claude Code가 내 설정을 알아내려고 cat .env를 실행하는 걸 지켜봤음. 뭐 그럴 수 있지 — 하지만 내 API 키들은 이제 누군가의 서버에 있는 대화 기록에 남게 됐음.
기존 도구들은 키보드 앞에 사람이 있다고 가정함. 그 가정은 더 이상 유효하지 않아서, 지금 우리가 일하는 방식에 맞는 작은 오픈 소스 도구를 만들었음.
보안 정보는 레포 밖의 KeePassXC 볼트에 저장됨:
`kdbx run -- npm test`
이 방식은 보안 정보를 자식 프로세스에 주입하고 아무것도 출력하지 않음. 에이전트는 자격 증명이 필요한 작업을 실행할 수 있지만, 정보를 쓰거나, 드러내거나, 내보내는 건 내 통제하에 있음.
이건 실수를 막는 거지 공격을 막는 게 아님 — 키 파일을 읽을 수 있는 거라면 무엇이든 볼트를 열 수 있음.
처음에 고려했던 것들:
- 1Password / Doppler / Infisical — 서비스형; 나는 로컬 및 오프라인 방식을 원했음
- sops / age — 레포 안의 암호화된 설정에는 좋지만, 나는 레포 밖을 원했음
- direnv + gitignored
.env— 여전히 디스크에 평문으로 존재함 - pass — 가장 비슷하지만, 프로젝트별 레이아웃이 없음


