Trace the integration test that already exercises the protected workflow.
Give AI coding agents a memory for critical workflow behavior.
DriftFence turns one critical workflow into an approved contract in Git. Coding agents see the guardrails before they edit, CI checks fresh traces before merge, and a failed check gives the agent the context to revise the patch instead of guessing. Intentional behavior changes still move through human contract review.
release-it.private-package-lockfile-bump
Before the agent edits
context queryconfig/release.ts
Protected by one approved release contract.
scripts/publish.ts
Package-publishing behavior requires review.
agent instruction
Preserve approved publish commands and metadata.
merge rule
Contract changes move through normal Git review.
$ driftfence query --files config/release.ts
$ driftfence agent-install --host codex
At merge time
.driftfence/check-report.mdThe repo's release tests still pass.
Recorded behavior no longer matches the approved contract.
expected output.commands.npm = 1
observed output.commands.npm = 0
Read the report, query approved constraints, revise the patch, or request contract review for intentional behavior changes.
The workflow firewall loop.
One source of truth moves through the whole change path: test trace, Git contract, agent context, and CI report.
Accept the generated contract through the same ownership path as code.
Agents ask which approved workflows apply before touching protected files.
If CI reports drift, the agent reuses the same constraints and report to revise the patch or request contract review.
CI compares fresh traces to the approved contract before merge.
DriftFence MCP is the bridge between approved contracts and agent hosts. Before protected edits, the agent can ask which workflows apply and what behavior must not drift. After a failed check, the same constraints and report help the agent revise the patch or ask for human contract review. MCP does not approve behavior changes or write contracts.
How the first workflow gets protected.
The first setup is intentionally small: choose one risky workflow, record the behavior already exercised by CI, approve the contract in Git, then give agents and reviewers the same source of truth for edits, revisions, and approvals.
Start with the workflow where silent behavior drift would create real review or operational cost.
npm install -D @driftfence/cli @driftfence/sdk
npx driftfence init --template release-npm
Capture the effects, emitted events, outputs, or state matchers that define the approved workflow behavior.
npx driftfence draft
npx driftfence accept
npx driftfence agent-install --host all
Optional read-only MCP support can expose the same approved context where your agent host supports it, including after a failed check when the agent needs to revise the patch.
npx driftfence check --mode enforce
The GitHub Action writes the report reviewers use when protected behavior changes.
Measured proof for the CI gate.
The results page shows fixed public GPT-5.5 tasks where DriftFence caught approved-behavior changes while the repos' own checks still passed. That evidence is for the contract gate today; the first private pilot validates the complete agent workflow.
Model-written patches at extra-high reasoning.
release-it private-package changes blocked while
the repo's usual checks still passed.
Every measured test-passing verdaccio patch in the
batch was blocked.
A separate blinded follow-up review judged every blocked patch meaningful.
The results page also shows similar cases DriftFence did not flag, so the evidence stays bounded to the full measured set. This evidence measures the CI contract gate; the first private pilot validates the complete agent workflow: constraints before edits, agent revisions after failed checks, and Git review for intentional contract changes.
Best when one workflow has real business risk.
Bring one workflow owner, one relevant CI slice, and one behavior reviewers need preserved even as agents move quickly.
Runs local-first in the stack used by the first pilot.
Reviewers need approved behavior made explicit before merge.
Start where unapproved behavior drift has a business cost.
What you leave the pilot with.
In six weeks, DriftFence protects one critical workflow in your repo and gives your team a repeatable merge-gate pattern.
- Workflow mapped. One owner names the protected behavior, the relevant files, and the CI path that exercises it.
- Approved behavior in Git. The contract is reviewed like normal code and owned by the team responsible for the workflow.
- Agents get guardrails first. Coding agents see DriftFence constraints before changing protected files, then reuse that context when CI reports a mismatch.
- Reviewers get a clear report. CI shows what changed, why it matters, and whether the change needs approval.
Bring one critical workflow.
Share the workflow, owner, and CI path. The first conversation should tell you whether DriftFence fits now, needs a paid pilot, or should wait for a clearer workflow boundary. Team plans and pilot pricing are published.