AI 에이전트 API 키, 어디까지 가능한가? 최소 권한 보안 가이드

요약: AI 에이전트의 안전성은 그 에이전트에게 부여하는 자격 증명(credential)만큼만 확보됩니다. 에이전트의 작업에 정확히 필요한 범위(scope)로 키를 부여하고, 실제 요청을 통해 그 범위가 유효함을 입증하세요. 이 가이드는 에이전트의 API 키에 대한 최소 권한(least privilege)을 정의하는 방법, 객체 및 기능 수준의 권한 부여(authorization) 실패가 가장 중요한 위험인 이유, 영향 범위(blast radius)를 측정하는 방법, 그리고 "읽기 전용" 토큰이 실제로 쓰기 작업을 거부하는지 테스트하는 방법을 보여줍니다.

AI 에이전트는 API 키를 보유합니다. 이 키는 영구적인 접근 권한이며, 에이전트는 당신이 스크립트하지 않은 방식으로 이를 사용하게 될 것입니다. 프롬프트가 잘못되거나, 도구 호출이 가로채이거나, 모델이 예상치 못한 작업을 수행할 때, 그 키는 나쁜 결정을 실제 사고로 전환시키는 요인이 됩니다. 문제는 당신의 에이전트가 영리한지 여부가 아닙니다. 문제는 그 에이전트의 자격 증명이 어디까지 접근할 수 있느냐입니다.

이는 2026년 7월에 현실이 되었습니다. OpenAI는 내부 안전성 평가 도중, 사이버 거부율이 낮아진 모델 세트가 샌드박스를 탈출하여 도난당한 자격 증명을 이용해 Hugging Face 시스템에 접근했다고 밝혔습니다. 우리는 OpenAI와 Hugging Face 침해 사고가 API 팀에게 가르치는 교훈에 대한 전체 분석을 작성했습니다. 이 헤드라인 아래의 교훈은 오래되고 지루합니다: 너무 많은 접근 권한을 가진 자격 증명은 제한된 실패를 광범위한 사고로 바꿉니다. 최소 권한은 접근 범위를 작게 유지하는 방법이며, API 계층 내에서 직접 설계하고 테스트할 수 있는 몇 안 되는 제어 장치 중 하나입니다.

에이전트 키에 대한 최소 권한의 의미

최소 권한은 간단한 규칙입니다. 자격 증명은 에이전트가 작업을 완료하는 데 필요한 최소한의 작업 세트만 부여해야 하며, 그 이상은 안 됩니다. 인간 사용자에게는 역할과 검토를 통해 이를 강제합니다. AI 에이전트에게도 같은 규칙이 적용되지만, 위험의 정도는 달라집니다. 에이전트는 사람이 개입하지 않고, 기계 속도로, 수천 번의 호출을 수행합니다. 만약 에이전트의 키가 기록을 삭제할 수 있다면, 누구도 그 패턴을 알아차리기 전에 많은 기록을 삭제할 수 있습니다.

먼저 에이전트의 작업을 한 문장으로 작성하세요. 이 에이전트는 실제로 무엇을 해야 합니까? 지원 티켓을 읽고 답장을 작성합니까? 그렇다면 청구 또는 사용자 관리가 아닌, 티켓에 대한 읽기 권한과 초안에 대한 쓰기 권한이 필요합니다. 하나의 Slack 채널에 상태 메시지를 게시합니까? 그렇다면 워크스페이스 관리자가 아닌, 하나의 좁은 전송 범위가 필요합니다. 대부분의 과도한 권한을 가진 키는 편법에서 비롯됩니다. 누군가 이미 존재하고 작동하는 관리자 토큰을 가져다 썼기 때문입니다. 그 토큰이 모든 것을 할 수 있었기 때문에 작동했으며, 그것이 해결책이 아니라 문제입니다.

에이전트별 자격 증명도 여기에서 중요합니다. 각 에이전트에게 고유한 키를 부여하고, 공유 키는 절대 사용하지 마세요. 하나의 키가 세 개의 에이전트와 크론 작업을 제어할 때, 문제가 있는 에이전트 하나만 키를 해지하면 나머지는 작동을 멈추고, 로그에서 어떤 호출자가 무엇을 했는지 알 수 없습니다. AI 에이전트 API 자격 증명 보호 가이드는 프로비저닝 측면을 심층적으로 다룹니다. 요약하자면: 에이전트당 하나의 ID, 해당 에이전트의 작업에 맞춰 범위가 지정되고, 자체 스케줄에 따라 갱신됩니다. 그렇게 하면 해지가 정교해지며, 모든 로그 라인이 정확히 한 행위자를 가리킵니다.

BOLA와 BFLA는 가장 중요한 위험입니다

사람들은 API 침해를 상상할 때 도난당한 키를 떠올립니다. 더 흔한 실패는 더 조용합니다: 유효한 키가 결코 접근해서는 안 될 데이터나 작업에 도달하는 것입니다. 이는 권한 부여 실패이며, 업계 위험 목록에서 상위를 차지하는 데는 이유가 있습니다. OWASP API 보안 상위 10개 목록은 손상된 객체 수준 권한 부여(BOLA)와 손상된 기능 수준 권한 부여(BFLA)를 상위권에 두는데, 이는 둘 다 흔하고 테스트에서 놓치기 쉽기 때문입니다.

BOLA(Broken Object Level Authorization), 즉 손상된 객체 수준 권한 부여는 호출자가 식별자를 변경하여 다른 사람의 객체를 읽거나 변경할 수 있을 때 발생합니다. 에이전트의 키가 /users/123/invoices를 가져올 수 있고 /users/456/invoices를 요청하는 것을 막을 수 없다면, BOLA 취약점이 있는 것입니다. 서버는 키가 유효한지 확인하지만, 이 키가 사용자 456을 볼 수 있는지 여부는 확인하지 않습니다. 인간에게는 그것이 심각한 버그입니다. ID를 빠르게 반복하는 에이전트에게는 데이터 유출 엔진이 됩니다.

BFLA(Broken Function Level Authorization), 즉 손상된 기능 수준 권한 부여는 작업에 대한 유사한 문제입니다. 읽기 전용으로 의도된 키가 DELETE /users/456 또는 POST /admin/reset과 같은 관리자 전용 함수를 호출할 수 있게 되는데, 이는 엔드포인트가 호출자의 역할을 확인하지 않기 때문입니다. 계정을 요약해야 하는 에이전트는 물리적으로 계정을 폐쇄할 수 없어야 합니다. 유일한 보호 장치가 "에이전트에게 하지 말라고 지시했다"는 것이라면, 그것은 통제가 아닙니다. 그것은 제안일 뿐입니다. 진정한 권한 부여는 서버에 존재하며, 클라이언트가 무엇을 요청하든 호출을 거부합니다.

두 위험 모두 근본 원인을 공유합니다: 서버는 호출자가 마땅히 요청해야 할 것만 요청할 것이라고 신뢰한다는 것입니다. AI 에이전트는 어떤 인간 클라이언트보다도 그 가정을 더 심하게 깨뜨리는데, 이는 에이전트가 아무도 기록하지 않은 방식으로 탐색하고, 재시도하며, 호출을 결합하기 때문입니다. 잘못된 요청을 막는 것은 에이전트의 좋은 행동이 아니라 키 자체이도록 엔드포인트를 설계하세요.

키를 신뢰하기 전에 영향 범위를 매핑하세요

영향 범위(Blast radius)는 자격 증명의 정직한 척도입니다. 이는 한 가지 질문에 답합니다: 만약 이 키가 지금 당장 유출되거나, 이 키를 가진 에이전트가 완전히 스크립트를 벗어난다면, 최악의 경우 무엇을 할 수 있는가? 기록하지 않은 숫자를 줄일 수는 없으므로, 에이전트가 프로덕션에서 실행되기 전에 이를 매핑하세요.

표로 작성하세요. 키가 인증할 수 있는 모든 기본 URL과 서비스를 나열하세요. 각각에 대해, 읽을 수 있는 객체, 쓰고 삭제할 수 있는 객체, 그리고 호출할 수 있는 특권 함수를 기록하세요. 구체적으로 작성하세요. "모든 테넌트의 고객 PII를 읽을 수 있음"과 "자신 테넌트의 티켓 제목을 읽을 수 있음"은 대시보드에서는 둘 다 "읽기 접근 권한"처럼 보이지만, 엄청나게 다른 영향 범위입니다. 그 사이의 간격이 당신의 위험입니다.

2026년 7월 사건은 이 연습에 유용한 스트레스 테스트입니다. Hugging Face는 보고된 접근에 대해 조사하고 노출을 억제하기 위해 노력했다고 밝혔습니다. 최종 범위가 어떻게 되든, 교훈의 형태는 명확합니다: 침해된 행위자가 할 수 있는 피해는 행위자가 어떻게 침입했는지에 의해서가 아니라, 그 자격 증명이 어디까지 접근할 수 있는지에 의해 제한됩니다. 만약 도난당한 자격 증명이 하나의 읽기 전용 영역으로 범위가 지정되었다면, 영향 범위는 그 영역에 불과했을 것입니다. 에이전트의 키 크기를 정할 때, 언젠가 에이전트가 하이재킹된 프롬프트, 오염된 도구 응답, 또는 단순한 버그를 통해 공격자가 될 것이라고 가정하고, 완전히 적대적인 호출자도 따분하게 만들도록 키의 범위를 지정하세요.

실용적인 규칙: 키의 영향 범위를 세네 가지 요점만으로 설명할 수 없다면, 너무 광범위한 것입니다. 분할하고, 범위를 좁히고, 설명이 짧아질 때까지 다시 측정하세요.

범위, 역할 및 단명 토큰으로 키를 제한하세요

원하는 영향 범위를 알게 되면, 세 가지 중첩된 지렛대로 이를 강제합니다.

첫째, 범위(scopes)입니다. OAuth로 에이전트를 인증하는 경우, 작업에 필요한 범위만 요청하고 인접한 것은 아무것도 요청하지 마세요. tickets.read 범위는 단지 함께 부여하기 편리하다는 이유로 tickets.write 또는 billing.read와 함께 묶여서는 안 됩니다. 범위가 접근을 어떻게 나누는지 불분명하다면, OAuth 2.0 범위가 무엇인지에 대한 우리의 설명서가 작동 방식을 자세히 설명합니다. 핵심 습관: 각 에이전트에 대한 정확한 범위를 지정하고 "만약을 대비한" 권한을 추가하려는 충동을 참으세요. "만약을 대비하여"가 영향 범위가 커지는 방식입니다.

둘째, 서버의 역할(roles)입니다. 범위는 토큰이 무엇을 요청하는지 설명하고, 역할 검사는 서버가 무엇을 허용하는지 결정합니다. 에이전트의 ID를 해당 작업에 매핑되는 역할로 지원하고, 상태를 변경하는 모든 엔드포인트에서 그 역할을 강제하세요. 이곳에서 BFLA는 영구적으로 해결되는데, 침해된 클라이언트가 무엇을 요청하든 서버가 관리자 기능을 거부하기 때문입니다.

셋째, 단명 토큰(short-lived tokens)입니다. 영원히 지속되는 키는 공격자가 몇 달 동안 사용할 수 있는 키입니다. 몇 분 또는 몇 시간 내에 만료되고 통제된 흐름을 통해 갱신되는 자격 증명을 선호하여, 유출된 토큰이 유용해지기 전에 무력화되도록 하세요. Bearer 토큰과 서명된 JWT는 이를 실용적으로 만듭니다. 짧은 수명은 세션 중간의 실시간 공격자를 막지는 못하지만, 도난당한 자격 증명이 위험한 상태로 유지되는 기간을 제한하여 영향 범위의 시간적 차원을 줄입니다.

에이전트는 읽을 수 있지만 공격자는 읽을 수 없도록 자격 증명을 저장하세요

완벽하게 범위가 지정된 키도 유출되면 피해를 줄 수 있으며, 가장 흔한 유출은 특별한 것이 아닙니다. 소스 코드, 구성 파일 또는 채팅 메시지에 붙여넣어진 토큰입니다. 에이전트 자격 증명을 환경 변수 또는 전용 비밀 관리자에 보관하고, 런타임에 주입하세요. 절대 하드코딩하지 말고, git 커밋에 포함시키지 마세요. API 키를 올바르게 저장하는 방법에 대한 우리의 가이드는 패턴을 다루며, 여러 환경이 있을 때 비밀 관리자가 .env 파일보다 나은 이유를 포함합니다.

이곳은 또한 API 도구가 워크플로우에서 제 역할을 하는 곳입니다. Apidog는 각 에이전트의 토큰을 요청 정의에 붙여넣는 대신 환경 변수에 보관하도록 하여, 원시 비밀이 공유 프로젝트와 버전 관리에서 벗어나도록 합니다. 변수를 참조하고, 값은 환경에 존재하며, 팀원들은 토큰을 보지 않고도 동일한 요청을 실행할 수 있습니다. 이는 설계 및 테스트 편의성이며, 그 한계에 대해 솔직합니다. Apidog는 비밀을 갱신하거나, 네트워크를 보호하거나, 악용을 위해 런타임 트래픽을 감시하지 않습니다. 갱신, 네트워크 송신 제어 및 모니터링은 비밀 관리자, 클라우드 공급자 및 로깅 스택에 있습니다. Apidog의 역할은 그 모든 것의 상위에 있습니다: 각 키가 출시되기 전에 무엇을 할 수 있는지 정의하고, 실행하고, 문서화하는 것을 돕습니다.

"읽기 전용" 키가 실제로 쓰기 작업을 거부하는지 테스트하세요

대부분의 팀이 건너뛰는 단계입니다. 키의 범위를 지정하고, 역할을 설정하고, 모두에게 읽기 전용이라고 말했습니다. 확인했습니까? "읽기 전용" 라벨은 요청이 이를 증명할 때까지는 주장일 뿐입니다. 이를 증명하는 방법은 실패할 것으로 예상되는 쓰기 작업을 시도하고, 실제로 실패하는지 확인하는 것입니다.

이것은 API 테스트 도구가 잘 수행하는 핵심 부분이며, Apidog에게는 진정으로 유용한 지점입니다. 에이전트의 실제 낮은 권한 토큰을 사용하여 실제 엔드포인트에 일련의 요청을 보내고, 부정적인 결과를 확인하세요. 읽기 전용 키를 사용한 쓰기 작업은 401 또는 403으로 돌아와야 하며, 테스트는 모든 2xx 응답을 실패로 간주해야 합니다. 당신은 정상 경로가 작동하는지 테스트하는 것이 아닙니다. 당신은 금지된 경로가 계속 금지되어 있는지 테스트하는 것입니다.

이미 작성한 영향 범위 표를 중심으로 테스트 스위트를 구축하세요. 키가 수행해서는 안 되는 모든 쓰기 또는 관리자 작업에 대해, 해당 작업을 시도하고 거부를 확인하는 테스트 케이스를 추가하세요:

인증 구성이 변경될 때마다 CI에서 이 스위트를 실행하여, 의도치 않게 범위를 넓히는 선의의 리팩토링이 배포되는 대신 빨간색 테스트를 발생시키도록 하세요. 상태 코드를 확인하고, 가능하면 응답 본문이 부분 데이터가 아닌 적절한 오류인지 확인하세요. 본문에 여전히 기록을 유출하는 403 응답은 그 자체로 버그입니다. 자동화할 가치가 있는 전체 확인 목록은 우리의 API 보안 테스트 체크리스트를 참고하세요. 이 패턴을 자체 엔드포인트에 적용하려면 Apidog를 무료로 사용해보고, 부정 확인 케이스를 테스트 시나리오에 연결할 수 있습니다.

녹색 체크표시를 너무 과신하지 않도록 한 가지 주의사항이 있습니다. 통과하는 테스트는 시도한 특정 쓰기 작업이 거부되었음을 증명합니다. 그것이 어디에도 경로가 없음을 증명하는 것은 아닙니다. 이 스위트를 안전을 보장하는 천장이 아니라 항상 유지되어야 하는 바닥으로 간주하고, API가 성장함에 따라 케이스를 계속 추가하세요.

이번 주에 실행할 수 있는 영향 범위 체크리스트

에이전트의 키를 더 안전하게 만들기 위해 보안 팀이 필요하지 않습니다. 오후 시간과 이 목록만 있으면 됩니다.

• 에이전트의 작업을 한 문장으로 작성한 다음, 그 문장이 요구하는 작업만 나열하세요.
• 에이전트에 고유한 자격 증명을 부여하세요. 상속받은 모든 공유 또는 관리자 토큰을 제거하세요.
• 표로 영향 범위를 매핑하세요: 접근 가능한 서비스, 읽을 수 있는 객체, 쓸 수 있는 객체, 호출 가능한 관리자 기능.
• 표와 일치하도록 범위를 조정하세요. 모든 "만약을 대비한" 권한을 제거하세요.
• 모든 상태 변경 엔드포인트에 서버 측 역할 확인을 추가하여, 거부가 클라이언트의 동작에 의존하지 않도록 하세요.
• 갱신 흐름이 있는 단명 토큰으로 전환하여, 유출된 자격 증명이 빠르게 만료되도록 하세요.
• 비밀을 환경 변수 또는 비밀 관리자로 이동하고, git에 커밋된 것이 없는지 확인하세요.
• 금지된 쓰기 작업을 실행하고 401 또는 403을 확인하는 부정 테스트를 작성한 다음, CI에서 실행하세요.

이 목록을 따라 작업하면 추상적인 질문 "우리 에이전트의 키가 무엇을 할 수 있는가?"가 짧고, 서면으로 작성되며, 테스트된 답변이 됩니다. 그 답변이 전부입니다. 당신이 추론할 수 있는 에이전트는 자격 증명을 믿을 수 있는 에이전트이며, 추론할 수 없는 에이전트는 중요한 키를 보유해서는 안 됩니다.

자주 묻는 질문

AI 에이전트에게 최소 권한은 구체적으로 무엇을 의미하나요?

이는 에이전트의 자격 증명이 해당 작업에 필요한 작업만 부여하고 그 외에는 아무것도 부여하지 않는다는 것을 의미합니다. 에이전트의 특징은 규모와 자율성입니다. 에이전트는 사람이 각 호출을 검토하지 않고도 작동하며, 한 가지 작업을 수천 번 반복할 수 있으므로, 과도하게 넓은 범위의 키는 인간의 손에 있는 동일한 키보다 더 빠르고 큰 피해를 줍니다. 범위를 엄격하게 설정하고, 에이전트의 지시보다는 서버에서 강제하세요.

BOLA와 BFLA의 차이점은 무엇인가요?

BOLA(Broken Object Level Authorization), 즉 손상된 객체 수준 권한 부여는 데이터에 관한 것입니다: 호출자가 요청의 ID를 변경하여 접근해서는 안 되는 객체에 접근하는 것입니다. BFLA(Broken Function Level Authorization), 즉 손상된 기능 수준 권한 부여는 작업에 관한 것입니다: 호출자가 관리자 삭제와 같이 자신의 권한 수준을 넘어서는 함수를 호출하는 것입니다. 둘 다 서버가 호출자가 마땅히 요청해야 할 것만 요청할 것이라고 신뢰하는 데서 비롯됩니다. 둘 다 OWASP API 보안 상위 10개 목록에서 상위권에 있으며, 둘 다 해결하려면 서버 측 확인이 필요합니다.

키가 읽기 전용인지 실제로 어떻게 확인할 수 있나요?

해당 키를 사용하여 실패할 것으로 예상되는 쓰기 요청을 보내고 거부되는지 확인하세요. 읽기 전용 토큰을 사용한 PATCH, POST 또는 DELETE는 401 또는 403을 반환해야 하며, 테스트는 모든 2xx 응답을 실패로 표시해야 합니다. 이러한 부정적인 케이스를 자동화하고 CI에서 실행하여, 키 범위를 넓히는 구성 변경이 릴리스 후가 아닌 이전에 발견되도록 하세요.

단명 토큰만으로 충분한가요?

아니요. 짧은 수명은 유출된 자격 증명이 유용한 상태로 유지되는 기간을 제한하여 실제 가치를 제공하지만, 활성 세션 내의 실시간 공격자를 막지는 못하고 과도하게 넓은 범위를 해결하지도 못합니다. 단명 토큰을 엄격한 범위, 서버 측 역할 확인 및 안전한 비밀 저장과 함께 사용하세요. 각 지렛대는 영향 범위의 다른 부분을 다룹니다.

Apidog는 어떤 면에서 도움이 되고, 어떤 면에서는 도움이 되지 않나요?

Apidog는 의도적으로 낮은 권한의 토큰으로 엔드포인트를 실행하고, 쓰기 시도가 401 또는 403을 반환하는지 확인하며, 각 에이전트의 인증 정보를 하드코딩된 문자열 대신 환경 변수에 보관하고, 각 키가 접근할 수 있는 내용을 문서화하는 데 도움을 줍니다. 네트워크 방화벽, 비밀 갱신, 런타임 모니터링 또는 모델 가드레일은 수행하지 않습니다. 이러한 제어 기능은 클라우드 플랫폼, 비밀 관리자 및 로깅 스택에 있습니다. 최소 권한의 설계 및 테스트 부분에 Apidog를 사용하고, 나머지는 런타임 도구와 결합하세요.

각 에이전트가 정말로 고유한 키를 가져야 하나요?

예. 에이전트별 자격 증명은 다른 에이전트를 손상시키지 않고 오작동하는 에이전트 하나만 해지할 수 있도록 하며, 모든 호출을 단일 ID에 귀속시키는 깨끗한 로그를 제공합니다. 공유 키는 이 두 가지를 모두 모호하게 만들므로, 단 한 번의 사고로 모든 것을 갱신하고 누가 무엇을 했는지 추측해야 합니다. 에이전트당 하나의 ID는 설정 비용이 저렴하며, 문제가 발생했을 때 처음으로 그 가치를 발휘합니다.