A coerced action is a legitimate tool call or write made by an AI agent for the wrong reason. The permission check passes, but the instruction came from attacker-controlled or untrusted content. This shifts detection from access control to runtime behavior, comparison, and policy evidence.
Expanded Definition
Coerced action describes a failure mode in agentic systems where an AI agent performs an allowed tool call, API request, or state change because untrusted content has shaped its decision process. The key issue is not broken authorization, but malicious influence over intent formation. In practice, the agent may satisfy permission checks while still acting on attacker-controlled prompts, retrieved content, email text, web pages, or tool output. This makes coerced action a runtime security problem rather than a static access control problem.
Definitions in the industry are still evolving, but the term is increasingly used to distinguish safe-looking execution from trustworthy execution. That distinction matters because a successful policy check can hide the fact that the agent was socially engineered by content it should not have treated as instruction. NHI Management Group treats this as a control-evidence issue as much as a logic issue: defenders need to know not only what the agent did, but why it decided to do it.
For governance and control mapping, this aligns closely with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organizations must evidence that actions are authorized, attributable, and monitored. The most common misapplication is treating coerced action as a simple permission failure, which occurs when teams assume a valid authorization result proves the agent acted for the right reason.
Examples and Use Cases
Implementing protections against coerced action rigorously often introduces added inspection and policy-evidence overhead, requiring organisations to weigh agent autonomy against the cost of stricter runtime verification.
- An email triage agent is told by an attacker-crafted message to forward a sensitive attachment to an external address. The send action is permitted, but the instruction source is malicious.
- A support agent reads poisoned ticket text that instructs it to reset a customer setting. The API call succeeds, yet the action was induced by untrusted content rather than legitimate operator intent.
- A retrieval-augmented generation workflow pulls a hostile web page into context, and the agent follows embedded directives to create a new secret or rotate a token incorrectly. The tool permission is valid, but the reasoning path is compromised.
- An operations agent uses a maintenance tool after reading a tampered log entry that frames the action as urgent. The write is allowed, but the underlying prompt evidence is adversary-controlled.
- A planning agent chains several legitimate tool calls after receiving a crafted document that nudges it toward data exfiltration. Each call passes checks individually, but the sequence reflects coerced execution.
Teams studying this pattern often also look to OWASP Top 10 for Large Language Model Applications because prompt injection and instruction hijacking are common precursor conditions. The practical lesson is that the source of the instruction must be validated as carefully as the destination of the action.
Why It Matters for Security Teams
Coerced action matters because it exposes a blind spot in conventional access control. A system can appear compliant while still being operationally unsafe if it cannot distinguish user intent, tool policy, and attacker-supplied instruction. That gap is especially relevant in agentic AI, where software entities can browse, write, call APIs, and trigger workflows with real execution authority. Security teams need runtime controls that compare action context against trusted policy evidence, not just static allowlists.
This is also where identity and NHI governance intersect. When an AI agent has its own credentials, tokens, or delegated privileges, coerced action can turn a legitimate NHI into an attacker-amplified actor. That means logging, provenance, step-up approvals, bounded scopes, and content trust boundaries become part of the identity control plane. Guidance in OWASP Non-Human Identity Top 10 is useful here because it highlights how machine identities can be overextended or abused when their execution context is not constrained. For broader AI risk management, NIST AI Risk Management Framework helps teams connect governance, measurement, and monitoring to real-world system behavior.
Organisations typically encounter the business impact only after an agent has already sent the wrong email, changed the wrong record, or exposed the wrong secret, at which point coerced action becomes operationally unavoidable to address.
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 OWASP Non-Human Identity Top 10 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.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic AI guidance covers prompt injection and unsafe tool use that can drive coerced action. | |
| OWASP Non-Human Identity Top 10 | NHI controls address misuse of machine identities when an agent is induced to act. | |
| NIST AI RMF | AI RMF governs trustworthy AI behavior, including monitoring and validation of actions. | |
| NIST CSF 2.0 | PR.AC-4 | Access control is relevant because coerced action exploits valid permissions in unsafe ways. |
| NIST SP 800-53 Rev 5 | AU-12 | Audit generation supports evidence of what the agent did and why it did it. |
Treat untrusted instructions as hostile input and verify tool actions against trusted policy evidence.
