What Happens When Your AI Coding Assistant Does Something You Didn't Approve

Published: 2026-03-21

AI coding tools that operate with approval workflows follow a general model: the tool proposes an action, a human reviews it, and if approved, the action executes. This model assumes that the human is approving the actual action that will occur.

In AI agentic systems, tools can modify their proposals after approval—changing arguments, target files, or execution context. This is not necessarily malicious. It can result from the model discovering a better approach during the approval process, responding to new context, or recovering from an error.

The result is the same regardless of intent: the action that executes is not the action that was approved.

How argument drift occurs

The distinction matters because most approval systems bind approvals to natural language descriptions. A prompt like "add user authentication to the login endpoint" might be approved, but the actual implementation could differ significantly from what the approver expected.

The differences can be subtle:

• The approved action was "refactor the auth module" but the AI also modifies three unrelated files
• The approved action was "add validation" but the AI replaces an existing validation library
• The approved action was "fix the bug" but the AI refactors the entire subsystem

In each case, the high-level description matches, but the actual changes diverge. This is not a hypothetical concern. It is a documented behavior in AI coding tools that has led to unexpected code changes in production systems.

Why natural language approval is insufficient

Approving on natural language descriptions creates a semantic gap between what was approved and what executes. The approver evaluates intent; the AI executes based on implementation decisions made after approval.

The gap exists because:

• Natural language descriptions are underspecified by design
• AI tools retain decision-making authority after approval
• Implementation choices are not reversible through the approval interface
• The human approver cannot see the actual code changes until after execution

What approval binding means

Approval binding is a mechanism that ties approvals to exact execution arguments rather than natural language descriptions. When an approval is issued, it is bound to a cryptographic digest of the specific action parameters—the exact files, arguments, and context that will be used at execution time.

At execution time, the control plane compares the digest of the proposed action against the digest of the approved action. If they differ—regardless of how similar the descriptions may be—the action is denied.

This does not prevent AI tools from proposing changes or discovering better approaches. It ensures that when an AI modifies its approach after approval, the modification is visible as a new action that requires a new approval.

What this does not prevent

Approval binding addresses a specific risk vector: the gap between approved intent and executed action. It does not address:

• Whether the human approver understands what they are approving (AI literacy remains the approver's responsibility)
• Whether the approved action is itself harmful (approval binding does not evaluate action content)
• Prompt injection attacks that occur before the approval request (injection in repository content, emails, documents)
• Execution that bypasses the control plane entirely (direct execution paths are outside governance scope)

Approval binding is one control in a governance system. It does not replace security reviews, code analysis, or human judgment.

FAQ

How does approval binding differ from traditional code review?

Code review evaluates changes after they are written but before they merge. Approval binding evaluates actions before they execute. The key difference is timing: binding operates at execution time, not at commit time.

Can approval binding prevent all unauthorized actions?

No. Approval binding only covers actions that route through the control plane and that have corresponding approvals. Actions that bypass the control plane, actions without defined approval requirements, and actions taken during degraded or offline mode are outside the scope of approval binding.

What happens when arguments change by accident?

When the digest of the proposed action does not match the approved digest, execution is denied and a digest mismatch event is recorded. Through the Syndicate Code TUI, a new approval request can be initiated with the updated arguments, and the human approver can evaluate the modified action.

Does approval binding slow down development?

Approval binding adds a verification step at execution time. This verification is a deterministic comparison of cryptographic digests and takes milliseconds. The latency is not in human review time but in the control plane's digest comparison. Human review time for the initial approval request is unchanged.

How does digest comparison work?

A SHA-256 hash is computed over the normalized action arguments at approval time and at execution time. The control plane stores the approved digest and compares it against the computed digest of the proposed action. Constant-time comparison is used to prevent timing attacks on the digest values.