Key facts.
- Greshake et al. demonstrated that indirect prompt injection via retrieved content can redirect agent tool calls to unauthorized endpoints and exfiltrate data through parameter manipulation, with no reliable model-level defense (Greshake et al., arXiv:2302.12173, 2023).
- AgentDojo (arXiv:2406.13352) evaluated 10 state-of-the-art agents against 97 realistic injection attacks; even with defenses in place, a substantial proportion of injection attempts succeeded in manipulating tool calls (AgentDojo, arXiv:2406.13352).
- GDPR Article 5(1)(f) requires personal data be protected against unauthorized processing; an injection that routes PII into an unauthorized tool call constitutes unauthorized processing regardless of intent (GDPR Art. 5(1)(f)).
- SOX Section 302 requires management to certify that internal controls prevent unauthorized access to financial reporting systems; an injection that manipulates a financial tool call undermines this certification.
- Most enterprise agents lack parameter-level logging sufficient to reconstruct whether a specific tool parameter value originated from the authorized user request or from injected content, creating an audit trail gap.
Why compliance exposure exceeds security exposure in most cases
A security team evaluating injection risk asks: did the attacker get data they shouldn't have? A compliance team evaluating the same incident asks: did the system process data in a way that wasn't authorized, documented, or auditable? The compliance question has a much lower threshold. An injection that changes a search query parameter from a customer name to a competitor name might not exfiltrate anything. It still constitutes an unauthorized processing operation under most enterprise data governance frameworks.
Greshake's foundational work showed that agents retrieving content from web pages, emails, or documents are exposed to injection via that content. AgentDojo's red-team benchmark confirmed that even agents with explicit injection defenses remain vulnerable to a meaningful proportion of attacks. The compliance implication: for any regulated enterprise agent, the risk model must include unauthorized processing - not just data exfiltration - as a primary threat scenario.
What parameter-level compliance controls look like
The technical controls that address this at the compliance level are different from those that address it at the security level. Security focuses on preventing the injection from succeeding. Compliance requires that if an injection does succeed, it's detected, logged, and auditable. This means: every tool parameter value must be logged alongside its source (user-provided, retrieved content, agent-generated), parameter values that originate from retrieved content must be flagged before tool execution, and any deviation from the authorized parameter set must produce a compliance-grade log entry.
Compliance risk by injection type
| Injection type | Security risk | Compliance risk | Detection method |
|---|---|---|---|
| PII rerouting | Data exfiltration | GDPR unauthorized processing | Parameter origin logging |
| Financial parameter manipulation | Fraud | SOX internal control failure | Parameter value range validation |
| Authorization bypass | Privilege escalation | Access control audit finding | Permission check logging |
| Query redirection | Information disclosure | Data governance violation | Endpoint allowlist validation |
One injected tool parameter is a GDPR disclosure wearing a security badge; a more capable model reads the injection just as obediently. (arXiv:2302.12173)
VibeModel's Pattern Intelligence Layer treats parameter provenance as a first-class signal. By tracking which parameter values originated from user requests versus retrieved content versus agent-generated reasoning, it identifies injection-influenced parameter patterns before tool execution. The compliance benefit is that this same tracking produces the audit log that regulators require: a reconstructible record of what authorized the specific parameter value used in each tool call.
Frequently asked questions
Is parameter-level logging required by regulation, or just good practice?
Increasingly required. EU AI Act Article 12 requires high-risk AI systems to keep logs sufficient for post-hoc analysis. For agents processing personal data, GDPR's accountability principle (Art. 5(2)) requires demonstrating lawful processing for every operation, which demands parameter-level audit trails.
Can we use an LLM to detect injection in tool parameters?
As one layer, yes. But it isn't sufficient alone. Model-level injection detection has a non-trivial false negative rate, as AgentDojo demonstrated. Structural controls, parameter origin logging, and allowlist validation add deterministic layers that don't depend on the model correctly identifying the attack.
Who owns this risk, security or compliance?
Both, but governance ownership typically belongs to compliance because the primary exposure in most enterprises is regulatory. The security team addresses the attack surface; the compliance team owns the authorization framework and the audit trail requirements.