Our delivery agents work under four standing rules. The model has no write path to a system of record. An agent never merges its own work. An approval binds to exactly what was approved. Evidence comes from the pipeline that ran. We enforce them in code and in permissions, because a rule that depends on the model remembering it is a hope. Two drafting practices sit beside them: no claim reaches a draft without a citation, and what an agent couldn't find out is reported as an open question.
This post is written for the CTO who has to say yes and the security reviewer who has to say it second. It covers how the rules work inside our Agentic Harness Orchestration products, and where they stop.
Key takeaways
- The model reads and drafts. A person, or a script a person runs behind a permission prompt, does the only writes.
- Four rules, each enforced somewhere other than the prompt: a deny list, a merge permission held by people, a hash check, a pipeline result.
- The rules are design controls. They are not a certification, and we don't claim they make prompt injection impossible.
What are the four rules, and how is each one enforced?
| Rule | How it is enforced |
|---|---|
| No write path to a system of record | Agents write drafts into a git repository. One script, run by a person behind a permission prompt, is the only thing that writes to the system of record. A project-wide deny list blocks the rest. |
| An agent never merges its own work | A person creates every merge request and merges it. The Harness has no operation for merging. |
| Approvals bind to what was approved | An approval is tied to a hash of the exact artefact. Change the artefact and the approval is void. |
| Evidence comes from the pipeline | Test and build results are read from the pipeline that ran them, never from the agent's own report. |
Why is a prompt not enough for the write-path rule?
Because the permission has to hold when the model is wrong, confused or being fed hostile text. A model that is told not to write can still be talked into it. A model that has no credential to write can't.
So the boundary sits outside the model. Everything on the model side reads and drafts. Everything on the person side, including a script a person runs behind a permission prompt, can write. Reads cross the line freely. Exactly one write does, and a model never issues it.
One detail matters to a security reviewer. An allow-list on each agent protects that agent. It doesn't protect the session the agent was launched from. So the deny list is project-wide, and we keep a test that fails if a write tool ever leaves it.
How do gates and approvals work around the rules?
Rules govern what an agent may do. Gates govern what has to be true before work moves on. In the delivery model we use for AI-led engagements there are four approval gates before anything is built: a fresh requirement, requirement approval, design approval and user story approval. Reviewers and approvers at those gates are named people on the client side.
After build, a person merges, and the client alone sets the final user acceptance sign-off. Review depth follows risk: routine work gets agentic review only, medium risk gets one human, high risk gets two, and security-critical work gets a specialist and an explicit approval.
What stops the agents from marking their own homework?
Separation, in three places. A critic agent runs in a fresh context, read-only, tuned toward doubt. It reports pass or fail against a checklist and never edits the draft. In one worked example it failed a version of a draft for stating an inference as fact, which is the job it exists to do.
Next, deterministic scripts check what a model shouldn't be trusted to check: citation format, and whether each excerpt is a verbatim substring at its cited location. A small typed-judgment model may screen claims and send a draft back for another look. It may never pass one.
Third, an agent never records a human approval on anyone's behalf. The agent that writes memory notes does so only from a version a person has confirmed, on a branch a person merges. Precedence is fixed as well: a recorded architecture decision beats a skill, and a skill beats an agent's judgement.
What does the open-questions rule change in practice?
It changes what a good draft looks like. Our first instinct with a title-only requirement backlog was to build something conversational that filled in forms. The better reading was that the information hadn't been written down by anyone, so it had to be found, and what couldn't be found had to be said out loud.
A draft with a long open-questions section is a record of honesty, not a defect count. A claim nobody can check should have been an open question. The same logic gives the second drafting practice: every claim carries a footnote with a locator and a verbatim excerpt.
What is the status today?
The Requirements Harness is live with one client. The Engineering Harness is built and going into its first client use in October 2026. The Quality Harness is in development, with a QA agent being trialled. The rules above are the ones we design and work to across all three. They apply fully only to the parts that are live. The design rules for work that crosses functions are in the ETA white paper.
Our one published pilot is small and we describe it in two people, two days, 49 stories, including what we didn't measure.
Where do these rules stop?
- They are design controls we operate. They aren't a certification or an audit result, and we make no compliance claim here.
- They reduce the blast radius of a successful prompt injection. They don't remove the risk of one. The aim is that an injected instruction can't reach anything that matters.
- Gates only help if the people at them read what they approve. That is why we treat a reviewer who never disagrees as a warning sign, as set out in an override rate of zero is an alarm.
If you are assessing a harness, ask for the deny list, the approval hash check and the pipeline-evidence configuration, not the slide that describes them. We are glad to walk through ours: start from the Agentic Harness Orchestration page.
About the author
How this was written. Drafted with AI assistance from Anitech's internal working papers and edited by Jack Dinneen.
