AI 에이전트에게 상시 API 키를 제공하는 것을 중단하세요
요약
AI 에이전트에게 수명이 긴 상시 API 키를 제공하는 보안 위험성을 경고하고, 이를 해결하기 위한 최소 권한 원칙과 브로커 패턴을 제안합니다. 에이전트의 동작 특성을 고려하여 대상, 작업, 리소스, 수명, 비율을 제한하는 범위 지정 자격 증명 사용을 권장합니다.
핵심 포인트
- 상시 API 키는 프롬프트 인젝션 및 유출 시 막대한 피해를 초래함
- 에이전트의 빠른 동작 속도와 확산성 때문에 보안 위험이 더 큼
- 대상, 작업, 리소스, 수명, 비율을 제한하는 범위 지정 자격 증명 필요
- 모델이 비밀 정보를 직접 보지 못하게 하는 브로커 패턴 도입 권장
AI 에이전트들이 실제 API를 대상으로 티켓 접수, 자금 이동, 기록 업데이트, 다른 에이전트 호출 등 실제 업무를 수행하기 시작했습니다. 여기에 도달하는 가장 빠른 방법은 가장 위험한 방법이기도 합니다. 바로 수명이 긴 API 키를 에이전트의 환경에 붙여넣고 실행하는 것입니다. 그 키는 이제 상시적인 부채(standing liability)가 됩니다. 해당 키는 만료되는 경우가 거의 없고, 대개 작업에 필요한 것보다 훨씬 더 넓은 범위(scope)를 가지고 있으며, 로그, 프롬프트, 또는 침해된 도구로부터 유출되는 순간 공격자는 에이전트가 할 수 있는 모든 권한을 상속받게 됩니다.
해결책은 "키를 더 조심해서 사용하라"가 아닙니다. 에이전트에게 상시 키(standing keys)를 발급하는 것 자체를 중단하는 것입니다.
비인간 정체성(non-human identities)을 위한 최소 권한 원칙
우리는 수십 년 동안 사람에게 최소 권한(least privilege)을 적용하는 관행을 쌓아왔습니다. 하지만 에이전트는 상시 자격 증명(standing credentials)을 특히 위험하게 만드는 세 가지 면에서 다릅니다:
- 빠르고 무인으로 동작합니다. 오용된 인간의 자격 증명은 누군가 알아차리기 전까지 몇 분 동안 피해를 줄 수 있습니다. 하지만 에이전트 루프(agent loop)는 누군가 확인하기 전에 수천 번의 호출을 수행할 수 있습니다.
- 지침(instructions)이 공격자에게 도달 가능합니다. 프롬프트 인젝션(Prompt injection)은 자격 증명을 어떻게 사용할지 결정하는 주체가 신뢰할 수 없는 입력에 의해 조종될 수 있음을 의미합니다.
- 확산(fan out)됩니다. 하나의 에이전트가 다른 에이전트를 호출하고, 그것이 도구를 호출하며, 다시 API를 호출합니다. 권한 범위(Scope)는 공유된 비밀(shared secret)에 머무는 것이 아니라 요청과 함께 이동해야 합니다.
따라서 에이전트의 액세스 단위는 운영 환경(production) 키의 복사본이 아니라, 특정 작업을 위해 발행된 수명이 짧고 범위가 좁게 설정된 자격 증명이어야 합니다.
"범위가 지정된(scoped)" 것이 실제로 의미하는 바
유용한 범위 지정 자격 증명은 여러 차원을 동시에 고정합니다:
- 대상(Audience) — 어떤 업스트림 API 또는 MCP 서버에 유효한지.
- 작업(Operations) — 어떤 메서드나 도구를 사용할지 (예: 읽기는 가능하지만 쓰기는 불가).
- 리소스(Resources) — 어떤 엔드포인트, 경로 또는 객체 ID를 사용할지.
- 수명(Lifetime) — 몇 달이 아닌 몇 분 단위. 스스로 만료됩니다.
- 비율(Rate) — 일정 시간당 호출 횟수의 상한선을 두어, 폭주하는 루프(runaway loop)를 제어합니다.
실제로 권한 부여(grant)는 다음과 같은 형태를 띱니다:
{
"audience": "api.github.com",
"operations": ["GET"],
...
이 다섯 가지 조건이 모두 엄격하게 적용된다면, 유출된 자격 증명(credential)의 가치는 매우 낮아집니다. 유출 즉시 작동이 중단되며, 아주 작은 문 하나만을 열 수 있을 뿐입니다.
브로커 패턴 (The broker pattern)
이를 구현하는 가장 깔끔한 방법은 에이전트(agent)와 비밀 정보(secret) 사이에 위치하는 자격 증명 브로커(credential broker)를 두는 것입니다. 모델은 실제 비밀 정보를 절대 보지 못합니다. 대신 다음과 같이 동작합니다:
- 에이전트가 브로커에게 특정 작업 수행을 요청합니다 (종종 MCP 도구를 통해 수행됨).
- 브로커는 정책을 확인합니다: 이 주체(principal)가 지금, 제한된 범위 내에서 이 작업을 수행할 권한이 있는가?
- 허용된다면, 브로커는 호출 시점(edge)에서 실제 자격 증명을 주입하고, 호출을 수행한 뒤 결과를 반환합니다.
- 모든 단계는 기록됩니다.
비밀 정보가 호출 시점에 해결(resolve)되며 모델에 전달되지 않기 때문에, 단 하나의 에이전트도 건드리지 않고 자격 증명을 교체(rotate)하거나 취소(revoke)할 수 있습니다. 또한 브로커는 모든 에이전트 호출이 통과하는 유일한 지점이므로, 권한 범위(scope)를 강제하고 감사 추적(audit trail)을 캡처하기에 가장 자연스러운 장소입니다.
실질적인 마이그레이션 경로
- 인벤토리(Inventory) 작성: 현재 에이전트가 보유하고 있는 키들을 파악하세요. 수명이 길고 권한이 광범위한 것들이 우선순위 대상입니다.
- 비밀 정보를 브로커 뒤로 이동: 에이전트 내부의 키를 브로커가 해결하는 참조(reference)로 교체하세요.
- 작업별로 권한 범위 축소: 처음에는 허용적으로 시작하되, 감사 로그(audit log)에 나타난 에이전트의 실제 필요 사항을 바탕으로 권한을 단계적으로 줄여나가세요.
- 수명 단축: 발급이 자동화되면, 만료(expiry) 처리는 비용이 들지 않게 됩니다.
최종 상태: 에이전트는 영구적인 비밀 정보를 보유하지 않으며, 모든 자격 증명은 특정 목적을 위해 생성되고 스스로 만료됩니다. 또한 추측하는 대신 정책을 읽음으로써 "이 에이전트가 무엇을 할 수 있는가?"라는 질문에 답할 수 있게 됩니다. 최소 권한 원칙(Least privilege)은 언제나 목표였습니다. 범위가 제한되고 수명이 짧은 자격 증명은 에이전트가 기본적으로 이 원칙을 준수하게 만드는 방법입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기