Coerced Execution

Expanded Definition

Coerced execution describes a control failure where a legitimate workload, service, script, or agent carries out an attacker’s instruction while still appearing authenticated and authorized. The key distinction is that the identity has not been stolen in the usual sense, and the permissions may be unchanged, but the decision path has been manipulated. In practice, this sits between classic compromise and pure misuse: the system is still “itself,” yet it is no longer acting on behalf of the intended owner or workflow.

This term is especially relevant in environments where software has execution authority, tool access, or delegated trust, including automation pipelines, privileged service accounts, and AI agents. The concept aligns closely with the governance and detection themes in NIST Cybersecurity Framework 2.0, because the defensive challenge is not just blocking login abuse but recognising when trusted activity has been redirected at runtime. Definitions vary across vendors on whether coerced execution is treated as a subset of misuse, injection, or command manipulation, and no single standard governs the term yet.

The most common misapplication is treating it as a normal authorization issue, which occurs when teams focus on who has access instead of whether the runtime instruction itself has been subverted.

Examples and Use Cases

Implementing detection for coerced execution rigorously often introduces runtime inspection and policy complexity, requiring organisations to weigh tighter behavioural control against additional monitoring overhead and false positives.

• A workflow agent receives a malicious prompt that causes it to send data to an external endpoint using its own valid credentials.
• A privileged automation script is redirected through argument injection so it performs an approved action in an unapproved context.
• A cloud-native service account is induced to call internal APIs outside its normal business logic, making the event look like routine machine traffic.
• An AI assistant with tool access is manipulated into chaining actions that were never intended by the operator, even though each tool call is technically permitted.
• A scheduled job is coerced through configuration tampering so it executes attacker-chosen commands while preserving its formal identity and logging profile.

For teams building safeguards around agentic systems, the OWASP Agentic AI Top 10 is useful for understanding how instruction manipulation and unsafe tool use can produce this failure mode. The same risk pattern also appears in service automation and NHI-heavy environments, where SPIFFE identity concepts help separate workload identity from runtime intent.

Why It Matters for Security Teams

Coerced execution matters because it breaks a common assumption in security operations: that authenticated activity is therefore trustworthy. Once an attacker can redirect a legitimate workload, the usual signals of compromise may disappear, and controls built around static identity, tokens, or role checks can all report a false sense of safety. That is especially important for NHI governance, where service accounts, API keys, certificates, and agent credentials often have standing permissions that make misuse difficult to distinguish from business-as-usual activity.

For practitioners, the operational response is to bind identity to context, constrain what a workload may do at runtime, and monitor for instruction-level anomalies rather than only access failures. The CISA Secure by Design guidance reinforces the value of making systems resilient to misuse paths that exploit trusted behaviour, while NIST AI Risk Management Framework thinking is relevant where AI agents are involved. Organisations typically encounter coerced execution only after an apparently valid workload exfiltrates data, triggers an unsafe action, or propagates abuse through trusted automation, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When should organisations sandbox code execution in agentic platforms?
• What is the difference between prompt injection and LLM remote code execution?
• Install-Time Execution
• Pre-execution Authorization