환경변수에 넣는 순간 샌 것이다: 에이전트 하네스 자격증명 브로커링 설계

샌드박스가 읽을 수 있으면, 새어나갈 수 있다

에이전트 하네스에 원본 API 키나 DB 자격증명을 환경변수로 그대로 주입하면, 모델이 그 값을 다음 프롬프트에 복제하거나 툴콜 인자·로그에 그대로 남길 길이 열립니다. 비인간·AI 아이덴티티 보안을 다루는 NHIMG의 2026년 6월 분석은 로테이션 주기를 아무리 줄여도 "에이전트가 컨텍스트 윈도우에서 시크릿을 읽을 수 있는 순간" 자체가 위험이라고 지목합니다. 값이 로그에 echo되거나 다음 툴콜로 복제되면, 로테이션이 돌기 전에 유출은 이미 끝나 있습니다.

저장과 접근을 나누는 하네스 설계

AWS Bedrock AgentCore Identity는 자격증명 저장과 접근을 분리하는 구조를 공식 문서에서 명시합니다. OAuth2 토큰·API 키·SigV4 서명을 워크로드 아이덴티티에 묶어 발급하고, 에이전트 런타임에는 원본 값이 아니라 그 워크로드에 한정된 핸들만 전달합니다. DigitalOcean의 Managed Agents 하네스 런타임도 비슷한 길을 택했습니다 — 시크릿을 "하나의 HTTPS 목적지"에 스코프해 암호화 저장하고, 샌드박스에는 단기 핸들만 주입합니다. 이 핸들은 API 응답이나 이벤트 스트림 어디에도 원문으로 나타나지 않습니다.

구축 로드맵과 함정: 자격증명 브로커를 하네스에 붙이는 법

(a) 기획 단계에서는 목표 수치를 코드보다 먼저 선언합니다. 신규 통합의 목적지별 스코프 적용률 100%, 발급 핸들의 TTL 10분 이내, 주간 로그 스캔에서 원본 시크릿 패턴 매치 0건을 출발선으로 둡니다. 스코프를 "에이전트 전체"가 아니라 "이 에이전트가 이 목적지로 보내는 요청"까지 좁혀야 하나의 핸들 유출이 전체 시스템으로 번지지 않습니다.

목표가 없으면 브로커 도입은 "키를 어딘가에 숨겼다"는 인상 평가로 끝납니다. 적용률과 TTL을 표로 고정해 두면 다음 통합부터는 같은 표에 수치만 채우면 됩니다.

(b) 실패 패턴은 대체로 두 갈래입니다. 첫째, 환경변수로 주입된 원본 값이 디버그 로그나 에러 스택에 그대로 찍히는 경로 — 마스킹 필터 없이 배포하면 발생 확률이 높습니다. 둘째, 목적지 스코프를 느슨하게 잡아 핸들이 의도하지 않은 호스트로도 통하는 경로입니다. 로테이션만 촘촘히 하는 대응은 이 두 경로를 막지 못합니다.

복구 분기는 유출 징후를 잡는 순간 시작됩니다. 핸들 하나가 비정상 목적지로 쓰인 로그가 보이면 그 핸들만 즉시 폐기하고, 같은 워크로드의 다른 핸들까지 번졌는지 감사 로그로 역추적합니다. 사람 승인이 필요한 break-glass 접근은 평시 발급 경로와 분리해 둬야 긴급 상황에서도 스코프 원칙이 무너지지 않습니다.

(c) 운영 체크리스트는 배포 전 시나리오 테스트로 시작합니다. 샘플 요청을 흘려 로그·에러 메시지에 원본 값이 찍히는지 정규식으로 스캔하고, 핸들 만료 후 실제로 거부되는지 확인합니다. 관측 필드에는 워크로드 ID·목적지 호스트·핸들 발급 시각·만료 시각을 반드시 남겨, 사고가 나도 어느 핸들이 어디로 쓰였는지 바로 추적되게 합니다.

(d) 개선 루프는 주 단위로 돌립니다. 그 주에 막힌 유출 시도와 오탐을 함께 리뷰하고, 스코프가 필요 이상으로 넓게 잡힌 통합을 찾아 좁힙니다. TTL이 더 짧아지는 방향으로 움직이는지, 새 통합이 들어올 때마다 스코프 적용률이 유지되는지를 그 자체로 하네스 품질 지표로 둡니다.

바로 쓰는 체크리스트

자격증명을 하네스에 넘기는 방식은 로테이션 주기보다 저장과 접근의 분리 여부가 먼저입니다. 목적지별 스코프 100%와 핸들 TTL 10분 이내를 합격선으로 걸고, 원본 값이 로그·에러 스택에 찍히는 경로를 배포 전 스캔으로 막은 뒤, 유출 징후가 보이면 해당 핸들만 즉시 폐기하는 분기를 갖추면 통합이 늘어도 같은 기준이 그대로 적용됩니다.

참고 링크

Manage credential providers with AgentCore Identity — AWS

Secrets and Configuration — DigitalOcean Agent Harness Runtime