Use case sources
Source reports and analysis supporting this case are listed below. AITBM interpretation and any indicative scoring are derived from this public evidence.
Incident overview
This is a methodology source rather than an incident. The paper reframes indirect prompt injection as a system-architecture problem: an attacker hides instructions in an email, webpage, document, or tool output, the agent reads it during a legitimate task, and the malicious text attempts to steer the next plan, policy update, or tool call.
It argues that dynamic replanning is necessary for utility but opens a boundary, so attacker-controlled feedback must not be allowed to expand what the agent may do; that model-based security judges must be constrained to narrow structured artefacts such as typed traces or proposed plan and policy diffs rather than raw attacker-controlled text; and that human review must be designed, with explicit checkpoints, evidence, and authority for ambiguous cases. It closes by criticising static benchmarks as overstating safety, calling for tests with long tasks, replanning, policy updates, parameter-level attacks, and adaptive payloads. No system was tested and no compromise is reported.
Why this analysis has no ERS
There is no assessed deployment. The brief summarises an academic position paper (arXiv 2603.30016, 'Architecting Secure AI Agents: Perspectives on System-Level Defenses Against Indirect Prompt Injection') that argues for plan, policy, approval, execution, and feedback boundaries in general-purpose agents. It reports no incident, no victim system, no observed configuration, and no measurement of any deployment — every statement is an architectural proposal or a critique of benchmark methodology. Scoring it would require inventing a system's IVP, ORP, and ACI inputs from prescriptive text, which the protocol forbids. The brief is retained for its AIDEFEND mapping and for what its benchmark critique implies about AITBM's own evidence-quality machinery.
Status: Not scorable by design · Classification: Research · source date 2026-05-18
AIDEFEND evidence routes
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief or in the AIDEFEND SecureFlow defense map (audited AIDEFEND dataVersion 2026.10.15); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.10.15. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-M-009.002 | Authority Envelope & Action Risk ClassificationParent AID-M-009 (Agent Autonomy & Authority Governance), catalogue dataVersion 2026.10.15. The brief calls this the conceptual anchor for the paper's plan/policy split; in AITBM terms it is the control whose presence or absence is the primary evidence for Cn-1 and Cn-6 in any agentic assessment. | Very High | Cn-1 Cn-5 Cn-6 Cn-7 |
| AID-H-018.004 | Intent-Based Dynamic Capability ScopingParent AID-H-018 (Tool Authorization & Capability Scoping), dataVersion 2026.10.15. | Very High | Cn-1 Cn-6 Cn-7 |
| AID-H-018.002 | Policy-Based Access ControlParent AID-H-018, dataVersion 2026.10.15. Externalising the decision into checkable policy logic is what makes Cn-1 measurable by SVSR rather than by assessor opinion. | Very High | Cn-1 Cn-6 Cn-7 |
| AID-H-018.006 | Continuous Authorization Verification (Anti-TOCTOU)Parent AID-H-018, dataVersion 2026.10.15. Maps to the paper's requirement to re-check sensitive steps after context, plan, policy, or delegation state changes. | High | Cn-1 Cn-6 Cn-7 |
| AID-H-017.007 | Dual-LLM Isolation PatternParent AID-H-017 (Secure Agent Architecture), dataVersion 2026.10.15. The quarantined-reader/privileged-executor split the paper argues for. | High | Cn-5 Cn-7 |
| AID-H-018.005 | Value-Level Capability Metadata & Data Flow Sink EnforcementParent AID-H-018, dataVersion 2026.10.15. Operationalises the paper's lattice-style information-flow policies by tagging runtime values with provenance and blocking unsafe movement into external sinks. | High | Cn-1 Cn-6 Cn-7 |
| AID-H-018.003 | High-Impact Independent Validation & Approval GateParent AID-H-018, dataVersion 2026.10.15. The paper's plan/policy approver is precisely the Cn-6 pre-execution gate. | High | Cn-1 Cn-6 Cn-7 |
| AID-M-006.001 | HITL Checkpoint Design & DocumentationParent AID-M-006 (Human-in-the-Loop Control Design & Readiness), dataVersion 2026.10.15. Triggers, operator roles, default-deny timeouts, and SOPs are what distinguish a Cn-6 score of 0.75 (human authority required for delegated-irreversible actions) from 1.00 (verifiable approval recorded in a tamper-evident trail). | Medium | Cn-2 Cn-6 |
| AID-M-008 | Automated Agentic Security BenchmarkingdataVersion 2026.10.15. The paper's benchmark critique lands here; in AITBM terms it argues for the Ec fidelity factor and for the Behavioral Attestation Battery's pre-registered canary and adaptive-payload requirements, because a static benchmark run once in a sandbox cannot support a high Evaluation Coverage score. | Medium | Ro-2 |