Why prompt-injection testing is not enough for production AI agents.

Prompt injection is a route to impact—not the impact itself.

A successful injection may alter instructions, influence tool selection, change parameters, disclose context, or trigger a chain of actions. Whether that becomes a security incident depends on the identities, permissions, application logic, APIs, tools, approval gates, and destinations surrounding the model.

If a hostile instruction reaches the agent but every consequential action is independently authorized against the right actor, tenant, task, and object, impact may remain constrained. If a harmless-looking request reaches an overprivileged tool with no contextual authorization, serious impact may occur without a sophisticated injection at all.

Effective authority is distributed across the system.

For a production agent, the final permission boundary may depend on:

• The initiating user and tenant.
• The delegated purpose and approved task.
• The identity presented by the application or agent runtime.
• The audience, scope, lifetime, and revocation state of credentials.
• The tools and APIs available in the current state.
• Action parameters, object ownership, and server-side business logic.
• Human approval gates and whether they bind the final action.
• Retries, fallbacks, redirects, and alternate destinations.

Reviewing any one layer in isolation can produce false confidence. An identity policy can be correct while the downstream API trusts an agent-supplied tenant identifier. A tool allowlist can be correct while an allowed tool accepts a dangerous parameter. A human approval screen can be present while the executed action differs from what was approved.

Denied paths are first-class requirements.

Teams usually document what the agent should do. Security assurance also needs explicit examples of what it must not do: cross tenants, outlive delegation, reuse a revoked credential, call an alternate destination, exceed an approved amount, repeat an action, or continue after the user withdraws authority.

These prohibited paths turn vague expectations into testable decisions. They also expose gaps between policy language and enforcement code.

A practical authority-verification case.

1. Actor: who initiated the workflow?
2. Context: which tenant, role, and object apply?
3. Delegated task: what was the agent asked and allowed to do?
4. Identity: which credential or service identity exercised the action?
5. Tool and destination: which path reached the downstream system?
6. Action: what operation and parameters were attempted?
7. Intended decision: allow, deny, or require approval?
8. Observed decision: what actually happened and which control decided it?
9. Evidence: can another engineer reproduce and explain the result?

Evidence—not test volume—changes the launch decision.

A useful result connects observed behavior to the release decision. It states the path tested, evidence quality, impact, uncertainty, coverage boundary, remediation direction, and retest status. That is more actionable than a count of prompts, checks, or generic attack categories.