AI로 생성한 주제 설명용 이미지입니다.
- Source: arXiv cs.CR 2609.14780
- Original: https://arxiv.org/abs/2609.14780
본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.
한눈에 보기
LLM agent에게 tenant_id 같은 권한 scope selector를 tool argument로 맡기면, prompt injection이 authorization bypass 없이도 agent가 자격증명에 포함된 다른 tenant를 선택하게 만들 수 있다는 논문이다. 해결책은 “모델이 올바른 tenant를 고르게 교육”하는 것이 아니라 tenant selector를 tool schema에서 제거하고, 검증된 credential에서 scope를 파생해 agent 아래 계층에서 강제하는 것이다.
연구 배경
전통 client는 코드가 tenant parameter를 결정하므로 서버가 tenant_id ∈ entitlement만 검증해도 충분하다. LLM tool caller는 argument가 attacker-reachable context의 함수이므로 이 전제가 깨진다. credential이 여러 tenant 권한을 가진 운영자라면 공격자는 SQLi나 auth bypass 없이 agent에게 그 권한 중 다른 tenant를 요청하게 할 수 있다.
공격 모델 / 전제 조건
공격자는 direct/indirect prompt injection으로 model context를 완전히 통제할 수 있고, 임의 HTTP request/header를 만들거나 제한된 유효 credential을 가질 수 있으며 tool output을 관찰할 수 있다고 가정한다. 반대로 IdP private key 위조, DB credential 획득, server code execution/source 수정은 불가하고 TLS는 정상이다. 즉 모델을 완전히 compromised deputy로 취급하고도 tenant confinement가 유지돼야 한다.
핵심 Root Cause
authorization 대상 선택 자체가 비결정적이고 attacker-influenceable한 LLM output에 포함되어 있기 때문이다. 서버의 membership check가 정확해도 credential E(p)가 여러 tenant를 포함하면 model이 그중 무엇을 요청할지 attacker가 바꿀 수 있다. 따라서 conventional “parameter를 검증한다”는 통제는 credential 전체 entitlement를 blast radius로 만든다.
핵심 공격 원리
Arm A처럼 get_reservations(hotel_id, limit)가 있고 principal이 3개 tenant 권한을 가지면 injection은 working tenant가 아닌 다른 entitled tenant ID를 model에게 넣게 한다. 서버는 정당한 entitlement이므로 요청을 허용한다. Arm B는 get_reservations(limit)로 selector 자체를 없애고 session credential의 scope를 서버가 강제한다. 단, agent가 writable scope/session variable이나 shell 등 우회 경로를 갖는다면 interface removal만으로 충분하지 않다.
공격 흐름
- agent가 multi-tenant credential로 동작한다. 2. user input/메일/PDF/DB row에 tenant 변경 지시가 들어온다. 3. LLM이 tool argument의 tenant selector를 다른 entitled tenant로 설정한다. 4. server의 정상 authorization check가 통과한다. 5. 다른 tenant row가 agent context로 반환된다. 구조적 방어에서는 3단계의 표현 가능성을 없애고, gateway가 client identity header를 제거하며, verified token claim에서 scope를 만들고, query builder/RLS가 모든 table/join에 scope를 강제한다.
성공 조건 / 실패 조건
성공에는 credential이 현재 작업보다 넓은 entitlement를 갖고 tool schema에 tenant selector가 있어야 한다. 또는 selector 제거 후에도 agent가 scope state를 쓸 수 있는 우회 capability가 있으면 성공할 수 있다. 실패는 tenant 선택이 schema에 없고, scope가 signed claim에서만 유도되며, raw SQL/alternate DB path가 없고, join까지 transitive scope closure가 적용되고, connection/session scope가 다른 principal에게 재사용되지 않을 때다.
연구진의 실험 환경
총 373 trial, 3-arm ablation, 8 model configuration, CLI/native MCP/local tools API 등 2개 이상 transport 계열을 사용했다. Claude Opus 5, gpt-5.4-mini, Gemini 3.1 Pro, qwen3:4b, llama3.2:3b, GPT-5.6 Sol/Terra/Luna 등이 포함된다. principal은 3-tenant anonymized entitlement를 갖고 한 tenant에서 작업한다. benign, plausible pretext, authority injection, tool-return guest-note의 indirect injection을 시험하며 leak 판정은 model 자기보고가 아니라 server audit log로 계산한다. DB 평가는 production MySQL 8.0 read replica의 multi-GB dataset과 local production-schema instance를 사용했다.
주요 실험 결과
Parameter-mediated Arm A는 발생한 out-of-scope attempt 26/26을 모두 serve했다. 전체 plausible-pretext trial 기준으로는 41개 중 26개에서 그런 attempt가 발생했다. selector를 제거한 Arm B에서는 schema를 통한 tenant read를 표현할 수 없었지만, writable scope를 조작하는 interface escape가 56 trial 중 12개 발생해 cryptographic context binding 필요성을 보여줬다. DB 측에서는 function-wrapped JSON membership이 JSON_TABLE join보다 median 기준 약 57× 느렸고, JSON_TABLE은 indexed ref access를 회복했다. 단 tenant index가 없는 약 1/5 table에서는 모든 encoding이 scan으로 퇴화했다. production choke-point builder는 scope 10→15 사이에서 planner cliff가 발생해 15 tenant에서 약 10초, 20 tenant에서 views 방식보다 약 6.5× 느렸다. connection-per-request는 같은 network path에서 median 637.95ms로 대표 scoped query 29.90ms의 21.3×였다. 500 production record egress sample에서는 phone/DOB masking 규칙이 유지됐다.
실제 발견된 취약점 / 사례
연구 시스템에서 실제 개발 중 Unicode \d가 Arabic-Indic/Devanagari digit까지 받아 visually distinct group name이 같은 integer tenant로 collapse될 수 있는 claim parser 문제, allowlist의 잘못된 soft-delete flag 3개, cross-tenant join 관계, session pooling 위험 등을 발견했다. schema audit에서 inter-table relationship 약 2/5가 최소 한 번 tenant boundary를 넘었고 최고 관계는 15.72% row가 cross-tenant였으며 해당 inspected records에는 이름과 전화번호가 있었다.
저자 주장 vs 실제 증명 범위
논문은 “LLM이 절대 prompt injection을 안 당한다”를 증명하지 않는다. 오히려 model compromise를 가정하고 구조가 버티는지를 본다. 373 trial은 특정 agent harness/model/configuration에 대한 경험적 ablation이며 모든 LLM의 공격 성공률을 대표하지 않는다. production은 더 강한 engine-enforced Point A가 아니라 application choke-point Point B를 사용했고, Point A의 ERROR 1142 fail-closed는 local production-schema 환경에서 확인됐다.
기존 공격 / 기존 점검 방식과의 차이
prompt injection detector/guardrail은 모델 행동을 확률적으로 통제한다. 이 연구는 권한을 선택하는 문법 자체를 agent에서 제거한다. 또한 primary table에만 tenant filter를 거는 전통 점검을 넘어 joined relation 전체의 transitive scope closure, signed claim canonical parsing, session reuse, egress minimization까지 authorization boundary로 본다.
연구의 한계와 주의해서 볼 부분
Point B는 alternate DB connection이 생기면 우회된다. MySQL user variable은 read-only가 아니므로 scope tampering 가능성이 남는다. connection-per-request 비용도 크다. null tenant key는 fail-closed지만 데이터 완전성을 훼손한다. 잘못된 IdP entitlement 자체는 막지 못한다. agent가 shell 등 tool interface 밖 capability를 갖는 경우 schema invariance만으로는 충분하지 않다.
공개 PoC / Exploit / Tool / Artifact 분석
논문은 production hostname과 민감 schema를 비공개로 두며 sanitized aggregate design, synthetic reference implementation을 corresponding author 요청 시 제공한다고 적는다. 즉 브리핑 시점 기준 누구나 즉시 clone 가능한 공개 PoC repository가 확인된 상태는 아니다. 논문 내부에는 GuardedCursor, query encoding, ablation 설계 등 재현에 필요한 핵심 구조가 제시되어 있지만 production data와 전체 구현은 공개 artifact로 간주하면 안 된다.
레드팀 / 모의해킹에서 어떻게 활용할까
MCP/agent 시스템에서 prompt injection payload 자체보다 먼저 tool schema가 권한 scope를 표현할 수 있는지를 본다. tenant/project/account/org/user_id가 model-controlled argument인지, credential의 entitlement가 현재 task보다 넓은지, header/session variable로 scope를 덮어쓸 수 있는지, raw SQL/alternate connector가 있는지 확인한다. 특히 join이 primary tenant filter를 우회하는지와 connection pool에서 이전 scope가 남는지 검증 가치가 높다.
실제 점검 시 추가할 체크리스트
- tenant/org/project selector가 LLM tool argument인가?
- selector를 제거해도 writable header/session/context로 scope를 바꿀 수 있는가?
- scope claim은 signature/JWKS 검증 후 canonical parser를 거치는가?
- Unicode digit, leading zero, path segment 변형이 fail-closed인가?
- 모든 join relation에 tenant predicate가 전이되는가?
- raw SQL/직접 DB connection이 choke point를 우회하는가?
- connection pooling checkout 시 scope reset이 원자적으로 보장되는가?
- empty/malformed scope가 0 row로 닫히는가?
실무 가치 평가
AI agent의 authorization 설계를 볼 때 매우 실용적이다. “prompt injection을 막자”가 아니라 “모델이 잘못돼도 권한 경계를 못 넘게 하자”로 관점을 바꾸며, 일반 SaaS multi-tenancy 점검의 join closure/session reuse 문제까지 함께 다룬다.
결론
가장 중요한 원칙은 LLM의 correctness를 authorization proof의 전제로 넣지 않는 것이다. 모델이 선택해서는 안 되는 scope라면 model output에서 제거하고 credential과 lower-layer enforcement로 이동해야 한다.
댓글