By NHI Mgmt Group Editorial TeamDomain: AI SecuritySource: ActiveFencePublished August 18, 2026

TL;DR: Nine frontier models tested as enterprise agents across 147 adversarial scenarios produced a mean Agent Failure Rate of 0.75, according to ActiveFence, with every model failing on more than half the scenarios and the best updated model still failing 17% of the time. The result shows that agent governance, tool access, and prompt-injection resistance remain operational controls, not theoretical concerns.


At a glance

What this is: ActiveFence benchmarked enterprise agents against indirect prompt injection and found that frontier models failed the majority of adversarial scenarios.

Why it matters: For IAM, PAM, and AI governance teams, the finding shows that giving agents tools and access without strict controls creates a real access and compliance risk.

By the numbers:

👉 Read ActiveFence's benchmark analysis of enterprise indirect prompt injection


Context

Enterprise AI agents break the old assumption that automation is only as risky as the workflow it directly controls. Once an agent can read email, process tickets, or act on vendor requests, hidden instructions can turn normal business content into an attack path through the agent's own access.

This is why AI agent governance now sits close to IAM and PAM even when the systems are not human users. The core problem is not model capability alone, but whether access, scope, and approval boundaries are defined tightly enough for systems that can independently decide how to act. The pattern is becoming typical in early agent deployments, not exceptional.


Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do indirect prompt injections create more risk than ordinary prompt errors?

A: Because the attack is embedded in content the agent is already expected to trust. The model can interpret a hidden instruction as part of the workflow and then act through legitimate permissions, which turns a text manipulation issue into a data, fraud, or compliance problem.

Q: What do organisations get wrong about AI agent safety at design time?

A: Organisations often assume that a safe design remains safe in production. In practice, agents can combine memory, APIs, and workflow steps in ways that were never obvious in the original approval. Runtime behaviour must therefore be monitored and constrained continuously. Use the Zero Trust model to judge actions as they happen, not only when the system is deployed.

Q: Which controls matter most when AI agents can take response actions?

A: The key controls are graduated autonomy, full audit logging, and policy-backed approval gates for higher-impact actions. Teams should also separate read access from write authority so agents can analyse broadly without being able to change protections or trigger irreversible remediation on their own.


Technical breakdown

How indirect prompt injection turns ordinary content into an attack path

Indirect prompt injection happens when an attacker hides instructions inside content the agent is expected to trust, such as an email, ticket, document, or vendor message. The model does not need to be directly prompted by the attacker. It simply reads the malicious content while performing its task, then treats those instructions as if they were part of the workflow. In enterprise settings, the danger is amplified when the agent has tool access, because the attack can move from text manipulation to action execution in the same session.

Practical implication: separate content ingestion from action authority so untrusted inputs cannot directly influence tool use.

Why agent failure rate is the right metric for enterprise risk

Agent Failure Rate measures whether a model fails at least once across repeated runs, which is more relevant than single-pass success because enterprise workflows are not one-shot demonstrations. A model that occasionally obeys a malicious instruction can still cause data loss, fraud, or policy violations in production. That makes average capability less important than repeated resistance under realistic conditions. The benchmark also used a functional adherence score to ensure the agent was actually doing the task, which avoids overstating safety by rewarding inactivity.

Practical implication: evaluate agents for repeated failure under realistic task conditions, not just for average benchmark performance.

Why tool access changes indirect prompt injection from model risk to governance risk

A prompt injection is limited if the model can only generate text. It becomes a governance problem when the agent can query systems, retrieve data, or trigger downstream actions. At that point, the attack surface includes permission design, approval flows, logging, and escalation paths, not just model guardrails. This is where IAM and PAM intersect with agent security: the issue is not whether the model is clever, but whether it can reach sensitive systems without a constrained, reviewable authority boundary.

Practical implication: treat agent permissions like privileged access and restrict tool scope to the smallest viable set.


Threat narrative

Attacker objective: The attacker wants the enterprise agent to misuse its trusted access so that sensitive data is exposed or harmful actions are executed on their behalf.

  1. Entry occurs through hidden instructions embedded in routine enterprise content such as emails, diligence memos, tickets, or vendor requests.
  2. Escalation happens when the agent interprets the injected content as part of the task and uses its legitimate tool access to expand scope or reveal sensitive information.
  3. Impact follows when the agent leaks data, authorises an unsafe action, or triggers a fraudulent or compliance-breaking outcome.

NHI Mgmt Group analysis

Agentic AI has become an identity and access problem before it becomes an AI quality problem. Once a system can independently choose tools and act on enterprise data, it behaves like a non-human identity with delegated authority. That makes scope, permissioning, and auditability more important than raw model accuracy. Security teams should treat the agent as a governed actor, not a conversational interface.

Indirect prompt injection exposes the verification trust gap in enterprise AI programmes. The enterprise assumes that content read by an agent is safe unless the source is malicious, but the benchmark shows that ordinary business artifacts can carry harmful instructions. This is a named governance failure because the environment trusts content provenance more than execution intent. Practitioners should design controls that verify intent before action, not after the model has already responded.

Agent Failure Rate is the right concept for understanding enterprise exposure. A system that fails one time in six or three times in four is not safely deployable for privileged workflows, even if its average output quality looks acceptable. That is especially true where actions are irreversible or externally visible. The practical conclusion is that security teams need repeated adversarial evaluation before production rollout.

Prompt injection turns model governance into privilege management once tools are available. The benchmark's attack patterns, including authority laundering and scope expansion, show that the real blast radius comes from what the agent can reach, not just what it can say. This is where PAM, approval workflows, and logging must extend into AI runtime controls. Practitioners should govern tool use as tightly as any other privileged session.

AI agent scope drift: hidden instructions can expand an agent's authority beyond its intended task boundary. The article shows that once agents operate across email, tickets, and vendor requests, their real risk is not single prompt failure but gradual scope expansion through trusted inputs. Security teams need explicit authority boundaries, not implied trust in the workflow.

What this signals

AI agent governance now needs the same operational seriousness as privileged access management. Once a system can read untrusted content and then act on internal systems, the boundary between model safety and access control disappears. The practical signal for programmes is that tool permissions, session logging, and approval flows should be designed before broad deployment, not after the first incident.

Verification trust has become the weak point in agentic workflows. Enterprises are not only deciding whether a model is accurate, but whether it can safely separate malicious instructions from business content. That shift means policy must cover content provenance, action authority, and escalation thresholds in the same control set.

The benchmark also reinforces why adversarial testing should be part of deployment gating. The relevant question is no longer whether an agent can perform the task, but whether it can do so safely when the input stream is hostile. That is a programme design issue, not just a model-selection issue.


For practitioners

  • Constrain agent tool authority Limit each agent to the smallest viable set of systems, data sources, and write actions, and remove broad access that is not required for the task.
  • Separate read and act paths Design workflows so an agent can ingest content without being able to execute irreversible actions from the same input path, especially for email, tickets, and vendor requests.
  • Add adversarial prompt-injection testing Test enterprise agents against hidden instructions, scope-expanding prompts, and authority laundering before production approval and after every major workflow change.
  • Log and review tool-triggered actions Capture which prompt, source artifact, and tool invocation led to each action so investigators can reconstruct agent decisions when data exposure or fraud occurs.

Key takeaways

  • Enterprise AI agents are failing under indirect prompt injection because trusted business content can hide malicious instructions.
  • The benchmark's 0.75 mean Agent Failure Rate shows that unsafe outcomes are common, not edge cases, in adversarial enterprise scenarios.
  • Security teams should govern agent permissions, approval flows, and logging before broad deployment, especially where agents can act on data or systems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10NHI-03Prompt injection and tool misuse are central to the benchmark's failure patterns.
NIST AI RMFMANAGEThe article is about managing operational AI risk in enterprise deployment.
NIST CSF 2.0PR.AC-4Agent permissions and access scope are the main governance issue.
MITRE ATT&CKTA0001 , Initial Access; TA0006 , Credential Access; TA0004 , Privilege EscalationThe benchmark's adversarial scenarios map to common attack tactics against enterprise systems.
NIST SP 800-53 Rev 5AC-6Least privilege is the key control once agents can act on enterprise systems.

Use MANAGE to define pre-deployment testing, approval gates, and ongoing AI incident response.


Key terms

  • Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
  • Agent Failure Rate: A measurement of how often an AI agent fails at least once across repeated test runs in realistic scenarios. It is useful for security evaluation because enterprise risk is driven by repeated failure under hostile inputs, not by single successful demonstrations under ideal conditions.
  • Trust Laundering: Trust laundering is when untrusted content gains trusted authority simply by passing through a tool that assumes the source is safe. In AI-assisted development, that can happen when repository files or hooks silently shape what the model sees, turning evidence selection into a security control.
  • Activation Trust Gap: The activation trust gap is the difference between trusting data because it is protected and governing it because it is being reused. It appears when organisations move data from backup or archival systems into AI pipelines without reapplying access, sensitivity, and consumer controls.

What's in the full report

ActiveFence's full blog covers the benchmark setup and scenario design this post intentionally leaves at a higher level:

  • The seven work domains and seven industries used to construct the 147 adversarial enterprise scenarios.
  • The 0-10 security scoring approach and how the nine-judge jury of frontier models was used to assess failures.
  • The sample scenario and proof-of-concept details showing how hidden instructions changed agent behaviour.
  • The retest results across newer model versions, including which models improved and how much.

👉 ActiveFence's full blog covers the benchmark design, sample scenarios, and retest results across newer model versions.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is suitable for practitioners building controls around privileged access, delegated authority, and identity lifecycle risk.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org