Audit Agent Write Intent Logs to Detect Unauthorized Proposals

When an autonomous agent mutates a repository, inspecting the resulting Git diff tells you what happened. It does not tell you what the agent attempted to do three seconds earlier, which policy checks it evaluated, or how many unauthorized proposals failed before one slipped through.

Treating the pull request as the first audit checkpoint is too late. If governance starts at the merge queue, you have no visibility into the decision loop. An agent running in an IDE or a CI worker can iterate through dozens of unsafe file writes, dependency additions, or license violations before producing a clean-looking patch.

To establish true software governance over automated contributors, you must capture and analyze the structured intent emitted before the disk or git index mutates.

The structure of a Build Intent record

When an agent requests a file write, package resolution, or scaffolding operation through an interface like MCP access, the request should register as an explicit proposal. The gate evaluates invariants—such as path allowlists, license constraints, and schema conformance—and yields a terminal state before any byte is written.

That exchange generates an immutable entry in your agent write logs. A minimal structured log contains the agent identity, the target surface, the evaluated policy assertions, and the gate verdict:

{
  "timestamp": "2025-02-14T08:12:04.112Z",
  "proposal_id": "prop_8f92a1c0",
  "agent_id": "refactor-worker-04",
  "session_id": "sess_99b3e1",
  "action": "write_file",
  "target_path": "src/auth/session.ts",
  "invariants": {
    "path_allowed": true,
    "license_compatible": true,
    "schema_conformance": "pass"
  },
  "verdict": "REJECTED",
  "reason": "POLICY_VIOLATION: prohibited import 'crypto-js' (use platform webcrypto)"
}

If the gate returns REJECTED, the tool call halts. The mutation is aborted in memory. Crucially, the rejection is recorded in the audit trail alongside the exact payload the agent proposed.

Surfacing evasion and systematic drift

Collecting intent logs is mechanical; extracting signal requires looking for specific behavioral patterns. Three failure modes consistently appear when analyzing agent write intent:

1. Repeated brute-force evasion

When an agent encounters a rejected write, its context window updates with the error string. LLMs frequently attempt to circumvent the failure by rephrasing the file write—for example, moving an unauthorized utility function from a banned dependency into an unmonitored local helper, or writing to /tmp instead of the approved module path.

Querying agent write logs for high rejection-to-acceptance ratios within a single session_id exposes prompt loops that are actively attempting to bypass your repository policies.

2. Out-of-bounds mutation attempts

Agents tasked with a narrow objective (such as fixing a unit test in tests/unit/) often attempt to modify configuration files, CI workflows, or lockfiles to make the build pass. By auditing rejected proposals where path_allowed evaluated to false, security teams can identify whether an agent's runtime environment granted broader tool access than its operational scope required.

3. Policy bypass attempts

In layered environments where agents can call raw filesystem tools alongside governed synthesis tools, you must detect drift between proposed intent and disk state. Comparing the sequence of approved intent proposals against the final commit tree reveals whether an agent bypassed the gate entirely by calling uninstrumented primitives. This posture relies on separating agent proposals from repository mutation gates.

Running the log analysis pipeline

You do not need a bespoke telemetry stack to audit write intent. Treat intent logs like security events:

1. Emit structured JSON to stdout/syslog from the MCP server or local proxy mediating tool calls.
2. Route records to your standard log aggregator (such as CloudWatch, Datadog, or an internal ClickHouse cluster).
3. Alert on anomalous terminal states. Set thresholds for:

• More than 3 REJECTED verdicts in a single agent task run.
• Any attempt to write to protected paths (.github/, root configuration files, credentials manifests).
• Any proposal containing non-compliant software licenses or prohibited dependencies.

A simple log aggregation query can highlight unstable agent runs across CI workers:

SELECT
  agent_id,
  count(*) AS total_proposals,
  count(*) FILTER (WHERE verdict = 'REJECTED') AS rejections,
  round(count(*) FILTER (WHERE verdict = 'REJECTED')::numeric / count(*), 2) AS rejection_rate
FROM agent_write_logs
WHERE timestamp > now() - interval '24 hours'
GROUP BY agent_id
HAVING count(*) FILTER (WHERE verdict = 'REJECTED') > 5
ORDER BY rejection_rate DESC;

This query identifies agents that are thrashing against constraints, allowing platform teams to adjust the prompt instructions, update repository permissions, or revoke the agent's credentials before unauthorized changes reach review.

What to ship on Monday

Audit what your agents are proposing before you worry about what they are committing.

1. Instrument the gate. Ensure your agent tooling routes file modifications through a single MCP interface or middleware layer that records every intent payload and policy evaluation.
2. Log terminal verdicts. Make certain that rejections, failed invariant checks, and outright permission denials are emitted with full context, not swallowed silently by the agent client.
3. Set up one alert. Trigger a notification whenever an agent generates more than three policy-rejected write attempts within a single run. Use those logs to tighten the policy gate before code reaches the repository.