A harness weakness where content, paths, or tool definitions change after a human has approved them. The approval is still valid on paper, but the executed action is no longer the same object the reviewer saw. This can redirect a benign action into configuration changes, code execution, or data exfiltration.
What Post-Approval Mutation Means in Practice
Post-approval mutation is a control-break problem, not just a workflow quirk. The reviewer approved one object, but the runtime system later swaps in different content, a different path, or a different tool definition, so the executed action no longer matches the reviewed one.
This matters because approval usually assumes stable intent. If the approved object can still change, the approval decision no longer provides meaningful assurance about what will actually run, touch, or exfiltrate data.
How the Mutation Happens
Mutation can occur through late binding, shared references, indirect file or URL targets, mutable tool registries, or configuration that is editable after review. In practice, the user sees a benign artifact at approval time, then a different artifact is resolved at execution time.
The weakness often sits between the review surface and the execution surface. A workflow may validate the displayed item, but fail to lock the underlying resource, version, digest, or parameters that define the real action.
That gap is especially dangerous in systems that support tool chaining, content rendering, code execution, or external fetches. A harmless-looking request can be redirected into a materially different operation without triggering a fresh human decision.
Why It Breaks Approval Integrity
Approval is only meaningful when the approved object is the executed object. Post-approval mutation breaks that chain of custody, so the human decision becomes a weak signal rather than a reliable control.
For security teams, the core issue is object identity, not user intent. If the artifact can mutate after sign-off, a benign review can be converted into configuration drift, unauthorized execution, or data exposure while preserving the appearance of compliance.
This is why immutable references, content addressing, and execution-time verification are central design ideas for this class of weakness. Without them, the system is relying on trust in something that was never frozen.
Where the Security Boundary Fails
Post-approval mutation usually crosses a boundary between authorization and execution. The reviewer authorizes one thing, but the system later dereferences a broader or different capability, which can expand impact far beyond the approved scope.
NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because this weakness sits at the intersection of access control, configuration management, auditability, and system integrity. The same is true of NIST Cybersecurity Framework 2.0, which frames the need to govern, protect, detect, and respond to changes that alter trust in an approved action.
When the mutation affects a tool or API-driven workflow, the failure can resemble broken authorization at the action layer. That is why OWASP API Security Top 10 and OWASP Agentic AI Top 10 are useful references for the underlying exposure pattern, especially where tool use or delegated action can change after approval.
Risk and Threat Considerations
Post-approval mutation creates a high-trust attack path because it lets an apparently reviewed action diverge from the reviewed object. That can turn a normal approval workflow into a delivery mechanism for unauthorized configuration changes, code execution, or data exfiltration.
Failure mechanism: the system validates an approved reference, but execution resolves a mutable target, so the live action differs from the reviewed artifact or parameters.
Impact: defenders lose confidence that approval actually constrained the executed outcome, which can enable privilege misuse, hidden control bypass, or silent malicious redirection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Post-approval mutation is a change-control failure that alters an approved object after review. |
| SI-7 — Software, Firmware, and Information Integrity | Mutation after approval undermines integrity of the executed content or tool definition. | |
| AC-3 — Access Enforcement | The weakness can redirect an approved action into a broader or different operation. | |
| Recommendation — Require controlled change approval and lock the executable object before execution. Verify integrity of the exact artifact at execution time, not only at review time. Enforce runtime authorization on the final resolved action, path, or tool target. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management, Least Privilege and Role-Based Access Control | Approval drift can expand the effective privilege or action beyond what was reviewed. |
| Recommendation — Apply least privilege to the final execution path and deny any post-review expansion. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | A reviewed action can mutate into a different function than the one authorized. |
| Recommendation — Authorize the specific function that will execute, not just the submitted request shape. | ||
Practitioner Guidance
What to watch for: Any workflow where a human approves a pointer, label, template, or path rather than the final immutable artifact deserves close scrutiny. Review is weakest when the system can still rewrite the target after sign-off.
Governance implication: Treat the approved object and the executed object as the same control requirement, not as separate steps. If your design cannot prove that continuity, the approval is operationally incomplete even if the UI says it succeeded.
Practitioner takeaway: The control objective is not merely “human approved,” but “the exact approved artifact is what executed.”