Keep the rules for what each agent may do in one place, and make enforcement read from that place. When bounds are scattered across prompts, tool settings, workflow configs and access groups, they drift apart, and nobody can say with confidence what an agent is actually allowed to do. One source of truth makes the answer checkable.
Where do agent bounds end up living?
In most firms, an agent's permissions accumulate in layers. The prompt says "never offer refunds over 100". The tool integration has its own limit, set by the engineer who built it at 250. The workflow engine has an approval step above 500. The service account the agent runs under has write access to the whole refunds table because that was quickest to set up. A spreadsheet owned by risk says the agreed limit is 150.
Each of these was set by someone with a reason. None of them agrees with the others. The agent's real limit is whichever layer happens to bite first on a given path, and that can change when any one layer is edited.
This is drift, and it is the normal state of any control that is copied rather than referenced. It gets worse as agents multiply, because each new agent picks up its own copies.
Why does drift matter so much for agents?
Three things make drift more dangerous for agents than for traditional systems.
First, agents choose their own paths. A rule enforced on one path may not be on the path the agent takes. If the 250 limit is in the tool and the agent finds another tool that also issues credits, the limit does not follow.
Second, prompt-based rules are requests, not controls. A model usually follows "never offer refunds over 100", but usually is not a control standard. If the only place a bound exists is the prompt, it is not enforced.
Third, nobody can answer the auditor's question. "What may this agent do?" should have one answer. With scattered bounds, the honest answer is a list of five places to look and a caveat that they disagree.
What should the single source hold?
The single source is a register of bounds per agent, per capability, that the enforcement layer reads at the moment of action. It should hold everything that decides whether an action is allowed.
| Field | What it records | Why it belongs in one place |
|---|---|---|
| Role scope | The capabilities this agent may use at all | So a capability not listed is refused everywhere |
| Depth (per agent), and the depth each action needs | Read, draft, execute, move money, coordinate | So depth is not reset by a tool or prompt edit |
| Certificate status | Current, lapsed or failed, with dates | So a lapse drops depth immediately on every path |
| Permitted sources | Which sources and provenance classes the agent may rely on | So weak evidence cannot support strong actions |
| Customer limits | The customer's own thresholds per capability | So a business limit is not overridden by a technical one |
| Owner | The person accountable for this agent's bounds | So every change has someone who approved it |
The register is not a document people read and then implement elsewhere. It is the thing enforcement reads. If it says 150, the limit is 150, whatever the prompt, the tool or the spreadsheet says.
How does this connect to the sources an agent uses?
Bounds about sources are the easiest to scatter, because sources are added by many hands: a new knowledge base here, a new data feed there. A source provenance register keeps them in one list with each source's class and owner.
The class matters because it decides what a fact can support. A sealed source, such as a record the firm itself issued and protects against change, can support more than a declaration typed in by a customer. A signed source carries the authority of whoever signed it. When the register of bounds says "refunds may rest on sealed or signed sources only", that rule has to be read alongside the register of sources. If the two live in different places with different owners, the rule cannot be enforced reliably.
Does one source of truth mean one giant agent?
No. A single register of bounds is different from a single agent with every capability. In practice, narrow agents with narrow bounds are easier to certify and safer to run, which is why the answer to whether one AI agent should do everything is usually no.
What the register does is make many narrow agents manageable. Each one has its own row. Changing a firm-wide limit is one edit that every relevant agent picks up. Retiring an agent is removing its rows. Without the register, every one of those operations means hunting through prompts and configs.
What is the trade-off?
A single source is a single point of failure if it is badly managed. It needs access control, change approval and its own audit trail, because whoever can edit it can change what every agent may do. That is the same discipline firms apply to payment limits and user entitlements, and it should be applied here.
The alternative is many weak points instead of one strong one. Scattered bounds are each easy to edit and none is fully trusted.
Where Pryme fits
In Pryme, the minimum chain reads every bound from one place at the moment of action: role scope, certificate, sources, the customer's own limits and the platform guardrails. The verdict names which bound decided. Prompts carry wording, not permissions. See the governed agentic operating system, explained.
What should you do differently?
Pick one live agent and list every place a limit on its actions is set: prompt, tool code, workflow, identity and access settings, policy documents. Compare the values. Where they differ, decide which is correct, put it in a single register, and change the other layers to read from it or remove them. Then do the same for the next agent.
Questions people ask
Should prompts still mention the agent's limits?
They can, so the agent explains itself well to customers. But the prompt should repeat the register, not be the register. If the two disagree, enforcement follows the register.
Who should own the register of bounds?
Each agent's rows should have a named business owner, with risk or compliance approving changes above a set level. The platform team owns the register's mechanics, not its contents.
How do we stop teams adding limits in their own code?
Make the register the easiest place to set a limit, and review integrations for hard-coded thresholds. A limit in code is not wrong in itself, but it should match the register and be tested against it.