핵심 요점
- 아이덴티티 및 접근 관리는 브라우저 앞에서 MFA와 SSO를 수행하는 사람을 전제로 구축되었습니다 — 상시 자격 증명을 보유하고 기계 속도로 작동하는 자율 에이전트는 예외가 아니라 구조적으로 이 전제를 깨뜨립니다.
- 위협 모델에는 과도한 권한의 서비스 계정, 에이전트 설정에 내장된 장기 API 키, 권한 있는 작업으로 확대되는 프롬프트 인젝션, 그리고 세 번째 홉에 이르면 아무도 원래 승인자를 추적할 수 없게 되는 에이전트 간 위임 체인이 포함됩니다.
- 비인간 아이덴티티(에이전트, 서비스 계정, 워크로드 아이덴티티)는 대부분의 기업 환경에서 이미 인간 아이덴티티 수를 큰 폭으로 초과하고 있습니다 — 이는 업계에서 널리 관찰되는 패턴이며, 이 글이 인용하는 특정 통계 수치는 아닙니다.
- 실제로 유지되는 통제: 단기적이고 순환되는 자격 증명, 완전한 감사 추적을 갖춘 에이전트당 하나의 아이덴티티, 되돌릴 수 없는 작업에 한정된 사람의 승인, 아웃바운드 제어, 명시적인 도구 허용 목록.
- 자체 호스팅 모델은 제3자 유출 위험을 제거하고 데이터를 내부에 유지하지만, 프롬프트 인젝션, 과도한 권한의 자격 증명, 감사 추적 부재라는 더 큰 위험은 해결하지 못합니다.
- 어떤 법역도 아직 에이전틱 AI 아이덴티티를 전담하는 법률을 갖고 있지 않습니다 — 현재로서는 주로 엔지니어링과 아키텍처의 문제이며 규제 준수의 문제가 아니지만, EU 금융 서비스와 핵심 인프라 배포는 여러 규제 체계가 겹치며 발생하는 실질적 압박에 직면해 있습니다(지역별 법적 현황 참조).
응답하는 AI에서 행동하는 AI로의 전환
아이덴티티 및 접근 관리는 특정한 절차를 중심으로 설계되었습니다: 사람이 브라우저 앞에 앉아 MFA나 SSO로 자신의 신원을 증명하면, 그 증명에 연결된 범위가 세션에 부여됩니다. LLM 에이전트는 이 절차의 모든 요소를 동시에 깨뜨립니다 — 각 작업마다 키보드 앞에 사람이 있는 것이 아니며, "세션"은 감독 없이 몇 시간 또는 며칠 동안 실행될 수 있고, 에이전트가 보유한 자격 증명은 흔히 설정 시점에 한 번 정해진 후 다시는 검토되지 않습니다.
이것은 같은 문제의 축소판이 아닙니다. 질문에 답하는 챗봇은 무언가를 변경할 상시 접근 권한이 없습니다. 반면 티켓을 읽고, 데이터베이스 레코드를 작성하고, 세 개의 내부 API를 호출하고, 구성 변경을 배포하는 에이전트는 그 각 단계마다 인가 결정을 내리고 있습니다 — 그리고 사람의 세션을 위해 구축된 IAM 도구에는 "이 결정은 5분 전 지시에 반응한 모델이 내린 것이지, 사람이 내린 것이 아니다"라는 개념 자체가 존재하지 않습니다.
실무적인 결과: IAM 프로그램이 사람을 위해 10년에 걸쳐 구축해온 접근 검토 주기, 민감한 작업에 대한 MFA 단계적 강화, 그리고 "누가 이 일을 했는가"를 밝히는 감사 추적은, 플랫폼 팀이 이번 분기에 배포하고 있는 에이전트에게는 대부분 아직 존재하지 않습니다.
📍 한 문장으로
아이덴티티 및 접근 관리는 사람이 각 세션 전에 브라우저에서 신원을 증명한다고 전제합니다. 상시 자격 증명을 보유하고 기계 속도로 작동하는 자율 에이전트는 예외가 아니라 구조적으로 이 전제를 깨뜨립니다.
💬 쉽게 말하면
IAM은 "방금 로그인한 사람이 맞는 사람인가?"라는 질문에 답하기 위해 만들어졌습니다. AI 에이전트는 사람처럼 로그인하지 않습니다 — 자격 증명을 지속적으로 보유하고 아무도 재확인하지 않은 채 그에 따라 행동합니다. 이는 IAM 도구가 대비하지 못한 다른 종류의 문제입니다.
위협 모델, 구체적으로
에이전트가 쓰기 권한을 얻었을 때 실제 노출의 대부분은 다섯 가지 실패 패턴으로 설명됩니다. 이들은 서로 결합됩니다 — 과도한 권한의 자격 증명에 감사 추적 부재가 더해지면 통제 가능했던 사고가 추적 불가능한 사고로 바뀝니다.
💬 쉽게 말하면
대부분의 에이전트 보안 사고는 한 번의 극적인 실패가 아닙니다 — 과도한 권한의 자격 증명, 고정 키, 감사 추적 부재가 동시에 존재하여, 단 하나의 삽입된 지시가 추적 불가능한 권한 있는 작업으로 발전할 여지를 만들어냅니다.
- 1과도한 권한의 서비스 계정.
Why it matters: 티켓 시스템의 필드 하나만 업데이트하도록 만들어진 에이전트에 더 좁은 권한의 계정을 별도로 프로비저닝하는 데 드는 수고를 피하기 위해, 이미 다른 곳에서 사용 중인 동일한 광범위한 서비스 계정 자격 증명이 부여되는 경우가 많습니다. 그 결과 에이전트는 작업에 필요한 것보다 훨씬 많은 접근 권한을 갖게 되고, 에이전트가 수행하는 모든 작업은 그 계정의 전체 블라스트 반경을 물려받습니다. - 2에이전트 설정에 내장된 장기 API 키.
Why it matters: 설정 파일이나 환경 변수에 저장된 고정 키는 만료되지 않고 순환되지 않습니다 — 에이전트 프레임워크가 자체 프롬프트를 로깅하거나 디버깅 엔드포인트를 통해 키가 유출될 경우, 단기 토큰이 제공하는 것과 같이 피해 시간을 제한하는 내장 메커니즘이 없습니다. - 3권한 있는 작업으로 확대되는 프롬프트 인젝션.
Why it matters: 웹페이지, 이메일, 지원 티켓, 공유 드라이브의 문서 등 작업의 일부로 외부 콘텐츠를 읽는 에이전트는 공격자가 그 콘텐츠에 삽입한 지시를 접할 수 있습니다. 에이전트가 "운영자의 지시"와 "읽도록 요청받은 텍스트"를 신뢰성 있게 구분하지 못하면, 검색된 콘텐츠에 숨겨진 지시가 에이전트를 의도된 범위 밖의 작업으로 유도할 수 있습니다 — 이는 보안 아키텍트가 설계로 방어해야 할 메커니즘이지, 재현할 페이로드가 아닙니다. - 4추적 불가능한 에이전트 간 위임 체인.
Why it matters: 에이전트 A가 에이전트 B를 호출하고, B는 하위 작업을 완료하기 위해 에이전트 C를 호출합니다. 세 번째 홉에 이르면 사용 중인 자격 증명, 원래 작업, 최상위 요청을 승인한 사람이 함께 전달되지 않는 경우가 많습니다 — 세 번째 홉의 감사 로그는 누가 승인했는지 재구성할 수 없는 작업을 보여줍니다. - 5도구 호출 및 MCP 표면이 공격 표면이 되는 문제.
Why it matters: Model Context Protocol(MCP) 및 유사한 도구 호출 인터페이스는 새 도구가 연결될 때마다 에이전트가 도달할 수 있는 범위를 확장합니다. 추가되는 각 도구는 이제 에이전트의 자격 증명이 커버하는 새로운 기능이며, 악의적이거나 손상된 도구 서버가 콘텐츠를 반환하여 에이전트가 이를 신뢰할 수 없는 데이터가 아닌 신뢰할 수 있는 지시로 취급하게 만드는 새로운 지점이기도 합니다.
기존 IAM이 이를 다루지 못하는 이유
SSO와 MFA는 접근 순간에 사람이 존재함을 증명하도록 설계되었습니다 — 자율 에이전트는 그러한 의미에서 결코 "존재"하지 않으므로, 검증 모델 전체가 애초에 에이전트에 적용되지 않습니다. 에이전트는 비인간 아이덴티티(NHI)입니다: 세션마다 한 번 인증하는 대신 지속적으로 행동하는 서비스 계정, 워크로드 아이덴티티, 또는 API 자격 증명입니다.
비인간 아이덴티티는 대부분의 기업 환경에서 이미 인간 아이덴티티 수를 큰 폭으로 초과하고 있습니다 — 이는 보안 벤더와 실무자 조사 전반에서 널리 보고되는 패턴이며, 이 글이 인용하는 단일 측정치가 아니고 비율은 조직마다 다릅니다. 이러한 보고에서 일관된 것은 방향성입니다: NHI 수는 수년간 서비스 계정과 자동화에 의해 주로 견인되며 인간 인력보다 더 빠르게 증가해 왔고, 에이전틱 AI는 이제 이 추세 안에서 가장 빠르게 성장하는 범주입니다.
대부분의 기업 IAM 프로그램은 여전히 인간 온보딩보다 더 가볍고 검토가 적은 프로세스를 통해 NHI 프로비저닝을 진행합니다 — 신입 직원은 접근 검토, 관리자 승인, 예정된 재인증을 거치지만, 새로운 서비스 계정이나 에이전트 자격 증명은 이 세 가지 중 어느 것도 거치지 않는 경우가 흔합니다. 이러한 격차는 NHI가 대부분 좁은 범위의 정적 스크립트였을 때는 용인될 수 있었습니다. 그러나 NHI가 도구 호출을 연쇄시키고 모호한 지시를 해석하며 프로비저닝한 사람이 사전에 명시적으로 나열하지 않은 작업을 수행할 수 있는 에이전트라면 더 이상 용인될 수 없습니다.
📍 한 문장으로
SSO와 MFA는 접근 순간에 사람이 존재하는지 검증합니다. 상시 자격 증명을 가진 자율 에이전트는 그러한 의미에서 결코 존재하지 않습니다 — 그래서 더 강력한 사람 인증이 아니라 비인간 아이덴티티 거버넌스가 진짜 공백입니다.
에이전트 블라스트 반경 계산기
특정 에이전트 배포를 다섯 가지 차원에서 평가하여 블라스트 반경 등급과 그에 맞는 최소 권한 권장 사항을 확인하십시오. 이는 전적으로 브라우저 내에서 실행됩니다 — 어떤 데이터도 전송되지 않습니다.
Agent Blast-Radius Calculator
Answer 5 questions about one agent deployment to get a blast-radius risk tier and a matched least-privilege recommendation. Nothing is sent anywhere — scoring runs entirely in your browser.
1. What is the agent's capability scope?
2. What is the credential lifetime the agent uses?
3. How reversible are the agent's actions?
4. Does a human-in-the-loop approval gate exist for high-impact actions?
5. Is there an audit trail with attribution to an authorizing human?
실제로 작동하는 통제
여섯 가지 통제가 에이전트 블라스트 반경의 실질적인 감소 대부분을 설명합니다. 어느 것도 단독으로는 충분하지 않습니다 — 위협 모델의 실패 패턴과 마찬가지로 서로 결합됩니다.
단기적이고 순환되는 자격 증명
- 하는 일:
- 고정 API 키를 자동으로 만료되고 순환되는 워크로드 아이덴티티나 토큰으로 대체합니다.
- 유지되는 이유:
- 유출되거나 오용된 자격 증명의 유효 기간이 무한하지 않고 제한됩니다.
에이전트당 하나의 아이덴티티
- 하는 일:
- 여러 에이전트나 사람과 서비스 계정을 공유하는 대신 각 에이전트에 고유한 자격 증명을 부여합니다.
- 유지되는 이유:
- 사고를 미분화된 풀이 아니라 한 에이전트의 작업으로 추적할 수 있고, 범위를 최소공배수가 아니라 에이전트별로 조정할 수 있습니다.
되돌릴 수 없는 작업에만 사람의 승인
- 하는 일:
- 에이전트의 모든 작업이 아니라 깔끔하게 되돌릴 수 없는 작업에 한해 사람의 검토를 요구합니다.
- 유지되는 이유:
- 모든 것을 승인 대상으로 하면 자동화의 목적이 무의미해지고 검토자가 읽지 않고 승인하도록 훈련시킵니다. 되돌릴 수 없는 작업만 대상으로 하면 검토가 의미를 유지합니다.
아웃바운드 제어
- 하는 일:
- 에이전트가 자신의 작업에 필요하다고 판단하는 것과 무관하게, 네트워크 수준에서 에이전트 프로세스가 도달할 수 있는 외부 엔드포인트를 제한합니다.
- 유지되는 이유:
- 네트워크 자체가 연결을 허용하지 않으면 손상되거나 조작된 에이전트는 데이터를 유출하거나 임의의 외부 서비스를 호출할 수 없습니다.
도구 허용 목록
- 하는 일:
- 개방형 도구 탐색 대신 명시적으로 열거된 호출 가능 도구 집합으로 에이전트를 제한합니다.
- 유지되는 이유:
- 손상된 서버에서 MCP를 통해 접근하는 도구를 포함하여, 목록에 없는 새로운 또는 검토되지 않은 도구는 삽입된 지시가 무엇을 요청하든 호출될 수 없습니다.
샌드박스 실행
- 하는 일:
- 호스트 시스템과 분리된, 자체 리소스 및 권한 경계를 가진 격리된 환경 안에서 에이전트의 작업을 실행합니다.
- 유지되는 이유:
- 실제로 실행되는 작업의 피해를 억제합니다 — 샌드박스 탈출은 공유 환경 안에서 작업이 성공하는 것과는 별개의, 더 어려운 문제입니다.
승인 권한자까지 추적할 수 있는 완전한 감사 추적 귀속은 별도의 항목이 아니라 위 여섯 가지 통제 전체를 관통합니다 — 이것이 없으면 이 통제들 중 어느 것도 사후에 추적 가능한 기록을 만들어내지 못합니다.
로컬 및 자체 호스팅 모델이 해결하는 것과 해결하지 못하는 것
에이전트의 모델을 자체 호스팅 인프라에서 실행하면 제3자 유출 위험이 제거되고 프롬프트와 출력이 조직 자체 네트워크 안에 유지됩니다 — 하지만 이 글의 주제인 아이덴티티 및 접근 문제는 해결되지 않습니다. 이 구분이 흐려지면 보안에 정통한 독자는 이 가이드의 나머지 부분을 신뢰하지 않을 것이므로, 명확히 밝힐 가치가 있습니다.
로컬 배포는 프롬프트 인젝션을 해결하지 못합니다. 인젝션은 애플리케이션 계층과 아키텍처의 문제입니다 — 에이전트가 신뢰할 수 있는 지시와 신뢰할 수 없는 검색 콘텐츠를 어떻게 구분하는가 — 그리고 기본 모델이 벤더 API에서 실행되든 조직 소유 하드웨어에서 실행되든 동일합니다. 모델을 내부로 가져온다고 해서 에이전트가 읽도록 요청받은 웹페이지나 문서를 처리하는 방식이 달라지지는 않습니다.
로컬 배포는 과도한 권한의 자격 증명을 해결하지 못합니다. 과도한 권한의 서비스 계정을 호출하는 자체 호스팅 모델은 동일한 계정을 호출하는 벤더 호스팅 모델과 정확히 같은 정도로 위험합니다 — 자격 증명 범위는 모델 가중치가 어디서 실행되는지가 아니라 에이전트 접근 설계의 속성입니다.
로컬 배포는 감사 추적 부재를 해결하지 못합니다. 추론이 임대한 API에서 실행되든 자체 소유 GPU에서 실행되든, 작업이 이를 승인한 사람까지 귀속되어 기록되는지 여부와는 무관합니다. 이는 별도로 결정되는 로깅 및 아이덴티티 아키텍처 결정입니다.
이러한 맥락에서 로컬 배포가 실제로 유용한 부분은 프롬프트와 도구 출력의 내용을 제3자 인프라 밖에 유지하는 것입니다. 이는 데이터 레지던시와 제3자 리스크에 중요하지만, 에이전트 보안 태세를 구성하는 하나의 요소일 뿐 위에서 설명한 아이덴티티 및 접근 통제를 대체하지는 못합니다.
💬 쉽게 말하면
자체 모델을 내부에서 실행하는 것은 "우리의 프롬프트와 데이터가 우리 인프라를 벗어난다"는 문제를 해결합니다. 프롬프트 인젝션, 과도한 권한의 자격 증명, 감사 추적 부재는 해결하지 못합니다 — 이는 모델이 벤더 API에서 실행되든 자체 하드웨어에서 실행되든 동일하게 존재하는 아이덴티티 및 아키텍처 문제입니다.
지역별 법적 현황
한국에서는 2026년 발효된 AI 기본법이 위험 기반 접근 방식을 적용하고 있으며, PIPA(개인정보 보호법) 개정을 통해 AI 관련 데이터 보호를 강화하고 있습니다. MSIT(과학기술정보통신부)가 AI 기본법에 따라 일반적인 AI 시스템 안전과 신뢰성을 관장하고, PIPC(개인정보보호위원회)는 PIPA에 따라 AI 시스템 내 개인정보 처리를 계속 감독하는 이원적 규제 구조가 유지되고 있습니다. 규제 당국은 에이전트가 다른 에이전트, 외부 서비스, 도구와 상호작용할 때 반복적인 동의에 의존하는 방식의 한계와 책임 소재를 어떻게 구조화할 것인가라는 문제를 이미 공개적으로 지적했지만, 서비스 계정이나 비인간 아이덴티티에 특화된 별도의 규정은 이 글 작성 시점 기준으로 아직 존재하지 않습니다.
즉, 한국은 에이전트가 야기하는 책임 소재 문제를 규제 당국 차원에서 인지하고 논의를 시작한 단계이지만, 이 글에서 다루는 자격 증명 범위나 감사 추적처럼 구체적인 기술적 요구 사항으로 이어지는 전용 규정은 아직 마련되어 있지 않습니다. 이는 어떤 법역도 에이전틱 AI를 아직 따라잡지 못했다는 이 글 전체의 논지와 일치합니다.
이 절은 일반적인 정보 제공이며 법률 자문이 아닙니다 — 접근 아키텍처를 확정하기 전에 자사의 업종과 구체적인 배포 내용에 대해 전문가와 상담하시기 바랍니다.
자주 묻는 질문
에이전틱 AI 보안이란 무엇입니까?
에이전틱 AI 보안은 상시 자격 증명을 보유하고 작업을 수행할 수 있는 자율 AI 에이전트를 관장하는 아이덴티티, 접근, 모니터링 통제의 집합입니다 — 질문에만 답하는 챗봇과는 다릅니다. 핵심은 각 에이전트를 설정한 사람의 연장이 아니라, 자체적으로 범위가 제한된 자격 증명, 감사 추적, 승인 게이트를 가진 비인간 아이덴티티로 취급하는 것입니다.
에이전틱 AI 보안은 전통적인 아이덴티티 및 접근 관리와 어떻게 다릅니까?
전통적인 IAM은 각 세션 전에 사람이 MFA나 SSO를 통해 신원을 증명한다고 전제합니다. 에이전트는 상시 자격 증명을 보유하고 작업마다 재인증 없이 기계 속도로 지속적으로 작동하므로, SSO와 MFA의 핵심인 사람의 존재라는 전제가 에이전트에는 적용되지 않습니다 — 이 공백은 비인간 아이덴티티 거버넌스로 메워야 합니다.
AI 에이전트에 쓰기 권한을 부여할 때 가장 큰 보안 위험은 무엇입니까?
과도한 권한의 자격 증명과 감사 추적 부재의 조합이 가장 큰 위험입니다. 이는 프롬프트 인젝션, 잘못 구성된 도구 호출, 위임 체인 등 단일 사고를, 통제 가능하고 추적 가능한 사건에서 블라스트 반경이 무제한이고 누가 무엇을 승인했는지 재구성할 방법이 없는 사건으로 바꾸어 놓습니다.
프롬프트 인젝션은 어떻게 권한 있는 작업으로 이어집니까?
작업의 일부로 웹페이지, 문서, 지원 티켓 등 외부 콘텐츠를 읽는 에이전트는 공격자가 그 콘텐츠에 삽입한 지시를 접할 수 있습니다. 에이전트가 "운영자의 지시"와 "처리하도록 요청받은 텍스트"를 신뢰성 있게 구분하지 못하면, 숨겨진 지시가 에이전트를 의도된 범위 밖의 작업으로 유도할 수 있습니다. 해결책은 아키텍처적인 것입니다 — 도구 허용 목록, 범위가 제한된 자격 증명, 되돌릴 수 없는 작업에 대한 사람의 승인 — 프롬프트를 더 잘 작성하는 것만으로는 부족합니다.
비인간 아이덴티티(NHI)란 무엇이며 AI 에이전트에게 왜 중요합니까?
비인간 아이덴티티는 사람이 아닌, 자격 증명을 보유한 모든 주체입니다 — 서비스 계정, 워크로드 아이덴티티, API 키, AI 에이전트 등입니다. NHI는 대부분의 기업 환경에서 이미 인간 아이덴티티 수를 큰 폭으로 초과하고 있으며, 이는 업계에서 널리 관찰되는 패턴입니다. 대부분의 IAM 프로그램은 인간 온보딩보다 더 가벼운 프로세스로 NHI 프로비저닝을 처리하는데, NHI가 스스로 작업을 연쇄시킬 수 있는 에이전트일 때 이 격차는 훨씬 더 중요해집니다.
에이전트의 모든 작업에 사람의 승인이 필요해야 합니까?
아닙니다. 모든 작업에 승인을 요구하면 자동화의 목적이 무의미해지고 검토자가 읽지 않고 승인하도록 훈련됩니다. 실제로 유지되는 통제는 깔끔하게 되돌릴 수 없는 작업, 즉 되돌릴 수 없는 작업에 한해 승인을 요구하는 것이며, 영향이 작고 되돌릴 수 있는 작업은 사람 개입 없이 진행됩니다.
로컬 또는 자체 호스팅 모델을 실행하면 에이전틱 AI 보안 위험이 해결됩니까?
아닙니다, 그것만으로는 해결되지 않습니다. 자체 호스팅 모델은 제3자 유출 위험을 제거하고 데이터를 내부에 유지하지만, 프롬프트 인젝션, 과도한 권한의 자격 증명, 감사 추적 부재는 해결하지 못합니다 — 이는 모델이 어디서 실행되든 동일하게 존재하는 아이덴티티 및 아키텍처 문제입니다.
AI 에이전트는 어떤 자격 증명 유효 기간을 사용해야 합니까?
장기 고정 API 키가 아니라 자동으로 순환되는 단기 자격 증명이나 워크로드 아이덴티티를 사용해야 합니다. 에이전트 설정에 내장된 고정 키는 유출 시 피해 시간을 제한하는 내장 메커니즘이 없지만, 단기 자격 증명은 설계상 이 시간을 제한합니다.
에이전트 간 위임 체인은 어떻게 위험을 만듭니까?
에이전트 A가 에이전트 B를 호출하고 B가 하위 작업을 완료하기 위해 에이전트 C를 호출할 때, 사용 중인 자격 증명, 원래 작업, 최상위 요청을 승인한 사람이 각 홉을 거치며 함께 전달되지 않는 경우가 많습니다. 세 번째 홉에 이르면 감사 로그는 누가 승인했는지 재구성할 수 없는 작업을 보여줄 수 있습니다 — 해결책은 인가 컨텍스트가 자동으로 이어진다고 가정하는 대신, 위임 체인이 인가 컨텍스트를 명시적으로 전달하도록 설계하는 것입니다.