What breaks when AI agents can create and approve the same output?

Why This Breaks More Than Approval Workflow

When an AI agent can both create and approve the same output, the control failure is not just procedural. It collapses segregation of duties, removes independent review, and turns a business safeguard into a self-confirming loop. That matters because agentic systems can chain tools, act at machine speed, and repeat the same mistake across many transactions before a human notices.

This is exactly the kind of failure path discussed in the OWASP Agentic AI Top 10 and in NHI research such as AI Agents: The New Attack Surface. NHIMG’s research notes that 80% of organisations say their AI agents have already performed actions beyond intended scope, which is a strong signal that autonomous approval paths are already being abused or misused in production. Once creation and approval sit inside the same agentic loop, policy drift becomes hard to spot and harder to prove.

Security teams often assume the approval step still exists because a workflow contains an approval state. In practice, many security teams encounter broken SoD only after an agent has already authorised its own output and the audit trail no longer shows a meaningful second check.

How It Should Be Designed Instead

The practical fix is to separate the actor that prepares a business action from the actor that validates it. For autonomous systems, that usually means the agent can draft, but a distinct policy engine or human approver must release. The current guidance from NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework is to treat autonomy as a governance boundary, not just a productivity feature.

In practice, that means:

• Use separate identities for generation and approval, with no shared token or session.
• Issue short-lived, task-scoped credentials so the agent cannot reuse approval authority later.
• Require runtime policy evaluation for every release decision, rather than pre-approved blanket access.
• Preserve immutable logs that show who, or what, proposed the action and who approved it.
• Route high-risk actions through a human or independent control plane when impact is material.

For agent workloads, workload identity matters more than static role assignment. A cryptographic identity from systems such as SPIFFE or OIDC can prove what the agent is, but that still does not mean it should approve its own actions. NHI guidance on agent behaviour in OWASP NHI Top 10 and the Ultimate Guide to NHIs emphasises that identity and authority are not the same thing. This is especially important when agents can generate invoices, code changes, or access decisions and then immediately sign off on them. These controls tend to break down when organisations let the same orchestration layer own both the approval state and the enforcement state because the audit record becomes circular.

Common Variations and Edge Cases

Tighter segregation often increases operational overhead, requiring organisations to balance throughput against control assurance. That tradeoff is real, especially in fast-moving environments where every approval hop can slow delivery.

There is no universal standard for this yet, but best practice is evolving toward compensating controls when full separation is impractical. Examples include restricted approval scopes, independent policy-as-code checks, or delayed release for sensitive actions. The key is that the approval path must be verifiable and outside the agent’s direct control. If the agent can modify the policy, simulate the approver, or reuse the same secret, the control is only cosmetic.

This becomes more difficult in multi-agent pipelines, where one agent drafts, another critiques, and a third executes. That architecture can look independent while still sharing the same trust boundary. NHIMG’s reporting in Moltbook AI agent keys breach and the vendor research in AI Agents: The New Attack Surface both underscore the risk of broad, reused access in agentic environments. In highly regulated workflows, the safest answer is still to keep the approver outside the agent’s execution path, because self-approval is a control failure even when the workflow engine says “approved.”

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• Why do AI agents create more risk when they reuse existing credentials?
• Why do AI agents create more IAM risk than ordinary developer tools?
• Why do AI agents create a different access-risk profile than traditional applications?