A session analysis can tell you what to tighten. Turning that into a rule is still your job today.
Run an audit today and you'll usually find the same thing: a session that should have been flagged, an access grant that outlived its purpose, a pattern that repeated three times before anyone noticed. Often, something in the system already flagged it—and nobody acted on it.
That gap—between an AI system generating a useful observation and a human turning it into a binding rule—is exactly what the audit finding above came from.
The recommendation already exists
On plans that include AI session review, a recorded Websh session's activity goes through a multi-pass analysis: the commands get extracted, each one gets classified, the sequence gets checked against known attack-chain patterns, and the last pass produces verification guidance—specific things to check—on the session's own record. That layered structure matters because a single risky command and a chain of them read the same way to a tool that only looks at one line at a time. What comes out the other end is real, and it isn't nothing: whoever reviews that session doesn't have to reconstruct what happened by hand.
The step that stays human today
Say three separate sessions show the same operator repeatedly needing to escalate beyond their assigned scope. In Alpacon today, that pattern does not roll itself across sessions into a policy change—three sessions like that produce no proposal to tighten the underlying access grant. Turning an observed pattern into a rule is a step a person takes today, by design.
In the approval lane, an AI signal can escalate how a decision gets reviewed and can never downgrade it—that's a code-level invariant, and it holds even if the AI signal itself goes down; a timeout or outage doesn't loosen anything either. It's a narrower guarantee than it might sound, though: it governs whether a pending decision gets more scrutiny, not whether an observed pattern turns into a new rule. Those are two different mechanisms. Only one of them exists today.
The same shape of control shows up in regulation: the EU AI Act's Article 14 asks a provider to build in a human's ability to disregard, override, or reverse a high-risk AI system's output (14(4)(d))—for stand-alone Annex III systems, that duty applies from 2 December 2027, not yet live, but built on the same idea: a system that requires a person to act, rather than one that acts alone.
Most organizations aren't even at that stage yet
For most organizations, the promotion step isn't even the bottleneck yet. CyberArk's CISO research—a survey of 104 CISOs across North America and Europe, published November 2025—found that AI agent adoption is expected to reach 76% within three years, while fewer than 10% of organizations have adequate security and privilege controls in place today. That's CyberArk's own vendor research, worth naming as such, and it's a different gap than the one this piece is about: it's not that nobody reviews the AI's recommendation, it's that most organizations don't yet have the underlying privilege controls a recommendation would even attach to. A human reviewing session guidance and deciding whether to tighten a rule is a later-stage problem. Plenty of teams haven't gotten there yet.
The same logic holds once they do. A SOC 2 or HIPAA auditor draws the same distinction: showing that something was flagged isn't the same as showing what happened after it was flagged.
What this means for your next AI governance audit
An AI governance audit of an AI-native PAM or agent-governance vendor should focus on one question: what happens to a recommendation after it's generated, not whether the tool produces one at all. Three checks surface the answer:
- Does it act without a person? Some vendor systems act on a recommendation without a person in the loop; others leave it on the record until someone reads it and decides. Ask which one the product in front of you does.
- Is the vendor straightforward about which is true? Some pitches blur observation and enforcement together, and that difference matters more than the recommendation itself.
- Can they show it live? Ask to see it in a demo, not just described on a slide—if it can't be produced on request, that's itself an answer.
On Alpacon, that answer is the second one. On plans that include AI session review, a recorded Websh session's verification guidance stays on that session's own record until someone reads it and decides what, if anything, to do about it. Nothing acts on it automatically today.
If your last AI governance audit turned up a recommendation nobody acted on, the fix isn't a smarter model. It's making sure someone reads what the system already flagged—and treats that as part of the job, not an extra step bolted onto it.
