좋아. 지금부터 **4번 글 = “Agentic AI Security(에이전트/툴콜 보안)”**을 **완전 원고(복붙 즉시 예약발행 가능)**로 작성할게.
(이 글은 1~3번의 아키텍처/의사결정/운영을 ‘보안 설계’로 완성시키는 핵심 필러야.)

✅ 게시용 메타데이터(복사해서 CMS 입력)

• Title (H1): Agentic AI Security 2026 — Tool Calling(툴콜) 시대의 위협 모델과 방어 설계(프롬프트 인젝션/과도한 권한/공급망)

• Slug/URL: agentic-ai-security-2026-tool-calling-threat-model

• Category: AI Cybersecurity / Governance

• Tags: agentic-ai, tool-calling, prompt-injection, llm-security, owasp-llm-top-10, excessive-agency, insecure-output-handling, supply-chain, sandboxing, audit-log, zero-trust

• Meta Description (160자 내외): 에이전트형 AI는 ‘대답’이 아니라 ‘행동’합니다. 2026년 실제 사고 사례를 바탕으로 Tool Calling 위협 모델, OWASP LLM Top 10 맵핑, 방어 설계(최소권한/샌드박스/승인/감사로그/평가)를 제공합니다.

• OG Title: Agentic AI Security 2026 — Tool Calling Threat Model & Defenses

• OG Description: 프롬프트 인젝션은 끝나지 않습니다. 에이전트/툴콜에서 가장 위험한 공격 경로와 방어 계층(Policy, Sandbox, Approvals, Auditing, Evals)을 백서 수준으로 정리합니다.

• 대표 이미지(생성 프롬프트): 본문 “Image Prompts” 1번 추천

• 권장 발행일: 2026-02-25 (Asia/Seoul)

Agentic AI Security 2026 — Tool Calling(툴콜) 시대의 위협 모델과 방어 설계(프롬프트 인젝션/과도한 권한/공급망)

“챗봇”은 말을 합니다.
“에이전트(Agent)”는 **행동(Action)**을 합니다: 파일을 만들고, 이메일을 보내고, 결제/발주를 하고, 배포를 누르고, 데이터베이스를 조회합니다.
그래서 2026년 보안의 핵심 질문은 바뀝니다.
“모델이 똑똑한가?”가 아니라 “모델이 할 수 있는 일이 안전한가?”

Executive Summary (바로 실행 가능한 결론 9문장)

1. Agentic AI(에이전트형 AI) 보안은 프롬프트만 잘 써서 해결되지 않는다. 핵심은 **툴의 권한(Privilege), 실행 환경(Isolation), 승인(Approval), 감사(Audit), 평가(Evals)**다.

2. 프롬프트 인젝션은 “SQL 인젝션처럼 한 방에 끝낼 수 있는 문제”가 아니라, 모델 구조상 지시문과 데이터를 완벽히 분리하기 어렵다는 점에서 더 까다롭다. 영국 NCSC는 “Prompt injection is not SQL injection” 관점으로 위험을 설명한다. (NCSC)

3. OWASP는 LLM 애플리케이션 Top 10에서 Prompt Injection(LLM01) 등을 핵심 위험으로 다루며, LLM 특화 취약점 분류를 제공한다. (OWASP Foundation)

4. OpenAI는 프롬프트 인젝션을 “프론티어 보안 과제”로 설명하며, 특히 툴을 사용하는 시스템에서 샌드박싱(sandboxing) 같은 격리 기법을 언급한다. (OpenAI)

5. Anthropic은 브라우저 사용(browser use) 시나리오에서 프롬프트 인젝션 방어 연구를 공개하며, 모델을 인젝션에 더 강하게 만들기 위한 접근을 설명한다. (Anthropic)

6. 에이전트형 사고는 “모델이 나쁜 짓을 결심해서”가 아니라, 외부 입력(웹/이메일/문서/깃허브 이슈)이 모델의 의사결정을 오염시키고, 툴 권한이 과도할 때 발생한다.

7. 2026년 2월 공개 보도에서는 오픈소스 AI 코딩 에이전트 생태계에서 공급망/에이전트 관련 보안 이슈가 크게 조명되었다. (The Verge)

8. 결론: Agentic AI는 **“Zero Trust for Tools(툴 제로트러스트)”**로 설계해야 한다. “모델을 믿지 말라”가 아니라, 모델 출력이 안전하지 않다는 전제로 시스템을 만든다.

9. 이 글은 위협 모델(자산/경계/공격자)부터, OWASP 분류 맵핑, 방어 계층(Policy+Sandbox+Approval+Audit+Evals), 운영 체크리스트까지 그대로 복사해 적용 가능한 설계로 제공한다.

1) 먼저 용어부터 “보안 관점”으로 다시 정의하기

1-1. 에이전트(Agent)란 무엇인가?

에이전트형 AI는 보통 아래 3요소를 가진다.

• Planner(계획자): 목표를 분해해 단계 계획을 세움

• Tool User(툴 사용자): 외부 도구(API/브라우저/쉘/DB/메일)를 호출

• Memory/State(상태): 이전 실행 결과와 컨텍스트를 유지

즉, 에이전트는 “텍스트 생성기”가 아니라 자동화 실행기다.

1-2. Tool Calling(툴콜)이 왜 위험한가?

툴콜은 모델이 **현실 세계(시스템)**에 영향을 주는 통로다.

• 읽기(Read): DB 조회, 문서 검색, 파일 읽기

• 쓰기(Write): 파일 생성/수정, 티켓 생성, 메시지 발송

• 실행(Execute): 명령 실행, 배포, 결제/송금 API 호출

툴콜이 추가되는 순간, 보안의 중심은 “답변 내용”에서 “행동 결과”로 이동한다.

2) 위협 모델(Threat Model): 에이전트 보안은 여기서부터 시작한다

아키텍처를 보안으로 바꾸는 가장 확실한 방법은 자산/경계/공격자 모델을 먼저 박는 것이다.

2-1. 보호해야 할 자산(Assets)

1. 비밀정보(Secrets): API 키, 토큰, 쿠키, SSH 키, DB 크리덴셜

2. 민감데이터(Sensitive Data): PII, 계약/재무, 내부 문서

3. 권한(Privileges): 배포 권한, 결제 권한, 관리자 권한

4. 무결성(Integrity): 코드 저장소, CI/CD 파이프라인, 정책 문서

5. 가용성(Availability): 비용 폭발(무제한 실행), 서비스 다운

2-2. 신뢰 경계(Trust Boundaries) — 에이전트는 경계가 많다

• 사용자 입력(신뢰 낮음)

• 외부 콘텐츠(웹페이지/메일/문서/깃허브 이슈 등: 신뢰 최저)

• 내부 시스템(DB/CRM/CMS/CI/CD: 신뢰 높음)

• 툴 실행 환경(쉘/브라우저 자동화/파일 시스템: 폭발 반경 큼)

• 로그/감사 저장소(유출되면 2차 피해)

2-3. 공격자 모델(Attacker Capabilities)

• 외부 입력을 주입할 수 있음(웹/메일/문서/이슈 제목/첨부파일)

• 사회공학(“긴급”, “관리자 지시”, “보안 업데이트 필요”) 문구 삽입

• 모델이 출력한 텍스트를 후속 시스템이 그대로 실행하도록 유도(출력 기반 RCE)

• 공급망 공격(패키지/플러그인/워크플로우 변조)

3) “왜 프롬프트 인젝션은 끝나지 않나?” — 지시문 vs 데이터의 구조적 문제

NCSC는 프롬프트 인젝션을 SQL 인젝션과 동일 선상에서 단순 비교하는 것이 위험하다고 지적하며, LLM이 본질적으로 지시문과 데이터를 명확히 분리하지 못하는 점을 강조한다. (NCSC)
OpenAI 역시 프롬프트 인젝션을 장기적으로 진화하는 “프론티어 보안 과제”로 설명한다. (OpenAI)

여기서 실무 결론은 단순하다.

프롬프트 인젝션 “완전 차단”을 목표로 하지 말고,
인젝션이 성공해도 피해가 제한되도록(Blast Radius 최소화) 시스템을 설계하라.

이게 에이전트 보안의 핵심 철학이다.

4) OWASP LLM Top 10을 “에이전트/툴콜”에 맵핑하면 위험이 선명해진다

OWASP Top 10 for LLM Applications는 LLM 특화 위험을 체계적으로 정리한다. (OWASP Foundation)
에이전트에 특히 치명적인 항목은 아래다(이 글은 에이전트 관점으로 풀어쓴다).

4-1. 에이전트에 치명적인 Top 위험 6개(실무 우선순위)

1. LLM01 Prompt Injection — 외부 콘텐츠가 “명령”이 되어버림 (OWASP Foundation)

2. Insecure Output Handling — 모델 출력이 후속 시스템에서 그대로 실행 (OWASP Foundation)

3. Excessive Agency — 모델이 너무 많은 권한/자율성을 가짐(승인/제한 없음)

4. Sensitive Information Disclosure — 컨텍스트/로그/툴 결과에 비밀이 섞임

5. Supply Chain — 플러그인/패키지/워크플로우 변조(에이전트 생태계의 약점)

6. Unbounded Consumption — 무한 루프/과도한 호출로 비용 폭발(가용성 공격)

5) 실제 사고가 말해주는 것: “에이전트 + 공급망 + 인젝션”은 같이 온다

2026년 2월, 에이전트/코딩 도구 생태계에서 보안 이슈가 크게 조명되었다. (The Verge)
이 사례가 주는 핵심 교훈은 “특정 도구가 나쁘다”가 아니라 다음 3가지다.

1. 외부 입력(웹/이슈/문서)은 공격 표면이다.

2. 에이전트가 툴을 통해 시스템에 영향을 줄수록, 출력 오염이 곧 실행 오염이 된다.

3. 공급망(패키지/플러그인/자동화)은 에이전트 시대에 더 위험해진다.

그래서 “툴 제로트러스트”가 필요하다.

6) 방어 설계(Defense-in-Depth): Tool Zero Trust 7계층

이 파트가 이 글의 본체다.
프롬프트를 잘 쓰는 것은 0번째 방어일 뿐이고, 진짜 방어는 아래 계층에서 나온다.

계층 1) 입력을 “신뢰도 라벨링”하라 (Untrusted Content Labeling)

외부 콘텐츠는 모두 UNTRUSTED로 태깅하고, 시스템 프롬프트/정책 엔진이 이를 데이터로만 취급하도록 강제한다.

• 웹페이지/메일/문서/이슈 본문/첨부파일: 기본 UNTRUSTED

• 내부 승인된 정책 문서/런북: TRUSTED(단, 버전/서명 필요)

실무 팁

• “콘텐츠 출처(provenance) + 해시”를 함께 저장하면, 사고 재현과 변조 탐지가 쉬워진다.

계층 2) 툴 권한을 “최소권한(Least Privilege)”으로 찢어라

에이전트가 쓰는 툴은 하나의 만능 토큰이 아니라, 작게 쪼갠 권한으로 설계해야 한다.

• Read-only 툴(조회)

• Write 툴(쓰기) — 반드시 제한된 스코프

• Execute 툴(실행) — 가장 위험, 기본 OFF 또는 강한 승인

권한 설계 예시(개념)

• CRM 조회: crm.read.customer_basic

• CRM 수정: crm.write.note_only (노트만)

• 결제/환불: 별도 서비스 계정 + 다중 승인

계층 3) “툴 승인(Approvals)”을 기본값으로 켜라 (Human-in-the-Loop)

OpenAI는 에이전트 빌더 안전 가이드에서 툴 승인(사용자 확인) 같은 원칙을 강조한다. (OpenAI 개발자 문서)
핵심은 간단하다.

• Read는 자동화 가능(단, 민감도에 따라 제한)

• Write/Execute는 승인 필요(기본값)

승인은 단순히 “OK?”가 아니라 명세 기반이어야 한다.

• 무엇을(what)

• 어디에(where)

• 어떤 범위로(scope)

• 왜(why)

• 예상 결과(expected outcome)

계층 4) 샌드박스/격리(Sandboxing)로 “성공해도 못 망치게” 만들어라

OpenAI는 툴을 사용하는 AI 시스템에서 샌드박싱 같은 격리 기법을 언급한다. (OpenAI)
에이전트가 쉘/브라우저/파일 시스템에 닿는다면, 격리는 선택이 아니라 필수다.

• 파일 시스템: 작업 디렉터리 제한, 읽기 전용 마운트

• 네트워크: egress 제한(허용 도메인만)

• 프로세스: 권한 낮은 계정, 컨테이너 격리

• 비밀: 런타임에서만 짧게 발급(짧은 TTL)

목표: 인젝션이 “명령”이 되더라도, 실행 환경이 폭발 반경을 제한한다.

계층 5) 출력은 ‘코드’가 아니다: Insecure Output Handling을 끊어라

OWASP는 출력 처리 미흡(Insecure Output Handling)을 주요 위험으로 다룬다. (OWASP Foundation)
에이전트에서 가장 흔한 사고 패턴이 이거다:

모델이 만든 텍스트를, 후속 시스템이 그대로 실행한다(스크립트/쿼리/CLI).

방어 원칙(실무)

• 모델 출력은 기본 “데이터”로 취급

• 실행 가능한 형태(명령/쿼리)는 **구조화된 스키마(JSON)**로만 받기

• 스키마 검증 + allowlist + 파라미터화

• 위험한 조합은 차단(예: delete/drop, 광범위 스코프)

계층 6) 정책 엔진(Policy Engine)으로 “안 되는 건 안 된다”를 기계적으로 강제하라

LLM Gateway/Policy Engine은 보안팀이 좋아하는 지점이다.
여기서 해야 할 일:

• PII 탐지/마스킹

• ACL 검증(문서/레코드 접근)

• 툴 allowlist(허용 툴만)

• 스코프 제한(특정 테넌트/프로젝트만)

• 속도/쿼터 제한(비용 폭탄 방지)

중요: 정책은 “프롬프트로 부탁”하는 게 아니라, 실제 실행 전에 강제해야 한다.

계층 7) 평가(Evals) + 레드팀(Red Teaming)으로 “깨지는 지점”을 계속 찾는다

Anthropic은 프롬프트 인젝션 방어 연구를 공개하며, 인젝션 상황에서 모델이 올바르게 거부하도록 훈련/평가하는 접근을 설명한다. (Anthropic)
NIST는 GenAI에 대한 AI RMF 프로파일 문서(Generative AI용 프로파일)를 제공하며 위험 관리 접근을 확장한다. (NIST Technical Series Publications)

실무적으로는 이렇게 한다

• 인젝션 테스트 세트(웹/문서/메일/이슈 형태) 구축

• “툴 악용 시나리오” 테스트: 과도한 권한 요청, 범위 확장, 승인 우회

• 회귀 테스트: 프롬프트/모델/툴 변경 시 자동 실행

• 카나리 배포: 일부 트래픽에서 먼저 검증

7) 에이전트 보안 설계의 핵심 문장 12개(운영팀/보안팀 합의용)

1. 외부 콘텐츠는 항상 UNTRUSTED다.

2. 모델 출력은 항상 안전하지 않다.

3. 툴은 최소권한으로 분해한다.

4. Write/Execute는 승인 없이는 실행하지 않는다.

5. 실행 환경은 샌드박스로 격리한다.

6. 비밀은 런타임에서 짧게 발급한다(짧은 TTL).

7. 출력은 스키마 검증/allowlist 없이는 실행하지 않는다.

8. 정책은 프롬프트가 아니라 실행 레이어에서 강제한다.

9. 감사 로그는 “누가/무엇을/왜/어떤 권한으로/어떤 결과로”를 남긴다.

10. 비용 폭탄(무한 루프/무제한 호출)은 보안 사건이다(가용성).

11. Evals/레드팀 없이는 ‘안전하다’고 말하지 않는다.

12. 인젝션은 완전 제거가 아니라 피해 최소화가 목표다. (NCSC)

8) “에이전트 감사 로그(Audit Log)” 최소 필드(복사해서 쓰는 표준)

에이전트는 사고가 나면 반드시 이런 질문을 받는다:

• 누가 실행했나?

• 어떤 입력이 원인이었나?

• 어떤 툴을 호출했나?

• 어떤 권한/스코프로 실행됐나?

• 결과는 무엇이었나?

• 승인(approval)은 있었나?

그래서 최소 필드는 아래처럼 잡는다.

• trace_id, request_id, session_id

• tenant_id, user_id, user_role

• untrusted_sources[] (URL/문서ID/메일ID + 해시)

• policy_decisions[] (허용/차단/마스킹 + 이유코드)

• tool_calls[] (툴명, 파라미터 스키마, 스코프, 실행결과, 실행시간)

• approvals[] (누가 승인했는지, 승인 당시 요약)

• secrets_accessed[] (어떤 secret이 언제 발급됐는지 — 값은 저장하지 말고 참조만)

• cost_metrics (토큰/툴 호출 횟수/재시도/시간)

이 구조가 있어야 “재현 가능한 보안”이 된다.

9) 운영 체크리스트 32개(에이전트 도입 전/후 점검)

A. 설계/경계(10)

1. 외부 콘텐츠 UNTRUSTED 라벨링이 있는가

2. 신뢰 경계(웹/메일/문서/내부DB)가 문서화되어 있는가

3. 에이전트가 접근하는 자산(비밀/DB/배포)이 목록화되어 있는가

4. “최대 피해 반경(Blast Radius)”이 정의되어 있는가

5. 데이터 분류(PII/기밀) 규칙이 정책 엔진에 반영되어 있는가

6. 멀티테넌시 환경에서 테넌트 경계가 강제되는가

7. 로그/감사 저장소 접근권한이 분리되는가

8. 취약점/사고 대응 책임(RACI)이 정해져 있는가

9. 비상시 “에이전트 기능 OFF(킬스위치)”가 있는가

10. 공급망(플러그인/패키지/워크플로우) 검증 정책이 있는가

B. 툴 권한/실행(12)

11. 툴 권한이 최소권한으로 분해되어 있는가

12. Write/Execute가 기본 승인 모드인가 (OpenAI 개발자 문서)

13. 위험 툴(쉘/배포/결제)의 기본값이 OFF인가

14. 실행 환경이 샌드박스로 격리되는가 (OpenAI)

15. 네트워크 egress가 allowlist 기반인가

16. 파일 시스템/프로세스 권한이 제한되는가

17. 모델 출력이 직접 실행되는 경로가 없는가(스키마 검증) (OWASP Foundation)

18. 툴 입력이 파라미터화/검증되는가

19. 재시도/루프 제한(최대 단계/최대 호출)이 있는가

20. 테넌트별 쿼터/레이트리밋이 있는가

21. 비밀은 짧은 TTL로 발급되는가

22. 비밀 값이 로그에 남지 않도록 마스킹되는가

C. 평가/Evals/레드팀(10)

23. 프롬프트 인젝션 테스트 세트가 있는가 (Anthropic)

24. 문서 인젝션/웹 인젝션/메일 인젝션 시나리오가 포함되는가

25. “승인 우회” 시나리오가 포함되는가

26. 모델/프롬프트/툴 변경 시 자동 회귀 테스트가 도는가

27. 카나리 배포 후 온라인 지표를 확인하는가

28. 정책 엔진 변경은 별도 검증 절차가 있는가

29. 감사 리포트 재현 테스트가 정기적으로 수행되는가

30. 사고 대응 런북(runbook)이 존재하는가

31. 외부 보안 리뷰(또는 내부 레드팀)가 정기적으로 도는가

32. 사용자 피드백(오작동 신고)이 triage 프로세스로 연결되는가

10) 6+ Image Prompts (전문성 강화용)

형식: [Image Concept] + [Prompt (English)] + [Description (Korean)]

1. [Tool Zero Trust Layered Defense]
   Prompt (English): “Agentic AI security layered defense diagram, tool zero trust, policy engine, sandbox isolation, human approvals, audit logs, evals pipeline, cinematic futuristic infographic, ultra-detailed, 8k”
   Description (Korean): 정책/샌드박스/승인/감사/평가로 계층 방어를 시각화.

2. [Prompt Injection Attack Surface Map]
   Prompt (English): “Prompt injection attack surface map for AI agents, untrusted web/email/docs inputs flowing into tool calls, red-team overlays, high-tech threat model infographic, 8k”
   Description (Korean): 외부 입력이 툴 실행으로 이어지는 공격 경로 지도.

3. [Least Privilege Tool Permission Grid]
   Prompt (English): “Least privilege tool permission grid, separated read/write/execute scopes, tenant isolation, clean enterprise UI dashboard, 8k”
   Description (Korean): 툴 권한을 쪼개는 최소권한 설계를 시각화.

4. [Sandboxed Execution Environment]
   Prompt (English): “Sandboxed execution environment for AI agents, container isolation, restricted filesystem, network egress allowlist, secret vault with short-lived tokens, photorealistic 3D render, 8k”
   Description (Korean): 샌드박스/격리/짧은 TTL 비밀 발급 구조를 표현.

5. [Human-in-the-Loop Approval Panel]
   Prompt (English): “Human-in-the-loop approval panel for AI tool calls, showing what/where/why/scope/expected outcome, sleek modern enterprise UI, 8k”
   Description (Korean): 승인 화면이 ‘OK 버튼’이 아니라 명세 기반이라는 걸 강조.

6. [Audit Log Timeline + Trace ID]
   Prompt (English): “Audit log timeline visualization with trace IDs, tool calls, policy decisions, approvals, citations, immutable ledger aesthetic, cinematic infographic, 8k”
   Description (Korean): 사고 조사/재현을 위한 감사 로그 타임라인.

7. [OWASP LLM Top 10 Mapped to Agents]
   Prompt (English): “OWASP LLM Top 10 mapped to agentic AI, prompt injection, insecure output handling, excessive agency, supply chain, unbounded consumption, clean security poster style, 8k”
   Description (Korean): OWASP 분류를 에이전트 위험으로 번역한 포스터.

11) FAQ (AEO 최적화 10개)

1. Q. 에이전트형 AI가 챗봇보다 위험한 이유는 뭔가요?
   A. 챗봇은 텍스트를 생성하지만, 에이전트는 툴을 통해 시스템에 행동을 실행합니다. 그래서 출력 오염이 곧 실행 오염이 될 수 있습니다.

2. Q. 프롬프트 인젝션은 완전히 막을 수 있나요?
   A. 현실적으로 “완전 차단”보다 **피해 최소화(격리/최소권한/승인/정책 강제)**가 더 실무적인 목표입니다. NCSC와 OpenAI 모두 이 위험이 구조적으로 까다롭다는 점을 강조합니다. (NCSC)

3. Q. OWASP LLM Top 10은 왜 참고해야 하나요?
   A. LLM 특화 취약점을 분류해 설계/점검 체크리스트로 바꾸기 좋기 때문입니다. Prompt Injection 같은 핵심 위험을 명확히 다룹니다. (OWASP Foundation)

4. Q. Tool Calling에서 가장 먼저 해야 할 보안 조치는?
   A. 툴 최소권한 분해 + Write/Execute 승인 기본값 + 샌드박스 격리가 1순위입니다.

5. Q. 승인(Human approval)을 넣으면 자동화 가치가 떨어지지 않나요?
   A. “승인이 필요한 구간”을 분리하면 됩니다. Read는 자동화, Write/Execute는 승인처럼 경계를 세우면 안전과 자동화가 같이 갑니다. (OpenAI 개발자 문서)

6. Q. 모델 출력이 후속 시스템에서 실행되는 걸 어떻게 막나요?
   A. 출력은 스키마(JSON)로만 받고, 검증/allowlist/파라미터화를 강제해야 합니다. OWASP는 출력 처리 미흡을 주요 위험으로 다룹니다. (OWASP Foundation)

7. Q. 샌드박스가 꼭 필요한가요?
   A. 에이전트가 쉘/브라우저/파일 시스템을 다루면 사실상 필수입니다. OpenAI는 툴을 사용하는 시스템에서 샌드박싱 같은 격리 기법을 언급합니다. (OpenAI)

8. Q. 감사 로그는 어디까지 남겨야 하나요?
   A. 최소한 trace_id, 정책결정, 툴 호출, 승인 기록, 근거(문서 계보)가 필요합니다. 원문 전체를 무작정 저장하기보다 참조/해시 중심이 안전합니다.

9. Q. 레드팀/평가는 무엇을 테스트해야 하나요?
   A. 웹/문서/메일 인젝션, 승인 우회, 과도한 권한 요청, 무한 루프/비용 폭탄(가용성)을 포함해야 합니다. Anthropic과 OpenAI의 공개 자료는 인젝션 방어가 중요한 연구 주제임을 보여줍니다. (Anthropic)

10. Q. 실제로 요즘 이런 사고가 있나요?
    A. 2026년 2월, 에이전트/코딩 도구 생태계에서 공급망/에이전트 보안 이슈가 연달아 보도되며 관심이 크게 커졌습니다. (The Verge)

Proof Box (근거/검증)

• OWASP Top 10 for LLM Applications는 LLM 특화 위험(예: Prompt Injection 등)을 정리합니다. (OWASP Foundation)

• UK NCSC는 “Prompt injection is not SQL injection” 관점으로 위험을 설명합니다. (NCSC)

• OpenAI는 프롬프트 인젝션을 프론티어 보안 과제로 설명하며, 툴 사용 환경에서 샌드박싱 같은 격리 접근을 언급합니다. (OpenAI)

• Anthropic은 브라우저 사용 맥락에서 프롬프트 인젝션 방어 연구를 공개합니다. (Anthropic)

• NIST는 GenAI에 대한 AI RMF 프로파일 문서를 제공하여 위험 관리 접근을 확장합니다. (NIST Technical Series Publications)

한계 / 리스크(반례 포함)

1. 프롬프트 인젝션은 “완전 차단”이 어려울 수 있어, 피해 최소화 설계가 핵심입니다. (NCSC)

2. 승인(approval)을 과도하게 걸면 자동화 가치가 떨어질 수 있으므로, Read/Write/Execute 경계가 중요합니다.

3. 감사 로그는 많이 남긴다고 무조건 좋은 게 아닙니다. 보존/권한/마스킹이 부실하면 2차 유출 위험이 커집니다.

4. 에이전트 생태계는 플러그인/패키지/워크플로우 등 공급망 요소가 많아 공급망 리스크를 별도로 관리해야 합니다.

Update Log

• v1.0 (2026-02-23): Tool Zero Trust 7계층 방어, OWASP 맵핑, 감사 로그 표준, 체크리스트 32개, 최신 보도 흐름 반영 (The Verge)

• v1.1 예정: (1) 승인 UX 템플릿(what/where/why/scope) (2) 인젝션 테스트 세트 샘플 구조 (3) 테넌트/ACL 정책 템플릿 확장

커뮤니티 토론 질문(댓글 유도)

1. 너희는 Write/Execute 툴에 “기본 승인”을 걸고 있나요? 아니면 자동화인가요?

2. 에이전트의 최대 피해 반경(Blast Radius)은 어떻게 정의했나요?

3. 프롬프트 인젝션 테스트(웹/문서/메일)를 정기적으로 돌리고 있나요?

내부 링크(이전 글 연결)

• 1번 글: Enterprise RAG Reference Architecture 2026 — Gateway·Policy·Audit

• 2번 글: Fine-tuning vs RAG vs Hybrid — 의사결정 프레임워크

• 3번 글: Enterprise LLMOps 2026 — 토큰 비용·p95·환각률 운영 체계

• 다음 글(5번 예고): GPU Cloud & AI Factory 2026 — Blackwell/랙스케일 인프라와 비용 최적화(고단가)

• The Verge
• WIRED
• techradar.com
  Prompt injection is not SQL injection (it may be worse)

  There are crucial differences between prompt and SQL injection which – if not considered – can undermine mitigations.