September 28, 2026 · 7 min read
AI Agent Registry Governance: Registration, Fences and Run Logs
By Sahan, co-founder, systems and delivery
AI agent registry governance is one rule enforced by machinery instead of memory: no agent runs until it is declared, fenced and wired to a log. Declared means a record with a named owner. Fenced means its permissions are written down where code can check them. Logged means every run leaves a start, a finish and an error a stranger could read. Miss any of the three and you have a shadow bot.
This is part seven of our governance series. The previous part covered what happens after an agent fails. This one covers what has to be true before it is allowed to run at all.
Why shadow bots are the default
Shadow agents appear because building one is now easier than asking permission. Anyone with an API key and a scheduler can have one running by Friday. Nobody sets out to create a shadow bot. It happens when registration is optional and nothing checks.
Most companies are already there. SailPoint’s survey of 353 security and IT professionals, fielded by Dimensional Research and published 28 May 2025, found 82% of organisations already use AI agents and only 44% have policies in place to secure them. IBM’s Cost of a Data Breach report, published 30 July 2025 and based on 600 breached organisations, put a price on the gap: a high level of shadow AI added USD 670,000 to the average breach, and 97% of organisations that had an AI-related incident said they lacked proper AI access controls.
We are not exempt either. Our group runs 41 registered agents, 9 of them live in production, and some of them existed before registration was mandatory. That part of the story is further down.
Registration: the build fails, the reminder does not
A registry only works if skipping it breaks something. Ours is a manifest per agent, checked in continuous integration against a closed schema. Unknown fields are rejected. Required fields must be present. Every ID must be unique and match its file name. A bad record means the change does not merge.
A second check closes the side door. Our internal app launcher cannot gain a new tile unless a matching manifest exists, and the build fails on the mismatch. That single check is the literal version of “no shadow bots”: a new tool has no path to appear in front of people without a registration record behind it.
Part one of this series listed what the manifest declares. Two fields matter more than the rest. The first is an evidence stage, recomputed every night from live run data. Editing it by hand achieves nothing, because the nightly job sets it back to what the runs actually show. The second is the agent’s authority level, which only a named person can raise, with the decision recorded in the change itself.
The rule joining them: authority may never exceed evidence. An agent with a thin track record cannot be handed a wide fence, whoever asks. Lowering authority needs no evidence and takes effect immediately.
Fences: permissions kept as data, not intentions
A fence is the written list of what an agent may touch. Every tomte, our word for one production agent with one defined job, sits on one of five cumulative rungs, from read-only reporting up to a delegated rung that nothing of ours holds today.
The middle rungs carry most of the weight. A fenced agent can message known parties from an approved template, but cannot touch money, cannot publish outside pre-approved channels, and cannot edit its own configuration. One rung up, an agent may retry and repair its own failed runs, but still cannot merge its own changes or touch another agent’s setup. Two decisions sit outside every rung and are enforced in code: anything to do with hiring or firing, and anything above a fixed money threshold, always goes to a human.
Credentials are part of the fence. Each agent declares the tokens and keys it uses, and a health check probes each one ahead of expiry. Before that check existed, we found out a credential had died when the agent using it failed in production.
The most common fence failure in the market is the missing fence. The Cloud Security Alliance surveyed 228 IT and security professionals in January 2026 (published 24 March 2026, commissioned by Aembit) and found 31% run agents under a human user’s identity, while only 22% apply access frameworks very consistently. An agent borrowing a person’s login inherits that person’s entire reach.
Where the registry lives: three options
| Option | What it records | What enforces it | Fits |
|---|---|---|---|
| Spreadsheet of agents | Name, owner, purpose | Goodwill | Under five agents, one owner |
| Vendor registry (Microsoft Agent 365, AWS Agent Registry) | Inventory, identity, approval state | The platform’s own controls | Agents built mostly on that vendor’s stack |
| Manifest in your repo, checked in CI | Owner, fence, authority, credentials, evidence | A build that fails | Mixed stacks, agents you build yourself |
The vendor options are real and moving fast. Microsoft’s documentation, updated 17 June 2026, describes Agent 365 as a unified inventory covering Microsoft and non-Microsoft agents, and retires the older Entra agent registry view from 1 May 2026. AWS documents an agent registry with an approval workflow (draft, pending, approved) as of September 2026. If most of your agents live on one platform, use its registry. If they span several, the manifest in your own repository is the one record every agent can be held to.
Run logs: start, finish, and a readable error
Every run reports a start and a finish. A periodic sweep looks for runs that started and never finished, so a process that dies mid-run cannot age into a silence that looks identical to “did not run.” Runs with nothing to do get their own status, after an early bug counted them as either successes or failures depending on the caller.
A failed run must carry a real error string. For months, a caller that sent a blank error got a generic placeholder swapped in, silently, forever. Now the placeholder is flagged loudly and opens a human ticket, and after a grace period the bad report is rejected outright.
Two more layers sit on top. Configuration and credential decisions go into a permanent governance trail, separate from the operational run table. And an out-of-band dead-man’s switch checks for staleness independently, because all our internal watchdogs share one scheduling layer, and one platform outage could silence every one of them together.
Regulation points the same way. Article 12 of the EU AI Act (Regulation (EU) 2024/1689) requires high-risk systems to allow automatic recording of events over their lifetime, and Article 26(6) requires deployers to keep those logs for at least six months. Most small-business agents will not be high-risk, but the log design is identical, and building it once is cheaper than retrofitting it later.
Where our registry still leaks
Enforcement binds going forward only. A handful of tools that predate the check were grandfathered, and they sit on a named list of exceptions that no new work may join. We are clearing it, not pretending it is empty.
When we finally wrote the authority scale down formally, an audit found only a minority of manifests had any level set, and one held a text placeholder in a numeric field. The evidence stage had its own bug: it was calculated over an agent’s whole lifetime, so one bad batch of illegible failures could cap an agent’s rating long after the cause was fixed.
The strangest failure was a diagram. It showed a data flow between two systems that did not exist in code, and an automated fact-check approved it by comparing the diagram against its own description. Certain claims about how our systems work must now point to machine-checked evidence, meaning a real file, schedule or config value, re-checked in CI and nightly.
What this costs to install
For a business under ten agents, the afternoon version is a list with an owner, a fence and a log destination per agent. Past that, it needs machinery. An AI Workforce Sprint builds one working agent from $9,500 fixed, in four to six weeks, and ships it with access control, logging and a paper trail for every action, registered from day one on your own GitHub and database. You own the manifest, the checks and the logs.
The discipline behind it is documented on our own fleet’s proof page, including 5,450 runs in one 13-day stretch with zero failures. Send us the list of agents you already run and who owns each one. We reply in writing within one business day, with no meeting. Start async.