Most agentic AI governance today lives in documents. There's an acceptable-use policy, a model approval form, a procedures manual and a line in the system prompt asking the agent to behave. Those documents are written for people, and people read them before they act. An agent doesn't. It reads whatever is in its context when it answers, and if the rule isn't there in a form it has to follow, the rule doesn't apply.
Our example is a regional bank with about 140 branches, made up but typical. In March 2026 it launched a customer-service agent in its mobile and online banking chat, and within weeks the agent broke a rule the bank couldn't afford to break. This guide follows that one rule from the policy manual to the moment the agent reads it.
It's governance for AI that acts. Traditional AI governance approves models and use cases and reviews their outputs. Agentic AI governance has to cover what happens between those reviews, while an agent reads systems, calls tools and answers customers without a person checking each step. It sits alongside data, security and model risk as one of the cross-cutting concerns in any enterprise AI strategy.
The clearest public framework so far is Singapore's. Its Model AI Governance Framework for Agentic AI, launched at Davos in January 2026, organizes the work into four dimensions: bounding risks upfront, including limits on an agent's access to tools and data; keeping humans meaningfully accountable; applying technical controls across the agent's lifecycle; and helping end users act responsibly. Every one of those dimensions depends on rules an agent can actually read and limits it can't get around.
|
AI governance as most firms run it |
Agentic AI governance |
|
|---|---|---|
|
What it governs |
Models and the use cases they're approved for |
What each agent may read, say and do while it runs |
|
When it applies |
At approval and periodic review |
On every answer and every tool call |
|
Where the rules live |
Policies, standards and approval records |
Ontology rules and access policies the agent reads |
|
What proves it worked |
Validation reports |
A record of each decision, with the rule version it used |
Because the agent never reads the paper, and even when it does, nothing makes it comply. The bank's chat agent could look up wire status in the payments system, read notes in the case-management system and search the procedures manual. In April, a customer asked why a $48,000 outgoing wire was on hold. The agent read the hold reason, which said AML review, and replied that the bank's anti-money-laundering team was reviewing the payment and would release it once the review was complete.
That reply was polite, accurate and a serious problem. Federal rules bar a bank from disclosing a suspicious activity report or anything that would reveal one exists, and the bank's procedures extended that caution to every open AML review. The rule was in the procedures manual. It was even in the agent's system prompt, as a line telling it never to discuss AML matters. The agent broke it anyway, because the hold reason was sitting in its context and the customer asked a direct question.
Three things failed, and none of them was the model. The agent had access to data it had no reason to see. The rule existed only as an instruction the model could weigh against being helpful. And nothing checked the answer before the customer saw it, so the bank found out two weeks later from a sampled transcript review. The pattern is common well beyond banking. IBM found that roughly one in five organizations reported an AI-related breach in its 2026 report, and 92% of those lacked proper AI access controls.
|
"An untested rollback plan functions as a control only on paper." Kaja Hussain, Sr. FDE in Database and Application Modernization, Mactores |
Pulling the agent fixed nothing structural. Getting AI agents in production and keeping them there depends on moving rules like this one out of documents and into the systems the agent reads.
With two mechanisms that do different jobs. An ontology tells the agent what things mean and which rules apply to them. Access policies decide what the agent can see at all, and they're enforced before retrieval so restricted data never reaches the model. The bank needed both for one rule.
|
Part of the rule |
Where the bank put it |
What it changed |
|---|---|---|
|
What a hold reason is |
The ontology: every payment hold has a reason, and every reason belongs to a class, either customer-disclosable or restricted |
The agent could tell a missing beneficiary address from an AML review without reading either one's details |
|
Which reasons are restricted |
The ontology: AML review and any reason the BSA officer marks restricted, signed by the BSA officer |
Compliance could add a reason class without touching the agent |
|
What the agent may see |
Access policy: payment status and the reason's class, but not the reason text or any case-management record |
The words "AML review" never entered the agent's context |
|
What the agent says instead |
The ontology: an approved message stored with the rule, with no reason and no timeline |
"Your wire is pending a routine review. We'll contact you if we need anything else from you." |
|
What happens next |
The ontology: a handoff to the case owner with the customer's question attached |
The case owner saw the contact the same day and decided what, if anything, to do |
The ontology is what made the rule readable. In an ontology in AI, a business rule is attached to the thing it governs, so the agent meets it whenever it touches a payment hold rather than whenever a prompt happens to mention AML. The access policy is what made the rule safe. Putting the user's or agent's permissions into the retrieval query, rather than filtering the answer afterward, is the same principle behind agentic RAG in production, and it meant the agent couldn't leak what it never read.
|
"Guardrails inspect language. Authorisation governs consequence." Gautham B, Forward-Deployed Engineer, Mactores |
The bank also stopped testing the agent with friendly questions. Its test set for the rule had 25 cases, including nine ways of asking why a wire was held and four attempts to get the agent to guess. The agent went back into production only when it gave the approved message in every case and the access logs showed no read of a restricted record.
Enough to rebuild the answer, not just replay it. A chat transcript shows what the agent said. It doesn't show what the agent read, which rule it applied, which version of that rule was in force or what it was refused. That's the record an examiner, an auditor or the BSA officer will ask for.
|
What the record holds |
From the bank's wire-hold answer (illustrative) |
|---|---|
|
Who asked, and through which channel |
Customer ID, mobile chat session, authenticated by the banking app |
|
Which agent answered |
Customer-service agent, version 1.4, model and prompt versions pinned |
|
What it read |
Payment status and hold-reason class for one wire; no case-management records |
|
Which rules applied |
Restricted hold-reason rule, version 3, owner: BSA officer |
|
What access was allowed or denied |
Allowed: payment status, reason class. Denied: reason text, case notes |
|
Which ontology version was live |
Payments ontology release of June 2026 |
|
What it said and where it handed off |
The approved message, and a handoff to the case owner with the customer's question |
For banks, this record carries regulatory weight. The Federal Reserve's SR 26-2, issued in April 2026, replaced SR 11-7 and left generative and agentic AI outside its model risk scope, so those systems fall under each bank's broader risk management and governance. That makes the bank's own evidence the thing an examiner reviews. The same approach runs through our context ontology for financial services work, where every agent answer carries the definitions, rules and entitlement decisions it used.
Outside banking the trigger differs, and the record doesn't. Insurers answer to state regulators' AI guidance for underwriting and claims, health systems have HIPAA, and anyone deploying AI in the EU is working toward the AI Act's dates. Each one eventually asks the same question: why did the agent do that?
The bank turned its fix into a checklist that every new agent and every new rule now goes through. It works as an AI governance checklist for any industry, and it maps onto the four dimensions in Singapore's framework.
|
Check |
What good looks like at the bank |
Owner |
|---|---|---|
|
Every agent has a named owner and a written scope |
The chat agent answers account questions and never moves money |
Head of digital channels |
|
Every rule the agent must follow has an owner and a version |
The hold-reason rule is version 3, signed by the BSA officer |
Rule owner |
|
Rules live in the ontology, not only in prompts or manuals |
The agent meets the rule whenever it touches a payment hold |
Data team, with the rule owner |
|
Access is enforced before retrieval |
Case notes are outside the agent's grants entirely |
Information security |
|
The agent acts under scoped permissions, never a shared service account |
Its role reads payment status only, under the customer's session |
Information security |
|
Actions above a threshold need a person |
Any change to a payment goes to a banker for approval |
Business owner |
|
Every rule has adversarial tests |
25 cases, including rephrasings and attempts to get the agent to guess |
Rule owner, with QA |
|
Every answer is logged with rule and ontology versions |
The record above, kept for the bank's retention period |
Compliance |
|
Rule changes go through review before release |
A new restricted reason class is approved, tested and versioned before it's live |
Rule owner |
|
Someone reviews the record regularly |
Weekly sample of handoffs and denials, reviewed by compliance |
Compliance |
The first three checks are the ones most programs skip, and they're where a context ontology does its work. The rest are familiar from any control framework. They only work once the rules are written somewhere the agent reads them.
That's what our context ontology services are built to do. Forward-deployed engineers sit with the people who own your rules, while agents handle the drafting, mapping and test generation. Within a week of the first working session, you get a diagnosis, a draft first-release scope and a target production date, starting with the one rule your agents must never break.