에이전트에게 운영 환경 키를 줘도 될까? 이게 먹힐까?
Giving the agent keys to prod. Will this work?
핵심 요약
AI 에이전트의 운영 환경 접근 시 읽기/쓰기 권한을 분리하고, 쓰기 작업은 승인 과정을 거치게 하여 보안을 강화하려는 아이디어입니다.
- 권한 분리 — 읽기 전용과 쓰기 전용 서비스 계정을 나누어 에이전트의 위험 범위를 제한함.
- 승인 프로세스 — 쓰기 작업이 필요할 때만 관리자 승인을 거쳐 임시 컨테이너에서 명령을 실행함.
- 보안 가드레일 — 프롬프트 제어가 아닌 IAM과 프로세스 경계를 활용해 물리적인 안전장치를 마련함.
- 실효성 검증 — 실제 운영 환경에서 이 방식이 안전하고 효율적인지 커뮤니티에 피드백을 구함.
openclaw가 실제 클라우드 환경에서 gcloud나 aws 명령어를 실행하게 하고 싶어. 문제는 100% 신뢰할 수 없다는 거야. 에이전트가 나를 오해하면 사고를 칠 수 있거든. 그렇다고 명령어 하나하나 승인하는 건 너무 귀찮고.
아이디어: 자격 증명을 두 개의 서비스 계정으로 나누자.
TIER 1 · 읽기 전용 TIER 2 · 파괴적 작업
────────────────── ────────────────────
agent: gcloud list agent: gcloud rm
│ │
│ (승인 없음) ▼
│ 승인 [✓][✗]
│ │
▼ ▼
읽기 전용 키 쓰기 키
(컨테이너 내부) (컨테이너 내부)
│ │
▼ ▼
cloud · ok cloud · done
에이전트는 쓰기 키를 절대 가지고 있지 않아 — 사용 요청만 할 뿐.
읽기 전용 키는 에이전트가 자유롭게 사용해. 조회, 설명, 드라이런 같은 것들. 만약 이걸로 파괴적인 시도를 하면 클라우드에서 바로 403 에러를 뱉겠지.
쓰기 키는 에이전트가 가지고 있지 않아. 변경이 필요할 때만 정확한 명령을 요청해야 해. 그럼 내가 알림을 받고 승인하면, 키가 주입된 일회용 컨테이너에서 명령이 실행되는 방식이지. 에이전트 프로세스는 키를 절대 볼 수 없어.
즉, 가드레일은 '조심해'라고 말하는 프롬프트가 아니라 IAM과 프로세스 경계인 셈이야.
이거 실제로 잘 작동할까? 아니면 내가 놓치고 있는 뻔한 문제가 있을까?
