The six layers of AI agent governance

Here is a pattern finance teams already know from email fraud, now with an agent in the middle. An accounts payable agent reads a message from a vendor asking to update its bank details. The agent updates the vendor record and releases the next three invoices to the new account.

Walk the controls. The agent was in the inventory. It had its own short-lived credential. Its token was scoped to update vendor records and release payments. Nothing flagged a prompt injection, because the email was ordinary business text. Every layer said yes.

The one thing no layer checked was whether a bank change, followed immediately by payments, was a decision anyone had delegated to the agent. Most finance teams would say it was not. That gap is what this article is about.

What AI agent governance is

AI agent governance is the set of controls that decide what an AI agent is permitted to do, enforce that while the agent runs, and tie every outcome to a person who answers for it. We cover the definition in more depth on our AI agent governance page.

It overlaps with AI agent security, but the two ask different questions. Security asks whether the agent is who it claims to be, is reaching only what it should, and has not been manipulated. Governance asks whether the decision the agent is about to make was ever handed to it, and within what limits. A secure agent with no attacker anywhere near it can still make a decision nobody authorized.

A working program needs both. The useful question is which layer answers which question, and where the gaps are.

The six layers

Our view is that a complete program has six layers. Five of them are established security and identity disciplines, and each one is necessary. The sixth, authority, is the one most programs are missing.

Layers 1 to 4: necessary, and built for a different question

Discovery tells you how big the problem is. Identity gives every agent a name you can trust. Access keeps an agent away from systems it has no business touching. Threat protection catches the agent that has been tricked or hijacked. All four are worth doing, and the vendors building them are solving real problems.

What they share is the unit they look at: the agent, its credential, or its input. None of them looks at the decision itself. A scope says the agent may release payments. It has no field for "not within 48 hours of a bank change" or "no more than this much today."

Layer 5: authority

Authority is the layer that holds what the business actually meant. We define it as three things together: decision rights (what the agent may decide, and who granted it), constraints (the limits on each decision and across a whole run), and accountability (a person who answers for the policy).

Our position is that this check has to sit in the action path, at the tool call, the API tier, a gateway, or a sidecar. Placed there, it evaluates the action whether or not the agent was ever registered. An agent nobody inventoried still has to pass the check to act.

Layer 6: accountability

An application log tells you a payment was released. A decision record tells you which policy allowed it, what the limit was at that moment, and which person approved the exception. Auditors and boards ask the second question, and only a record written at decision time can answer it.

One request through every layer

Here is the opening example again, checked one layer at a time.

1

One request through six layers

A vendor bank change followed by three payments. Four layers pass it. Authority holds it.

The first four layers each did their job and passed the request, because none of them was asked whether a bank change followed by payments was inside the agent's mandate. The authority layer was. The 48-hour hold is an example of a rule a finance team might set, not a universal standard; every company writes its own.

What the industry frameworks say

Four sources matter most right now. The mapping of each to the six layers is our reading, not a claim the authors make.

OWASP. The OWASP Top 10 for Agentic Applications was published on December 9, 2025, built with more than 100 contributors. Its ten risk categories cover areas such as goal hijacking, tool misuse, identity and privilege abuse, memory poisoning, and rogue agents. Most of them land in layers 2 to 4. It is a security list, and it is the right starting point for that part of the program.

NIST. On February 5, 2026, NIST's National Cybersecurity Center of Excellence released a concept paper on agent identity and authorization. It focuses on adapting existing identity and access standards to agents, and it also asks whether authorization policies should change in real time as an agent's context changes, along with how agent activity should be logged and audited. That question about real-time authorization is, in our view, the doorway to layer 5.

The EU AI Act. The Digital Omnibus on AI moved the high-risk deadlines: stand-alone high-risk systems now face their obligations from December 2, 2027, and AI in regulated products from August 2, 2028, according to Gibson Dunn's summary. Human oversight is among those obligations. The dates moved; the requirement did not.

MCP. The Model Context Protocol, now a common way for agents to call tools, defines authorization at the transport level using OAuth 2.1. That is a real improvement for layer 3. A token that lets an agent call a tool still says nothing about whether a specific call falls inside the business's limits.

Where BotAris fits

BotAris provides layers 5 and 6. People define authority in the Authority Model as policy they own. The Decision Authority Enforcement Point checks each consequential action against that policy in the action path and resolves it to allow, constrain, escalate to a person, or deny. The Accountability Ledger records every decision.

BotAris does not replace your identity provider, your access controls, or your threat protection. It uses them as inputs. Because the check sits on the action rather than on a registered agent, it covers agents you know about and agents you do not. An unknown agent is not shut out by default; it can act only within the authority your business has chosen to give unknown actors.

In the opening example, the payments would not have gone out. The bank change would have triggered the finance team's own rule, a 48-hour hold and a callback, and the decision would have gone to the AP manager with the full context attached.

Frequently asked questions

Is AI agent governance the same as AI agent security?

No. Security protects the agent and the systems around it from misuse and attack. Governance decides which choices the agent is allowed to make at all. You need both, and a program that has only security will still let a well-behaved agent exceed its authority.

Which layer should we build first?

Most organizations already have identity and access in place for people, so extending those to agents is the natural start. Our position is that authority should not wait for a complete inventory, because the agent you have not found is the one most likely to cause the problem. Enforcement in the action path can start in record-only mode before it blocks anything.

Do small deployments need all six layers?

The layers scale down. A single agent with one important decision still needs an identity, sized access, protection from manipulation, a written limit on that decision, and a record of what it did. The tooling can be light. The questions are the same.

---

Sources. OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026, December 9, 2025. Modulos, summary of the ten OWASP agentic risk categories. NIST NCCoE, Software and AI Agent Identity and Authorization, concept paper released February 5, 2026. Biometric Update, NIST concept paper explores identity and authorization controls for AI agents. Gibson Dunn, EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines. Model Context Protocol, Authorization specification, revision 2026-07-28. The six-layer model and the mapping of frameworks to it are our position.