Most AI-native PAM covers who gets access. Governance also has to judge what happens next.
In a January 2026 survey of 228 IT and security professionals, commissioned by Aembit and conducted by the Cloud Security Alliance, 68% said they can't clearly distinguish an AI agent's activity from a human's. 74% said agents often receive more access than necessary. 52% said agents at least sometimes inherit access originally intended for a human or another system (Cloud Security Alliance, 2026-03-24).
Access control alone cannot close that gap: it decides what an agent is allowed to hold, but by construction it cannot judge what the agent does with it. The gap is what happens after the grant. An agent that holds exactly the access it should still has to decide, command by command, what to do with it—and in most stacks, very little watches that part.
This is the gap that "AI agent governance" is supposed to close, and it's worth being precise about what the word actually has to cover, because most of what we've seen ship under that label is access control with a new logo.
Governance is three separate jobs
AI agent governance is the practice of judging what an agent does with access it already holds, not just deciding what it's allowed to hold in the first place—and then tightening the rules based on what happened. Strip the marketing language and a governance program for AI agents has to do three distinct things, at three distinct moments:
- Decide what an agent is allowed to hold. Who is this identity, what role does it map to, what's the scope ceiling on this session. This is access control—the part PAM vendors, legacy or AI-native, already cover.
- Judge what it actually does with that access, while it's doing it. Not "is this agent allowed to touch this database" but "is this specific command, right now, still the job this session was opened for." This is runtime execution judgment—a different question, asked at a different moment than access control's.
- Learn from what happened and tighten the rules that govern the next session. A policy written before anyone ran a single session is a guess. A policy that gets corrected by what actually happened—a new pattern an agent tried, a rule that was too loose, an approval that should have fired sooner—is a system that improves.
| Job | Moment | Question it answers |
|---|---|---|
| Job one—access control | At grant time | What is this agent allowed to hold? |
| Job two—runtime execution judgment | At execution time | Is this specific command still the job this session was opened for? |
| Job three—feedback loop | After the session | What should this session change about the next one? |
A program that only does access control is wearing a governance label it hasn't earned. A program that adds runtime judgment is closer, and from what we've seen, it's rarer than the marketing suggests. A program that does all three is what "governance" should mean, and as of today it's a direction the category is walking toward more than a claim we've seen any vendor substantiate end to end.
Job one: the part everyone already sells
Access control is the job every AI-native PAM entrant, us included, already covers. It's necessary and it's table stakes. But getting the grant right doesn't stop the grant from being wrong for what happens three steps into a session.
A 2026 paper on agentic AI security argues the same shift from the research side: security has to move from authenticating the actor to evaluating the action, treating a capable agent as suspect by default rather than trusted once it clears an identity check (Zafar et al., arXiv 2605.16436).
Gartner projects the average global Fortune 500 enterprise will run over 150,000 agents by 2028, up from fewer than 15 in 2025 (Gartner, 2026-04-28). Only 21% of respondents say their organizations have a mature governance model in place for agentic AI (Deloitte, 2026-04-24). The access-control math doesn't get easier at that scale. It gets worse.
Job two: judging the action, not just the actor
Runtime execution judgment is what separates a governed session from an access-controlled one: it scores each command against the session's stated purpose, not just against the identity that opened it. Inside Alpacon, a Work Session opens with a declared identity, a declared purpose, and a scope ceiling.
For sudo, that ceiling is bounded by the scope the session declared. An elevation the session didn't declare is refused ahead of any MFA challenge, superuser or not—that check runs today, not as a future default.
Every command an agent sends through Alpacon's command API is risk-scored. Rules resolve what's obviously fine or obviously forbidden, and one that lands in the grey zone is matched against the session's declared purpose—not just against command text—before it can be routed to a human to approve, rather than after. Whether Alpacon acts on that verdict or only records it is a per-workspace choice—enforcement is the default, with a monitor-and-record mode for teams that want to watch the judgments before switching them on.
Runtime execution judgment answers the question access control structurally can't: an agent holding exactly the right credential can still form a command that's wrong for the job. 63% of security, IT, and risk leaders say they cannot enforce purpose limitations on what their agents are authorized to do, and 60% cannot terminate a misbehaving agent (Kiteworks, 2026 Data Security and Compliance Risk Forecast). Access control alone was never going to move either number.
Judging the action means scoring a specific command against what the session says it's for, at the moment it's about to run—not against a role or a credential decided before the session existed. That's a different mechanism than access provisioning, built to sit outside the agent's own judgment rather than inside it.
This runtime-judgment coverage has a boundary: it applies to what runs through Alpacon's governed Work Sessions, not to service tokens. A credential issued for CI/CD or a vendor integration satisfies authorization through a static, admin-approved ACL set up front rather than a just-in-time session—and in-scope token commands auto-approve instead of routing to a human. They're still judged, and one above a critical ceiling is denied. If your agents run partly on service tokens and partly inside sessions, that's two different governance models, not one, and it's worth asking any vendor—us included—which model covers which path.
Job three: learning from the session, and tightening the next one
Job three is the feedback loop: the audit trail feeding back into the policy, so next month's rules are informed by what actually happened this month, not just by what someone guessed in advance. It's the job the industry talks about least.
Loops that tighten policy from observed behavior have already shipped elsewhere in identity governance—Veza scores granted-but-unused access, Okta's admin review campaigns flag admins by activity. We haven't seen an AI-native PAM vendor publish the agent-specific version: a policy that gets corrected by what an agent's commands actually did, not just which entitlement went unused. That's a different, harder thing to build than a policy document that never updates itself—and it's fair to hold any vendor's claims here to the distinction between "this is where we're headed" and "this is live."
What to actually ask a vendor selling "AI agent governance"
If "governance" is doing real work in a vendor's pitch, it should map to a moment, not just a feature list:
- At grant time—what's this agent allowed to hold, and how tightly is it scoped? (Job one. Every AI-native PAM vendor has an answer.)
- At execution time—when this agent forms a specific command, does anything compare it to what the session was actually opened for, before it reaches the target system? (Job two. Fewer vendors have a real answer here—and it's worth asking whether the verdict actually blocks anything, or only gets logged for later.)
- After the session—does anything about what the agent's commands actually did change the policy that governs the next session, or only which entitlements went unused? (Job three. We haven't seen an AI-native PAM vendor publish the agent-specific version of this yet.)
Even the protocol layer draws the same line between permission and judgment. The MCP specification released on July 28, 2026 carries client identity and lets a tool ask for confirmation mid-call (MCP spec release, 2026-07-28). Its authorization chapter decides whether the caller holds a sufficient scope for the operation it just attempted, and issues a step-up challenge when it doesn't. What it never asks is whether that operation is the right thing to do given what the session was opened for. It treats "does this caller have the right scope" and "is this the right thing to do right now" as two different problems.
A CISO evaluating AI-native PAM this year is really evaluating three separate claims stacked under one word. Job one is necessary and largely commoditized. Job two is where the real differentiation seems to live right now. Job three—closing the loop for AI agents specifically, the way identity governance tools already do for human entitlements—is where the category looks headed. We haven't seen an AI-native PAM vendor publish the agent-specific version yet, us included, and it's worth asking any vendor selling "governance" which of the three they actually answer, not just which they name in a feature list.
