Governance has to sit outside the model, and that single design choice shapes most of what a CIO decides about agents. Integration, access and model choice all follow from it. If the rules that limit an agent live in a prompt, they are requests. If they are enforced at the moment of action by a separate layer, they are controls.
Why must governance sit outside the model?
A model can be told “never pay a new account”. It will usually comply. Usually is not a control. Models can be manipulated by content they read, which is why prompt injection and excessive agency both appear in the OWASP Top 10 for LLM Applications.
So the check on what an agent may do runs outside the model, at the moment the agent tries to act. Every action meets five bounds at once: role scope, the agent’s current certificate, the sources it may rely on, the business’s own limits, and the platform guardrails. The lowest wins. Swap the model and the bounds stay the same.
How should agents connect to existing systems?
Through scoped connections, one per capability, not through a general-purpose service account.
| Question | Good answer |
|---|---|
| What can the agent read? | Only the sources named in its brief, with each fact stamped by provenance |
| What can it write? | Only the actions certified at its current depth |
| Whose identity does it use? | Its own, never a staff member’s login |
| Where do actions go when held? | To a named reviewer queue in the workspace |
| What is recorded? | Every verdict, in an append-only record outside the agent’s reach |
Provenance deserves attention from IT. Facts reaching an agent can be sealed (from the system of record itself), signed (a named party answers for them), declared (stated by a customer or person, unverified) or external (an emailed invoice, a web page). An external claim cannot authorise a payment. Your integration decides which systems count as sealed, so it is a security decision as much as a data one.
How should a CIO treat model choice?
As a replaceable component. Agents work best when the governance layer is independent of the model provider, so you can change models for cost, quality or data residency reasons without re-writing controls. Two consequences follow.
First, re-certify after a model change. Certification replays the agent against real cases from your own operation and scores it gate by gate. A new model is a new candidate until it passes.
Second, do not count on vendor fine-tuning for control. The better approach is qualification, not training: change the agent’s brief, sources, bounds and certification, and leave model weights alone. That keeps your data out of someone else’s model.
What does access management look like with agents?
Treat each agent like a privileged user with a narrow role. It needs an identity, an owner, scoped permissions and review. It must never act under a person’s credentials, or the record will attribute actions to the wrong party.
Depth makes access reviews more concrete. An agent at depth 2 drafts and a person sends, so its write access is to a draft queue. At depth 3 it executes routine work within bounds. At depth 4 it can move money or take hard-to-undo actions, which justifies the same scrutiny as a payments operator. Certificates lapse after 90 days, and a run that clears no depth drops the agent to depth 1 the same day, so access is never permanent.
Identity also connects to the business side. Agents that onboard customers or suppliers depend on KYC and KYB records being accurate, because those records become sealed sources for later decisions.
Who else does the CIO need around the table?
Compliance and internal audit, early. They will test the record, the refusals and the certificates. Their concerns are covered in what a compliance team needs to know about AI agents and what internal audit needs to know. And the business teams whose reviewers decide held items: reviewers need authority, not just access. The broader view by role is in AI agent skills by role.
Which mistakes does IT usually make first?
Granting broad API access to “get the pilot working”, then never narrowing it. Logging to a store the agent can write to. Treating a model upgrade as a routine patch. And forgetting that IT administrators need training on agents too: they configure connections and must recognise when a request would widen an agent’s authority.
Where the Academy fits
IT staff who design, connect and certify agents fit the Builder track of Pryme Intelligence Academy, about 24 hours plus a capstone agent certified in Attest to depth 2 or higher. Architects of regulated, multi-agent deployments fit the Architect track. Every lab runs in a free Build workspace, so engineers practise on the real product.
Questions people ask
Can we use more than one model provider?
Yes, if governance sits outside the model. Each agent is certified on the model it runs, and changes trigger re-certification.
Do agents need their own service identities?
Yes. Each agent should have its own identity and owner, so every action in the record is attributable.
Where should the decision record be stored?
Outside the agent’s write access, append-only, and retained to the same standard as other audit evidence.