Agentic development governance

AI-assisted development promises more output for the same effort. In practice it fails in two ways. In the first, the agent makes changes that nobody approved. In the second, the agent receives so much context that each task costs more and the result gets worse.

Both are governance failures, not productivity problems. Output without controls is risk that nobody has measured.

We did not design these controls in the abstract. We built them while we developed bord.room, the hospitality operations software that OtterBlock owns, after agent-written changes brought in defects and security issues that review had to catch.

The result is a governance layer that sits between the agent and the repository. It applies the same rules to every task and records what happens.

The starting position is that the agent is an untrusted insider, not a colleague. It gets the least access the task needs, and every action it takes is recorded.

Each tool an agent can call has a risk class, from read-only to destructive. Higher classes need approval before they run. The default is deny, so an action that is not permitted is refused.

Every event goes to an append-only log. No entry can be edited or removed afterwards, so the history of a change cannot be revised.

Before code is merged, it passes security evaluations for the failure modes of language models: prompt injection, excessive agency and insecure handling of model output.

A context gateway gives the agent pointers to the files it needs instead of the full files. The prompt stays small, and the agent works from current material instead of stale copies.

Delivery metrics in the style of the DevOps Research and Assessment (DORA) programme measure throughput and failed changes, so the controls can be judged against the work they govern.

The backlog is held in a database. Each item moves through defined gates before it reaches production, and the same rules apply at each gate for every item. Each move between gates is recorded as an event.

The result is a record that a board, an auditor or a regulator can read. It shows what changed, which agent or person changed it, which checks it passed and who approved it.

Controls that only their author understands are hard to defend. We map ours to published frameworks, so others can review them against a known baseline.

The OWASP Top 10 for Large Language Model Applications, from the Open Worldwide Application Security Project, names prompt injection, excessive agency and insecure output handling. The AI Risk Management Framework from the US National Institute of Standards and Technology (NIST) organises the work into four functions: govern, map, measure and manage. The NIST Secure Software Development Framework treats agent-written code as a software delivery problem as well as an AI risk problem.

Generated output is a context hazard, so the agent gets references, not whole files.

Governance is designed for collaborators that are not people, so every action is attributable and cannot be denied afterwards.

The agent is threat-modelled as an untrusted insider, with deny by default.

History is append-only. No record is rewritten.

The implementation stays small and plain, so anyone can inspect it and run it offline.

An organisation that lets agents write code needs a gate between what an agent writes and what reaches production. It also needs a record that shows the gate was applied. We design both in our applied AI and AI governance work.