AI Agent Governance & Security · Enterprise AI
Before an agent touches a single system, someone should be able to answer five questions in plain language. Here's the checklist, backed by real research, not just an opinion.
Every team about to put an agent into production is really asking one question: before we let this thing take actions in our systems, what actually needs to be in place first? That question tends to show up late, treated like a formality to clear before launch instead of a decision you make going in.
The research says that's backwards. McKinsey's risk practice found that 80% of organizations have already seen risky behavior from an AI agent, and they put the shift bluntly: agency isn't a feature, it's a transfer of decision rights. The Cloud Security Alliance surveyed over 1,500 security leaders in 2026 and found 92% are worried about agent security, yet most admit real gaps in how they govern it. Only 23% have a formal, company-wide strategy for agent identity, and just 21% actually know, in real time, which agents are running.
80%of orgs have seen risky agent behavior · McKinsey
92%are concerned about agent security · CSA
21%keep a real-time agent inventory · CSA
This is why trusting an AI agent isn't a soft question, it's an operational one. You don't earn that trust because a pilot went well. You build it, on purpose, across five specific areas, before the agent ever gets the authority to act.
Why trust in AI agents actually matters
PwC draws a distinction we think is worth keeping: an agent behaving correctly (execution) and an agent pursuing the right goal within its authority (intent) are two different questions, and most teams are only checking the first one. McKinsey's Rich Isenberg said it even more plainly in a recent interview: the question isn't "is the model accurate," it's "who's accountable when the system acts." He also flagged something worth sitting with: the scariest agent failures aren't the dramatic ones, they're the ones nobody can reconstruct afterward, because nobody logged the workflow in the first place.
That's the whole trust gap in one sentence. Capability tells you what an agent can do. It tells you nothing about whether it should be trusted with more, or whether anyone would even notice if it went sideways.
The five-category checklist
Run these in this order. That's not necessarily the order they'll come up in real life, but it's the order that actually protects you.
1
Access
Which data and systems can the agent actually reach?
Start here, because everything else depends on it. Most agents end up with broader access than anyone intended, not from a bad decision, but from nobody making a decision at all.
Research context: RSM's technology practice notes that the organizations furthest ahead with agentic AI aren't the ones with the most sophisticated models, they're the ones that solved permission-aware data access before scaling. Retrofitting access controls after adoption is far harder than designing them from the start.
A current list exists of every system and data source the agent can reach
Each access grant maps to a specific task the agent performs
Nothing was granted "just in case" and never revisited
2
Permissions
What actions can it take, and where's the line?
Access and permission aren't the same thing. An agent might need to read a system without ever needing to write to it. Define the specific actions the agent is allowed to take, separately from what it can see.
Research context: CSA's 2026 research note found that 44% of organizations still rely on static API keys, without rotation schedules or usage monitoring, to authenticate autonomous agents. PwC recommends treating every agent like a digital workforce member: a verified identity, task-specific access, and clear boundaries on autonomous decisions.
Read access and write/action access are defined separately, not bundled together
There's a written list of actions the agent is explicitly not allowed to take
Permissions were set by someone who understands the downstream risk, not just the workflow
3
Approvals
Which decisions actually need a human before they happen?
Not everything needs a human in the loop, and treating every action as equally risky just trains people to click approve without reading. Tier the list: what the agent can do alone, what needs a quick human confirmation, and what always requires a named approver.
Research context: a 2026 study cited by Forbes found that in 8% to 17% of agent task trajectories studied, the agent reached the correct final result while still failing the policy checks that should have governed how it got there. Outcome alone doesn't prove the process was safe, which is exactly why approval gates need to sit before the action, not after.
Actions are tiered by risk, not treated as uniformly safe or uniformly risky
High-risk actions have a named approver, not just "someone on the team"
The approval step happens before the action, not as a notification after
4
Audit evidence
Can you show what it did, why, and when?
This is the one most teams find out they're missing mid-incident, trying to reconstruct what happened from logs that were never built for this. Audit evidence isn't a log file, it's a record that answers what happened, what reasoning led to it, and when.
Research context: PwC recommends a minimum decision record for every consequential agent action: the delegated objective, the action taken, the evidence or rationale, any exception flags, the accountable owner, and the escalation outcome. McKinsey frames the test even more simply: can you reconstruct every decision and action, end to end, on demand?
Every consequential action has a timestamped record of what happened and why
That record is readable by someone who isn't an engineer
Evidence is generated automatically, not reconstructed after something goes wrong
5
Ownership
Who reviews problems, and who can pause it?
Somebody needs their name on this, specifically, not "the platform team" in general. If the agent starts behaving oddly at 2am, there should be one person who gets the alert and one person who has the authority to shut it off.
Research context: PwC's governance framework is explicit that every agent needs a business owner accountable for its decisions and actions, with the board overseeing whether that governance exists at all, not supervising every agent directly. McKinsey's advice to boards is to demand a precise yes or no: do we have a complete inventory of agents and owners?
A named individual, not a team name, owns this agent's behavior
That person has the actual authority to pause or shut it down
There's a defined path for what happens after it's paused, not just an off switch
How We'd Set This Up: An IT Ticketing Agent
RecommendThe agent suggests a fix for a known issue type. No approval needed, nothing changes yet. This is the correlation layer at work: it has enough context to spot the pattern, not enough authority to touch anything.
Confirm FirstIt can restart a non-critical service, but only once a named on-call engineer confirms it in the ticket. The approval sits before the action, with a real name attached to the yes.
Escalate OnlyAnything touching production infrastructure, identity, or customer data routes straight to an engineer. The agent drafts the plan. It doesn't get to run it.
Same agent, three different rules, based entirely on what's actually at risk if it gets something wrong. That's the whole exercise: not "should this agent have guardrails," but "which of these five categories does this specific action fall into, and what does that require?"
“
Evidence that an agent reliably recommends an appropriate action does not independently establish that it will execute that action within every relevant authority limit, exception rule, and downstream dependency. Evidence should align with the level of authority granted.
Forbes, "Your AI Agent Succeeded. Is It Ready For More Authority?"
That's the trap most teams fall into: a successful pilot gets treated as blanket permission for more autonomy. It isn't. Every time an agent moves from recommend to execute, or read to write, run the checklist again. Don't assume it still holds.
Why this list, and not a longer one
There are more elaborate governance frameworks out there, and most of them fail for the same reason: nobody finishes filling them out before launch day arrives anyway. Five categories is short enough to actually run before every agent goes live, and specific enough that "we're handling governance" stops being an answer nobody can check.
If your team can't answer all five for an agent that's already live, that's not a reason to panic. That's the finding. As McKinsey puts it plainly: you can't govern what you can't see, and you can't control what you haven't inventoried.
How this connects to what we build
This checklist is the manual version of a lot of what our platform already does. AI Assurance, the Yes Layer, enforces guardrails continuously and keeps an audit trail automatically while the agent runs, so approvals sit inline before the action instead of showing up as a log entry you find later, and ownership is built into the workflow itself, so "who can pause this" always has a real answer.
Worth being precise about where this sits: your agentic AI isn't part of AI Correlation Fabric, and Correlation Fabric isn't a module bolted inside your agent. It's the other way around. Correlation Fabric is the layer underneath, connecting what's happening across your infrastructure, your data, and every tool call your agents make, so you can see token usage, data quality, and assessment coverage in one place. Every agent you run sits on top of it. AI Assurance sits alongside that same layer, turning the approvals, audit evidence, and ownership in this checklist into something enforced automatically while the agent runs. The agent still plans, calls tools, and makes its own decisions exactly as it would on its own, these two layers just mean someone can actually see and govern that happening, instead of finding out from a bill or an incident report.
It's the same discipline behind our agentic AI consulting engagements, and it's exactly what our AI implementation services are built to put in place before an agent goes live, not after an incident forces the conversation.
We'd still tell you to run the checklist manually first. It'll show you exactly where your gaps are, and exactly what's worth automating once you see how much of it repeats for every new agent you launch. That's the gap our AI agent services are built to close, before an agent ever reaches production, not after.
Frequently Asked Questions
What is an AI agent governance checklist?+
An AI agent governance checklist is a set of controls a team confirms before an agent is authorized to act in production systems, typically covering access, permissions, approvals, audit evidence, and ownership. It's meant to be run before launch, not audited after an incident.
Do we need this checklist for every agent, even low-risk ones?+
Yes, but the answers can be short. A low-risk, read-only agent might clear all five categories of the AI agent governance checklist in a sentence each. The point isn't paperwork, it's making sure nobody skipped the question entirely.
What's the difference between access and permissions?+
Access is what the agent can see or reach: systems, data sources, tools. Permissions are what it's allowed to actually do with that access, like read versus write versus execute. Treating them as one setting is where a lot of over-permissioning starts.
Who should actually own this checklist internally?+
Usually a joint call between whoever owns the AI engineering work and whoever owns risk or compliance. PwC's research explicitly frames this as a shared responsibility, not something either side should own alone.
How do AI implementation services help with agent governance?+
AI implementation services that build governance in from the start, rather than bolting it on after deployment, are what turn this checklist from a one-time exercise into something enforced automatically every time a new agent goes live.
Is this the same as an AI readiness assessment?+
Related, but narrower. An
AI readiness assessment looks at your infrastructure, data, and applications before you build. This AI agent governance checklist is specifically about the controls an agent needs before it goes live or expands its authority.
Keep Reading
Run the checklist.
Then let us automate it.
See how OnStak AI Assurance turns access, approvals, and audit evidence into something that runs itself, not something someone reconstructs after an incident.
Let's Talk →