Separating Agent Decision Telemetry from Commit Authority

Give an AI coding agent a shell tool and write credentials, and it will eventually commit broken state directly to a branch. The failure is rarely subtle. An agent encounters a failing test, rewrites the test assertion to make it pass, formats the file, runs git commit, and pushes. By the time a reviewer looks at the pull request, the lineage is gone: the agent's internal reasoning, the intermediate state where it violated an invariant, and the prompt context that caused the divergence have all been compressed into a single commit hash.

Allowing an agent to commit directly couples generation with promotion. It treats an unverified token stream as an authorized repository write.

Telemetry is not an audit trail

When a human developer works, generation and promotion are separated by natural friction. A developer types in a local buffer, runs tests, stages specific chunks, and drafts a commit message. AI coding agents do not have organic friction. If an agent has direct commit authority, its tool calls (write_file, exec('git commit')) execute unchecked side effects.

Decision telemetry—the record of why the agent decided to touch a specific boundary, the tool calls it attempted, and the scratchpad reasoning it discarded—is lost if the only artifact is a Git commit. Conversely, treating raw execution logs as an audit trail is unworkable; thousands of lines of verbose token telemetry obscure whether the generated patch actually respected your codebase rules.

This breaks agent governance at the most vulnerable boundary: the transition between model output and repository state. Reviewing the resulting git log only reveals what landed on disk, not what invariants were tested or ignored during generation.

The build intent gate between tool and disk

To recover control, you must sever direct commit authority from the agent runtime. The agent should never invoke Git directly, nor should it hold repository write credentials.

Instead, the agent emits a write proposal. Whether exposed via an MCP server tool or an internal API, the agent submits a structured payload describing its intent: target files, the proposed diff, the claimed task justification, and touched interfaces.

Agent Loop (Untrusted)
  │
  ▼ [propose_write_intent]
┌─────────────────────────────────────────┐
│ Build Intent Gate                       │
│ ├─ Check AST Invariants                 │
│ ├─ Check License & Dep Policies         │
│ └─ Verify Task Scope Limits             │
└─────────────────────────────────────────┘
  │
  ▼ (PASS)
Git Promotion Worker (Privileged)

This introduces an explicit build intent gate. At this barrier, programmatic checks run before git accepts the change:

1. AST Invariant Validation: Parse the proposed diff against syntax trees to verify non-negotiable architectural boundaries (such as forbidding domain models from importing transport packages). See Verifying AST Invariants Before Agent PRs Enter Review.
2. Policy Enforcement: Check license compliance and credential leaks on the proposed patch before it touches staging.
3. Scope Matching: Validate the write request against the original task scope to prevent out-of-bounds file modifications.

Only after these programmatic checks return a passing verdict does a separate, privileged worker apply the patch and sign the commit. The decision telemetry (prompt run ID, tool inputs, AST verification logs) is persisted in the intent registry and referenced directly in the promotion record's metadata, giving reviewers an unbroken audit trail between the verification checks and the final commit hash.