AI governance for enterprise security review means showing the buyer proof, from a running system, that you control what your own AI agents can do, who approved it, where the record lives, and how to stop it. A policy PDF says you intend to. A runtime control with a log proves you do.
If your deal is sitting in security review, you have probably already sent the SOC 2 report and the AI policy. The questionnaire came back anyway, with follow-ups about agent permissions and approval gates. That is the new shape of review. Buyers, regulated ones especially, now extend standard due diligence to AI data handling, model governance and agent permissions. They favor specific, verifiable answers over general assurances. This post covers what they ask, why the usual artifacts fall short, and what evidence clears the review.
What the Security Review Actually Asks About Your AI
The review asks what your agents can reach, who signed off, what got recorded and how you shut them down. Classic controls like SOC 2 and ISO 27001, encryption and incident response are still on the list. The AI layer sits on top.
Expect questions in a few clusters. Data and providers: which models and subprocessors receive customer data, whether prompts or outputs are retained, and whether customer data trains anything. Agents and access: what systems, tools and data each agent can touch, whether credentials are scoped and revocable, and whether sensitive actions need human approval. Governance and oversight: who approves AI use and owns the risk, and how models are inventoried and monitored. Changes and incidents: how model updates are tested, what is logged, how long it is kept, and what the response plan is when an agent misbehaves.
Then comes the evidence request: a data-flow diagram, a subprocessor list, an AI inventory, testing records, audit logs and relevant security reports. For agent products, reviewers press hardest on identity, least-privilege access, approval gates, audit trails and a way to stop or revoke an agent's actions.
Why a Policy PDF and a Posture Dashboard Fall Short
A policy PDF describes intent and a posture dashboard describes history. Neither is a control. Reviewers have read enough AI policies to know that a document does not stop an agent from running a command it was never meant to run.
The PDF problem is simple. It says agents operate under least privilege. The reviewer asks where that is enforced. If the answer is "in our engineering standards," the follow-up questionnaire gets longer.
The dashboard problem is subtler. A posture tool is a camera. It shows what an agent did, scores risk, flags anomalies. That is useful, and plenty of security teams buy it for exactly that. But when the reviewer asks "can the agent do X?", a camera can only answer "we would have seen it afterward." Watching an agent is not controlling it.
The evidence that clears review comes from the lock: a governed runtime that decides what an agent can do before it does it. Posture tools and governance programs still have a place, and they often sit alongside a runtime in the same account. They just can't answer the control question on their own. For the longer version of this distinction, see Governed AI Operations vs AIOps: Watching vs Controlling Agents.
Four Answers Reviewers Want: What, Who, Where, Stop
Every agent question in a review reduces to four. Build your answers around them and the questionnaire gets shorter.
What can the agent do? Reviewers want a defined scope per agent and per tool, not a general statement. The answer is a list of tools, each with a permission level, set by someone accountable, with some tools simply unavailable to the agent whatever the prompt asks for.
Who approved it? For sensitive actions, they want a named human decision tied to a specific action. "A human is in the loop" is not an answer. "This action paused, this person approved it at this time" is.
Where is the record? One log, queryable, that lets someone reconstruct an incident: timestamp, initiating user or session, agent identity, tool, target, action and policy outcome. Logs scattered across five services do not survive an audit conversation.
How do you stop it? Revocation has to be real. Disable a tool, remove access, end the session. And the stop has to hold: an agent that was granted something yesterday should not carry it forward unchanged today.
What Runtime Governance Evidence Looks Like
Runtime governance evidence is output from a system that enforces policy as agents act, not a description of how you hope they behave. A reviewer can inspect it.
The strongest package pairs your attestation with demonstrable runtime controls:
A per-tool permission map. Each tool the agent can call, with its level set by an administrator. Tools that run freely, tools that pause for approval, and tools that are off.
Approval records. Which actions paused, who reviewed them, what they decided and when.
An exportable audit log. Every governed action with organization, workspace, session, tool, risk, status, approval state and date, protected from casual edits and queryable on request.
Evidence that scope is rechecked. If a run pauses for approval, what it was granted should not persist blindly. Scope should be rebuilt from what is true when the approver signs off, because permissions change and sessions end.
Logs alone do not satisfy SOC 2 or ISO 42001, and a good reviewer knows it. Keep a control-to-evidence map that ties each artifact to the requirement it supports. The runtime evidence is the part that is hard to fake, which is why it carries weight.
How Luumen Gives AI Vendors That Evidence
Luumen is a governed agent platform that lets you run AI agents against production systems with policy enforced at runtime and every action on the record. That is the lock the reviewer is asking about.
Here is how it maps to the four answers.
What: Administrators set each tool's level. Full access means the tool runs without asking. Ask for approval pauses execution for inline human-in-the-loop review inside the LuumenAI chat session. Not enabled means the tool is not available to the agent, whatever the prompt asked for. Permissions scope to the individual tool call, backed by RBAC. Governed integrations carry a risk level, schemas, an approval floor and evidence requirements, and are reviewed before they are enabled.
Who: Governed actions need human approval, and the approval state is recorded against the action.
Where: Every governed action lands in one queryable audit log, with organization, workspace, session, tool, risk, status, approval state and date.
Stop: Set a tool to Not enabled and the agent cannot use it. When a run pauses for approval, Luumen does not keep what it was granted. On resume it rebuilds scope from whatever is true at the moment the approver signs off.
On the attestation side, Luumen states that it holds SOC 2 Type II and ISO 27001, with AES-256-GCM at rest and TLS 1.3 in transit. Those are Luumen's own claims about Luumen, not a substitute for yours. For how this plays out against infrastructure review, see AI Governance for SAP Operations: Runtime Controls Before Production. You can also see multi-server operation and inline approvals in LuumenAI chat.
Building the Evidence Pack Before the Questionnaire Lands
Assemble the pack before a buyer asks, because the first questionnaire is the slow one. Everything after reuses it.
Scope the system honestly. Write down the AI product, the data flows, the model providers and subprocessors, tenant boundaries, and whether customer data is used for training. Make sure your SOC 2 scope covers the AI system the buyer is evaluating.
Document the governance layer. Keep an AI-system inventory, a risk register and a human-oversight and incident procedure. If you pursue ISO/IEC 42001, align to it. It adds AI-specific lifecycle governance that SOC 2 does not replace.
Define agent permissions as configuration, not prose. Each agent gets an identity and least-privilege tool access. Export the per-tool settings so a reviewer can see them.
Design logs for reconstruction. Timestamps, initiating session, agent, tool, target, action, policy outcome. Set retention and export procedures, and document how prompts and outputs are logged and deleted.
Rehearse the stop. Walk through revoking a tool and ending a session so you can show it, not describe it.
Map artifacts to requirements. One page that says which evidence supports which control. Reviewers love a map.
Show the lock, then book the demo
Enterprise reviewers have stopped accepting that you take AI governance seriously and started asking to see it working. A policy PDF and a posture dashboard tell them what you meant and what happened. A governed runtime shows what your agents cannot do and who allowed what they did. If your deal is stuck, put the lock in front of the reviewer. Book a demo and you will see how Luumen scopes an agent's tools, from Full access to Ask for approval to Not enabled, and what the resulting approval record and audit log look like.