AI Coding Agents Don't Drift Randomly: They Drift at Permission Gaps

AI coding agents do not drift randomly. They drift when capability questions get treated as implementation details instead of planning gates.

The questions are simple:

• What can this tool touch?

• What boundary does this cross?

• What proof do I need before the agent acts?

This article walks through six patterns of agent drift, all from real build sessions, and shows how a non-coder builder can prevent them with explicit guardrails before the agent ever gets permission to act.

The Setup

I build real apps with AI coding agents. I am not an engineer. For the first few months, I thought project drift was a random bug.

The drift looked like this:

• The agent rewrote files I did not ask about.

• It made architectural choices I never approved.

• It claimed safety it could not prove.

I would roll back, restate the prompt, and try again.

I was wrong. The drift followed a clear pattern: every time the agent drifted, there was an unanswered capability question the agent filled in with its best guess.

What Went Wrong: Six Patterns of Permission-Gap Drift

1. Tool changes are capability changes, not documentation updates.

The agent proposed adding a new tool surface: filesystem access it had not had before. I treated it as a configuration detail. The agent treated it as permission granted. It immediately began reading and writing files outside the scope I intended, because the new tool surface removed a boundary I had not rebuilt.

The lesson: a new tool, script, or access path is not a setup step. It is a capability change. Before handing it over, ask what doors it opens.

2. Implementation readiness is not the same as trust readiness.

The agent identified a practical next step: writing files deep in my project structure. Technically simple. Ready to execute.

But I missed the trust questions:

• Does the agent understand the security boundary?

• Does it know what not to change?

• Does it know when to stop?

I let implementation readiness override planning. The agent did the work correctly, but it also touched adjacent files I had not reviewed. The scope was never defined.

The fix: before the agent acts near a trust boundary, define the boundary, the scope, the proof it must produce, and the stop rule.

3. Backup is not the same as verified restore.

An agent told me a data migration was safe because it had created a backup. That sounded reasonable. I approved it.

The migration ran, something failed partway through, and the restore path was untested. The agent had verified neither that the backup could actually be restored, nor that the migration could be rolled back from a partial state, nor that a forward-fix existed if the rollback itself failed.

The missed question: separate "the happy path worked" from "recovery is verified." Do not accept backup existence as proof of restore. Ask what happens after partial progress, what restores the data, who makes the stop decision, and what proof was actually run.

4. When you hand off work, shut down the old agent.

I once built a workflow where one agent would do the heavy lifting, then hand the remaining task to a second agent. The handoff instructions told the second agent to take over. The first agent's instructions never told it to stop. Both agents kept working on the same scope, creating overlapping changes and conflicts.

The capability question: when a skill or workflow delegates a task to another agent, does the delegating agent have an explicit instruction to stop working on that scope? Without it, the handoff itself creates drift.

5. Extract the habits, not the framework.

I found a large agent-skills repository with hundreds of files, careful methodology, and detailed workflows. I was tempted to copy the whole thing.

The durable value was not the framework. It was a few repeated habits:

• review patterns

• scope-checking rules

• verification steps

Those habits appeared across every workflow. Copying the whole framework would have imported complexity I did not need. Extracting the five or six highest-signal habits gave me the same protection with a fraction of the weight.

6. Boundaries break in layers you cannot see from the top.

One review session surfaced four different boundary failures:

• malformed data escaping intended error paths

• a fallback reading from wrong source fields

• explicit null values silently overwritten by defaults

• a workflow summary tracking the wrong state

None were visible from the agent's top-level summary. Each was a boundary contract broken one layer down: this field means this, this path goes here.

The missed question: do not verify only what the agent summarizes. Verify at the boundary itself. Check the actual data flowing across the contract, not just the agent's report.

The Pattern Behind All Six

Every failure happened because I treated a capability question as an implementation detail to figure out later.

The questions I should have answered first:

• What can this touch?

• What boundary does this cross?

• Who stops when?

AI coding agents are not careless. They are literal. When you do not tell them where permission ends, they infer it from the only signal available: "I can reach this, so I am allowed to touch this."

Guardrails are not about restricting the agent. They are about making boundaries explicit before the agent has permission to act.

The Practical Workflow

Here is the guardrail pattern I use now, before any agent session that touches files, data, or another agent:

1. Classify capability changes. Does this introduce a new tool, access path, trust boundary, or agent handoff? If yes, plan it before implementing.

2. Define boundary, scope, proof, and stop rule. Write down: what the agent can touch, what it cannot, what proof it must produce that it stayed in bounds, and what condition means stop and ask.

3. Separate success from recovery safety. When the agent claims safety from backup or success, ask: was restore tested? what happens after partial progress? who owns the stop decision?

4. Close handoff loops. When handing work to another agent, the delegating instructions must include an explicit stop on the original scope.

5. Verify at the boundary, not at the summary. Check the actual data flowing across contracts, not just the agent's report about them.

6. Extract habits, not frameworks. Pull out the two or three durable patterns; leave the rest.

Takeaways

• AI coding agents drift at permission gaps: unanswered questions about what they can touch and when they must stop.

• Tool changes, new access paths, and trust-boundary work are capability changes, not implementation details. Plan them first.

• Backup existence is not verified restore. Migration success is not verified rollback. Separate "it worked" from "recovery works."

• The best guardrails are explicit answers to "what are you allowed to do, and how will you prove you stayed in bounds?"

Call to Action

If you are building with AI coding agents, try this before your next session: write down one capability question the agent must answer before it acts. If you cannot define the boundary yet, do not give the agent permission to start. I would like to hear what question you write.

Reply or tag me with it.