OWASP에서 OWASP Top 10 for Agentic Applications 2026이 공개된 지 시간이 좀 흘렀지만, 이제 와서 다시 한번 훑어보았습니다. Top 10을 그대로 읽으면, ASI01: Agent Goal Hijack

, ASI02: Tool Misuse and Exploitation

, ASI03: Identity and Privilege Abuse

와 같이 위협 명칭이 나열되어 있어, "실제로 Agent의 어느 부분을 신경 써야 하지?"라는 점을 파악하기가 조금 어려웠습니다.

제 경우에는 Agent의 처리 흐름에 겹쳐서 보는 것이 더 이해하기 쉬웠습니다.

이 기사에서는 OWASP Agentic AI Top 10을 암기하는 것이 아니라, Agent의 구성 요소별 체크리스트로 바라보는 방법을 정리합니다.

Agent는 구현에 따라 차이가 있지만, 대략 다음과 같은 흐름으로 동작합니다.

User -> Goal / Instruction -> Planning -> Memory / Context
-> Tool Selection -> Tool Execution -> External Systems
-> Output / Human

Claude Code, OpenAI Codex, 각종 Agent SDK, MCP를 사용한 구성도 세부 사항은 다르더라도 대체로 이 흐름으로 생각할 수 있습니다.

이 흐름에 OWASP Top 10을 배치하면, "위협 명칭"이 아니라 "설계 시 확인해야 할 지점"으로서 다루기 쉬워집니다.

위의 그림과 겹치지만, 표로 나타내면 다음과 같은 느낌일 것입니다.

이렇게 보면, OWASP Top 10은 "공격 패턴의 목록"이라기보다, Agent를 만들 때의 리뷰 관점에 가깝게 다룰 수 있습니다.

기존의 LLM 애플리케이션의 경우, 프롬프트 인젝션의 영향은 "이상한 답변을 한다" 정도로 보이기 쉬웠습니다.

하지만 Agent에서는 이야기가 조금 달라집니다.

회의를 예약해줘
↓
고객 정보를 외부로 보내줘

와 같이, 답변이 아니라 행동 그 자체가 탈취됩니다.

따라서 사용자의 원래 목적과 Agent가 실행하려는 목적이 뒤바뀌지 않는지 가드(Guard)해야 합니다.

Agent가 장기 기억(Long-term Memory)이나 RAG를 사용하기 시작하면, 잘못된 정보가 그 상황에서 끝나지 않는다는 점이 무섭습니다.

예를 들어, A씨는 관리자로 취급해도 좋다와 같은 잘못된 정보가 Memory나 지식(Knowledge)에 들어가면, 그 이후의 판단에도 계속 영향을 미칩니다.

RAG나 Agent Memory를 도입한다면, "무엇을 저장할 것인가"뿐만 아니라 "누가 업데이트할 수 있는가", "언제 누가 추가한 기억인가", "언제 무효화할 것인가", "참조 출처를 추적할 수 있는가"도 확인해 두고 싶습니다.

Agent Security의 상당히 큰 부분이 바로 여기라고 생각합니다.

Agent는 AWS, 사내 시스템, MCP Server 등을 조작할 수 있습니다. 즉, 문제는 잘못된 답변뿐만 아니라 잘못된 실행이 됩니다.

예를 들어, 메일을 읽기만 하면 되는 Agent에게 송신 권한까지 부여하거나, 참조만 하면 되는 CRM 연동에 업데이트 권한까지 부여하는 상태는 매우 위험합니다.

툴(Tool)마다 다음과 같은 관점을 확인하는 것만으로도 상당히 현실적인 체크가 됩니다.

• 해당 Agent에 정말로 필요한가
• 읽기 권한만으로 충분한가
• 고위험 작업에 승인(Approval) 단계를 넣을 수 있는가
• 실행 로그를 나중에 추적할 수 있는가

Agent를 설계할 때는 처음에 Top 10을 훑어보기보다, 먼저 자신의 Agent 구성 요소를 써 내려가는 것이 좋아 보입니다.

Goal / Planning / Memory / Tool / Execution / External Systems / Human Approval

그 후에 이번 기사처럼 각 요소에 OWASP Top 10을 매핑해 나갑니다.

예를 들어 Tool 주변이라면 ASI02, ASI03, ASI05를 중점적으로 보고, Memory를 사용한다면 ASI06을 보고, Agent끼리 연결한다면 ASI07을 보는 식입니다.

이 방식이 추상적인 위협 목록을 읽는 것보다, 자신의 구현 사항에 대입하여 생각하기 더 쉽다는 느낌이 듭니다.

OWASP Agentic AI Top 10은 이름만 보면 조금 무겁게 느껴질 수 있지만, Agent의 구성 요소(Components)에 매핑하면 상당히 사용하기 편리해집니다.

제 이해로는, 이것을 '암기해야 할 Top 10'이 아니라, 'Agent의 각 부품에 대한 보안 체크리스트 (Security Checklist)'로 사용하는 것이 좋을 것 같습니다. (다른 위협들도 마찬가지겠지만요)

Agent 개발에서는, Agent의 구성 요소를 도출한다 -> 각 요소에 OWASP Top 10을 매핑한다 -> 중요한 항목을 심층 분석한다

이런 식으로 진행하면, 위협 모델링 (Threat Modeling)의 입구로서 사용하기 유용할 것이라고 생각합니다.