AI Agent 보안에서 Prompt Injection보다 먼저 봐야 할 것

"우리 에이전트는 Prompt Injection 방어가 되어 있나요?" AI Agent 보안 회의에서 가장 먼저 나오는 질문이다. 좋은 질문이지만, 순서가 틀렸다. 공격자가 프롬프트를 조작해 에이전트를 속이는 데 성공했다고 해도, 그 에이전트가 할 수 있는 일이 읽기 전용 조회뿐이라면 피해는 제한적이다. 반대로 프롬프트 방어가 완벽해도 에이전트가 프로덕션 DB에 쓰기 권한을 들고 있고 호출 기록이 어디에도 남지 않는다면, 그 시스템은 이미 위험하다.

요약

Prompt Injection은 AI Agent 보안의 입구일 뿐 전부가 아니다. 공격이 성공한 뒤 실제 피해 규모를 결정하는 것은 에이전트가 가진 도구 권한, 신원 설계, 데이터 경계, 그리고 감사 로그다. 2025년 12월 공개된 OWASP Top 10 for Agentic Applications도 프롬프트 조작보다 도구 오용과 권한 남용을 더 비중 있게 다룬다. 이 글은 인프라 운영자가 에이전트 보안을 검토할 때 먼저 봐야 할 네 가지를 정리한다.

이 글이 필요한 사람

AI Agent를 프로덕션에 올리려는 DevOps 엔지니어, 클라우드 보안 담당자, 플랫폼 팀에게 유용하다. LLM 모델 자체보다 에이전트가 외부 시스템과 연결되는 지점이 걱정되는 사람을 위한 글이다.

왜 지금 이 주제인가

2025년 12월, OWASP는 100명 이상의 보안 전문가가 참여하고 NIST, Microsoft, NVIDIA가 검토에 기여한 'OWASP Top 10 for Agentic Applications 2026'을 공개했다. 자율 AI 에이전트만을 대상으로 한 첫 동료 검토 프레임워크다.

여기서 눈여겨볼 점이 있다. 우리가 흔히 'Prompt Injection'이라 부르는 위협은 이 목록에서 ASI01(Agent Goal Hijack), 즉 에이전트의 목표를 탈취하는 항목으로 한 칸을 차지할 뿐이다. 바로 다음 두 자리는 ASI02(Tool Misuse, 도구 오용)와 ASI03(Identity and Privilege Abuse, 신원·권한 남용)이 차지한다. 프레임워크 설계자들은 ASI01~ASI03을 "목표, 도구, 신원"이라는 하나의 묶음으로 본다. 프롬프트만 막으면 끝이 아니라는 신호다.

이유는 단순하다. 일반 LLM 챗봇은 잘못 대답해도 텍스트 한 줄로 끝난다. 그러나 AI Agent는 도구를 호출하고, 외부 API를 부르고, 시스템을 바꾼다. 같은 프롬프트 조작이라도 에이전트에서는 실제 행동으로 이어진다. 그래서 방어의 무게중심도 "속지 않게 만들기"에서 "속아도 큰일이 안 나게 만들기"로 옮겨가야 한다.

1. 도구 권한: 에이전트가 할 수 있는 일의 범위

가장 먼저 봐야 할 것은 에이전트에 연결된 도구 하나하나가 무엇을 할 수 있는가다.

많은 팀이 에이전트에게 도구를 붙일 때 권한을 넉넉하게 준다. 개발 단계에서 권한 때문에 막히는 게 번거롭기 때문이다. 그 결과 조회만 하면 되는 에이전트가 쓰기 권한까지 들고 있거나, 하나의 도구 자격증명이 여러 시스템에 통째로 접근하는 구조가 만들어진다. OWASP가 ASI02에서 지적하는 "과도한 권한을 가진 도구(over-privileged tool)"가 바로 이것이다.

원칙은 도구 단위 최소 권한이다. 에이전트 전체가 아니라 도구 하나하나에 대해 "이 도구는 무엇을, 어디까지, 어떤 데이터에 대해 할 수 있는가"를 정의해야 한다. OWASP는 이를 도구별 프로파일(per-tool profile)로 분리할 것을 권한다.

특히 위험한 것은 되돌릴 수 없는 행동이다. 결제, 권한 부여, 리소스 삭제, 외부로 나가는 메시지 전송 같은 작업은 에이전트가 단독으로 실행하게 두면 안 된다. 이런 고위험 행동에는 사람의 승인(approval flow)을 한 단계 끼워 넣는 것이 기본이다.

2. 신원: 누구의 권한으로 행동하는가

두 번째는 에이전트가 행동할 때 어떤 자격증명을 쓰는가다.

에이전트는 두 가지 방식으로 행동한다. 사용자를 대신해서 행동하거나(위임), 에이전트 자신의 권한으로 행동한다(서비스 신원). 이 둘이 흐릿하게 섞이면 권한 추적이 무너진다. 사용자 A가 시작한 작업을 에이전트가 관리자 권한으로 실행해버리는 상황이 대표적이다. OWASP ASI03가 다루는 신원·권한 남용이 여기서 발생한다.

운영 관점에서 챙겨야 할 것은 세 가지다. 에이전트에게 별도 신원을 부여하고, 그 신원에 최소 권한만 매핑하고, 토큰의 수명을 짧게 가져가는 것이다. 오래 사는 광범위한 토큰 하나가 에이전트 손에 들어가는 순간, 프롬프트 한 줄로 그 토큰 범위 전체가 위험해진다.

3. 데이터 경계: 무엇을 보고, 무엇을 내보내는가

세 번째는 에이전트가 접근하는 데이터의 경계다.

에이전트는 검색(RAG), 메모리, 도구 응답을 통해 다양한 데이터를 끌어온다. 문제는 입력과 출력 양쪽에서 생긴다. 입력 쪽에서는 신뢰할 수 없는 외부 데이터가 에이전트의 컨텍스트로 들어와 판단을 오염시킨다. 이것이 ASI06이 다루는 메모리·컨텍스트 오염이다. 출력 쪽에서는 에이전트가 권한 밖의 민감 데이터를 끌어와 응답이나 로그에 노출한다.

운영에서는 데이터를 신뢰 등급으로 나누는 것이 출발점이다. 외부에서 들어온 콘텐츠는 명령이 아니라 데이터로만 취급하고, 검색 대상 데이터에도 사용자별 접근 통제를 적용해야 한다. 에이전트가 접근할 수 있다고 해서 모든 사용자가 그 결과를 볼 수 있어야 하는 것은 아니다.

4. 감사 로그: 무슨 일이 있었는지 재구성할 수 있는가

마지막은 사고가 났을 때 되짚을 수 있는가다.

앞의 세 가지가 모두 예방이라면 감사 로그는 사후 대응의 기반이다. 에이전트가 자율적으로 여러 도구를 연속 호출하는 구조에서는, 무엇이 잘못됐는지 나중에 재구성할 수 없으면 같은 사고가 반복된다. 최소한 다음은 남겨야 한다.

구분 기록해야 할 내용

요청자	어떤 사용자가 어떤 요청을 했는가
Agent	어떤 에이전트 버전과 정책으로 실행되었는가
도구	어떤 tool, API, runbook이 호출되었는가
권한	어떤 Role, Service Principal, Managed Identity가 사용되었는가
결과	실행 결과, 실패 원인, 검증 지표는 무엇인가

핵심은 에이전트의 결정 경로를 추적할 수 있느냐다. 어떤 입력이 어떤 도구 호출로 이어졌는지 연결되지 않으면, 로그가 많아도 사고 분석에는 쓸모가 없다.

AWS / Azure 관점

이 네 가지는 클라우드에서 이미 익숙한 통제를 에이전트에 적용하는 일이기도 하다.

AWS에서는 에이전트에 전용 IAM Role을 부여하고 도구별로 권한 경계(Permissions Boundary)를 좁히는 방식이 출발점이다. 단기 자격증명은 STS로 발급하고, 도구 호출과 모델 호출 기록은 CloudTrail로 남긴다. Bedrock 기반 에이전트라면 모델 입출력 로깅과 가드레일을 함께 켜 두는 것이 기본 구성이다.

Azure에서는 에이전트에 Managed Identity를 부여해 자격증명을 코드에서 분리하고, RBAC로 도구별 권한을 최소화한다. 민감 자격증명은 Key Vault로 관리하고, 행동 기록은 Azure Monitor와 Microsoft Entra의 감사 로그로 모은다.

두 클라우드 모두 새로운 보안 모델을 요구하는 것이 아니다. 최소 권한, 단기 자격증명, 신원 분리, 중앙 감사 로그라는 오래된 원칙을 에이전트라는 새 행위자에 그대로 적용하는 것이다.

실무 체크리스트

• 에이전트에 연결된 도구별로 권한을 정의했는가, 아니면 한 자격증명으로 다 처리하고 있는가
• 결제·삭제·권한 부여 같은 되돌릴 수 없는 행동에 사람 승인 단계가 있는가
• 에이전트가 사용자 위임으로 행동하는지, 자기 신원으로 행동하는지 구분되는가
• 외부에서 들어온 콘텐츠를 명령이 아니라 데이터로만 취급하는가
• 사고가 났을 때 입력에서 도구 호출까지 결정 경로를 재구성할 수 있는가

흔한 실수

Prompt Injection 방어 하나로 보안이 끝났다고 보는 것이 가장 흔한 실수다. 입력 방어는 우회될 수 있다고 전제하고, 우회됐을 때의 피해 범위를 권한과 데이터 경계로 줄여 두어야 한다.

개발 편의를 위해 넓게 열어 둔 권한을 운영 전에 좁히지 않는 것도 자주 나온다. "나중에 조이자"는 보통 사고가 난 다음에야 실행된다. 권한은 처음부터 좁게 시작해 필요한 만큼만 여는 편이 안전하다.

마무리

AI Agent 보안에서 Prompt Injection은 중요하지만 첫 단추일 뿐이다. 공격이 성공해도 피해가 크지 않도록 만드는 것은 도구 권한, 신원, 데이터 경계, 감사 로그다. 입력을 완벽히 막으려 애쓰기 전에, 에이전트가 속았을 때 무엇을 할 수 있는지부터 점검해보자.

---

이 글이 유용했다면 다음 편도 확인해보세요.

다음 글: LLM 서비스를 붙일 때 로그에 남기면 안 되는 데이터

References

• OWASP Gen AI Security Project, "OWASP Top 10 for Agentic Applications for 2026" — https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
• OWASP Gen AI Security Project, "OWASP Top 10 for Agentic Applications: The Benchmark for Agentic Security" (2025-12-09) — https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
• OWASP Cheat Sheet Series, "AI Agent Security Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html