에이전트가 토큰을 호출하는 시대, 시크릿은 어떻게 둘 것인가

TL;DR
시크릿 관리의 진짜 결정은 매니저 선택이 아니라 권한 발급 단계에서 무엇을 좁히느냐입니다.
AI에게 검토를 위임할 때 가장 중요한 전제는 잘못된 명령 실행 차단입니다. read-only 계정 발급과 하네스 레벨 명령 차단을 두 단계로 두었습니다.
macOS 키체인 ACL을 호출 시점 의도 게이트로 두려 했으나 실측에서 해제했습니다. ACL은 도구 단위 신뢰 모델이라 권한 단위 차단의 대체재가 아닙니다.

위임에 이르기까지

처음에는 AI에게 맡기지 않고 직접 확인하며 한 단계씩 질문하는 방식으로 진행했습니다. 명령어 실행도 안전하고 결과 해석도 본인 손에 남는다는 점에서 자연스러운 선택이었습니다.

다만 그렇게 하니 시간이 많이 들었고 AI의 특성과도 잘 맞지 않았습니다. 분석을 맡기고 그 사이 다른 작업을 진행하는 멀티태스킹이 막혔습니다. 본인이 따라붙어 한 단계씩 확인하는 동안 다른 작업이 멈췄습니다.

그래서 검토 작업을 AI에게 위임하는 쪽으로 옮겼습니다. 위임에서 가장 중요한 전제는 잘못된 명령어가 실행되는 일을 막는 것입니다. 모든 운영 인프라가 권한 분리를 같은 수준으로 제공하지는 않아 권한만으로 닫히지 않는 구간이 남기 때문입니다.

이 전제 위에서 두 단계로 차단했습니다.

• 1차, AI 전용 read-only 계정 발급: 에이전트가 쓰는 토큰은 처음부터 조회 전용 계정에서 발급합니다. 운영 자원에 쓰기·운영 권한이 닿지 않습니다.
• 2차, 하네스 레벨 명령 차단: 권한 분리가 완전하지 않은 환경을 보강하기 위해 하네스에서 한 번 더 위험 명령을 거릅니다. 1차가 닫아주지 못한 틈을 도구 레벨에서 메웁니다.

이렇게 보완한 뒤 분석을 위임하니 검토를 맡긴 동안 다른 작업을 진행할 수 있게 되었습니다. 위임 경로에 들어가는 토큰의 영향 범위가 좁아 안심하고 맡길 수 있었습니다.

1차 방어선이 옮겨졌다

사람이 가끔 셸에서 호출하던 토큰을 이제 AI 에이전트가 자동화 흐름 안에서 매일 호출합니다. 사용자가 작업을 지시하고 에이전트가 헬퍼 도구를 거쳐 운영 API를 호출하는 구조입니다.

이 관계에서 1차 보안 방어선은 시크릿이 어디 저장되어 있느냐가 아닙니다. 시크릿 자체의 권한 범위입니다.

• 에이전트가 다루는 토큰은 운영 자원에 읽기만 가능합니다. 쓰기·운영 작업 권한은 없습니다.
• 쓰기·운영 작업은 에이전트 위임 대상이 아닙니다. 사람이 수동으로 별도 자격증명을 직접 입력해 수행합니다.
• 계정 권한으로 read-only를 원천 적용하면 토큰이 어디로 노출되든 유출(exfiltration) 후 악용 범위가 좁아집니다.

권한 위임과 작업 위임을 가른 것이 핵심입니다. 사용자가 에이전트에게 위임하는 것은 작업 수행이지 권한이 아닙니다. 그 위에서 시크릿 인프라(보관·배포 매체)는 2차 문제입니다.

ACL 실측에서 발견한 한계

설계 단계에서 사용 시점 확인을 추가 방어선으로 도입하려 했습니다. macOS 키체인 ACL -T ""를 적용하면 어떤 도구도 자동 신뢰되지 않으니 매번 OS 모달이 발화하는 점에서 후보였습니다.

가정은 다음과 같았습니다. 에이전트의 의도치 않은 호출(prompt injection 등)만 차단하고 사용자 명시 호출은 통과합니다.

실측에서 가정이 깨졌습니다.

• macOS 키체인 ACL은 호출 도구(security 바이너리) 단위 신뢰 모델입니다. 사용자가 의도해서 한 호출과 에이전트가 의도치 않게 한 호출을 OS는 구분하지 못합니다.
• 사용자 명시 정상 호출에도 OS 모달이 매번 발화합니다. 선택지는 거부, 허용, 항상 허용 세 가지입니다.
• “항상 허용” 클릭 시 security 바이너리가 ACL에 등록되어 사전 차단 효과가 즉시 사라집니다.

이 안은 “정상 흐름 차단”과 “ACL 무력화”라는 이중 함정으로 자동화 흐름과 충돌했고 결국 해제했습니다.

남은 인사이트가 글의 척추입니다.

ACL은 도구 단위 신뢰 모델이고, 의도 게이트는 시간·맥락 단위 정책입니다. 두 차원이 다릅니다.

OS는 “어떤 바이너리가 호출하느냐”는 압니다. 그러나 “그 호출이 사용자 의도인지 자동화 위임인지”는 모릅니다. 자동화 시대는 도구가 사용자 의도를 대행하는 시대이고 ACL은 이 위임을 표현하는 도구가 아닙니다.

따라서 의도 게이트는 OS가 아닌 도구 레벨에서만 만들 수 있습니다. 본인 환경에는 이미 하네스 레벨에서 위험 명령을 거르는 차단이 들어가 있습니다. 그 위에 호출 발신자 식별, 사용자 입력 타임스탬프 윈도우, 키 패턴별 정책 같은 헬퍼 차원 의도 게이트는 외부 비신뢰(untrusted) 컨텐츠 처리 영역이 작은 본인 환경에는 현재 도입하지 않았습니다.

방어선의 위계

이번 작업이 도착한 두 가지 사상입니다.

1. 권한 위계가 매니저 선택을 앞섭니다.

자동화 시대의 시크릿 관리는 위계가 있습니다.

단계	메커니즘	본인 적용
1차 (원천)	계정 권한 발급 단계의 범위 제한 (read-only)	적용 중
2차	시크릿 인프라 (보관·배포 매체)	협업 도구 개인 영역(원본) + 키체인(캐시) 2단
3차 (보강)	도구 레벨 의도 게이트	하네스 명령 차단 적용 중, 추가 정책은 외부 도구 사용 확장 시

OS 키체인 ACL은 위계의 어느 자리도 아닌 보조 게이트입니다. 1차가 약하면 ACL이 메워주지 못하고 1차가 단단하면 ACL은 불필요합니다. 매니저 비교가 표면이고 사상이 아닌 이유가 여기 있습니다.

2. 권한 위임과 작업 위임은 다릅니다.

사용자가 에이전트에게 위임은 작업 수행에 한정되며 권한은 아닙니다. 이 모델 위에서 시크릿 인프라의 평문 수용 폭이 결정됩니다. read-only 토큰은 노출되어도 악용 범위가 좁고 본인 전용 영역의 평문은 본인 신뢰 모델 안에서 수용 가능합니다. 반대로 쓰기 권한 토큰을 같은 자리에 두면 평문 수용 폭은 즉시 좁아집니다.

이 두 사상이 매니저 비교를 표면 결정으로 만들고 권한 위계를 본질 결정으로 끌어올립니다.

결정한 구성

본인은 협업 도구 개인 영역(원본)과 macOS 키체인(캐시) 2단을 선택했습니다. 부트스트랩 토큰 한 줄을 키체인에 두면 새 디바이스에서도 1분 안에 모든 토큰을 복원합니다. 무료이고 외부 매니저 의존이 없으며 본인 전용 가시성입니다. 1차 방어선(read-only 권한)이 단단해서 평문 수용도 가능했습니다.

이 결정 자체는 본인 환경에 맞춘 결과일 뿐입니다. 핵심은 그 위에 깔려 있는 위계이지 이 구성 자체가 아닙니다.

---

보안 면책

이 글의 결정은 본인 환경(토큰 권한이 read-only로 좁혀져 있음, 본인 전용 개인 영역, 외부 비신뢰 도구 사용 영역이 작음)에 맞춘 결과입니다. 토큰 권한 범위가 다르거나(쓰기·운영 권한 포함) 협업 도구 가시성이 다른 환경에서는 평문 수용 폭이 달라집니다. 자기 환경 기준으로 권한 위계와 신뢰 모델을 점검한 뒤 채택하시기 바랍니다.

이 글은 Claude와 함께 작업했습니다.