Everyone claims AI governance now. 15 questions to test the claim.

“Governance” has become a fixture in enterprise AI announcements. Identity, security, orchestration, infrastructure, and data platform vendors offer products for agent safety, governance, and control, bringing welcome attention to a problem enterprises need to solve. As the claims grow broader, CIOs and risk leaders need to get more precise about what they are buying.

Look closely at those offerings and the capabilities differ. Some restrict an agent’s access, test how an agent behaves before launch, or collect records for an audit. Your exposure depends on how those capabilities connect and where their coverage ends. A vendor evaluation needs to show whether the controls cover your agents, apply your business rules, and keep working as both change.

One floor, no loop

Controls within that stack test behavior, restrict access, stop activity, and document outcomes. Each serves a necessary purpose, and each has boundaries that a governance claim should make clear.

The pattern to watch for is one floor and no loop: a useful capability presented as complete governance, with little clarity about what happens after deployment. A stack without a lifecycle is incomplete. Buyers need evidence that the controls will remain effective as agents, rules, and environments change.

Two gaps deserve particular attention.

• The first is a missing foundation: an incomplete view of which agents exist and what they can access. A platform might tightly control its registered agents while leaving agents that were never registered ungoverned. Those unknown agents can expose customer data without ever encountering the controls you evaluated.
• The second is a missing lifecycle. After an agent passes its launch review, someone may connect another tool, replace its model, or expand its permissions. Each change can affect behavior and protection. An unchanged approval says little about the agent’s current risk.

The lifecycle gap cuts both ways. A restriction introduced without testing can disrupt legitimate work, prompting a team to disable it to restore service. Governance must account for that pressure through testing, authorized changes, and checks that the protection still works.

A foundation and a continuous lifecycle

The foundation begins with a registry: a live record of every agent and what it is made of, including its model, tools, accounts it acts through, and data it can reach. When a sales agent gains access to another customer database, its owner should see the change and review the permissions involved.

Each agent also needs a distinct identity so investigators can trace its actions separately from its builder’s activity. With that foundation in place, governance becomes a loop that runs for as long as the agent does.

The lifecycle connects five stages throughout the agent’s use:

• Define sets the rules for the agent’s work, drawing on existing business obligations and risk decisions. For the sales agent, those rules specify which customer records it can use, which services it can contact, and which actions require approval.
• Test checks the agent against those rules before release and after relevant changes. A test should confirm that the sales agent can complete an approved customer request while resisting instructions to send protected records elsewhere.
• Enforce applies the rules while the agent works. A monitoring tool records a prohibited transfer and alerts security after the fact. An enforcement control prevents the transfer through the controlled route. Buyers need to know which actions the product can prevent and which it can only report.
• Prove preserves evidence of what happened and why. For the attempted transfer, that means identifying the agent, the rule that blocked it, and any approval or override that affected the decision.
• Adapt updates the controls as agents, requirements, and environments change. If the sales agent gains a new outside tool, its permissions need review and its protections need testing again. That change brings the process back through the loop.

15 questions to ask any AI governance vendor

These questions cover the full governance lifecycle,  from the foundation that makes agents visible to the process that keeps them governed. No single vendor answers all 15 today, and any vendor that claims to is defining governance narrowly or selling you a roadmap. Your job isn’t to find a perfect score. It’s to evaluate coverage, direction, and architectural fit against your operating requirements.

Use these questions with every vendor. Ground the answers in your workflows and operating environments. Record what works today, what requires additional tools, and what your team will own after deployment. The answers labeled “flag” identify claims that deserve a closer look.

Foundation: agent registry and identity

1. Can you show us every agent we run, what each is made of, and when its ingredients change?

An agent can gain access to sensitive customer data after its original approval, leaving the business exposed to a change nobody reviewed. Ask for a registry that tracks models, tools, data access, and accounts, with changes reported to the responsible owner. Buyers may hear the ingredient list called an AI bill of materials (AI-BOM). Ask how agents built elsewhere enter the registry and how unregistered agents are found.

Flag: The vendor claims visibility into all your agents but is only describing agents built on their own platform.

2. Does each agent have its own identity, separate from the person who built it?

Agents that act through shared employee accounts leave investigators unable to distinguish an agent’s actions from a person’s decisions. Have the vendor show you how activity remains traceable when the builder changes roles or leaves.

Flag: Traceability depends on the builder’s account. If that person leaves or changes roles, the audit trail breaks.

Define: business rules and compliance requirements

3. Can we apply our existing rules and work with the risk and compliance tools we already use?

Separate rulebooks can leave risk leaders approving one restriction while agents operate under another. Ask how existing obligations reach agent controls and how evidence returns to the team’s current systems.

Flag: Integration means manual copying between systems, with no process to keep rules and evidence in sync.

4. Which regulatory frameworks come ready to use, and how does the evidence map to their requirements?

An audit can stall when activity records don’t answer a question about a specific requirement. Ask which obligations under the EU AI Act or recommendations in the NIST AI Risk Management Framework are supported. Request an example linking a requirement, its control, and supporting evidence.

Flag: The vendor claims logs are compliance-ready but can’t show which requirement a specific log entry satisfies.

Test: agent behavior and control effectiveness

5. How can we try to make an agent misbehave before launch?

Biased answers, invented information, or an agent manipulated through prompt injection can put customers at risk. Ask to see results from deliberate attempts to make the agent break its rules and whether a failed test blocks release.

Flag: The vendor shows passing results from standard tests but no evidence from deliberate attempts to break the agent.

6. What’s the plan when a rule change breaks something?

A restriction meant to protect customer data can cause an outage if it also blocks approved work. Ask how quickly the previous state can be restored, who is notified, and what the vendor does to isolate the rule change from running agents. Then ask what steps the vendor takes to reduce that risk before enforcement: staging, scoping the change to a subset of agents, or testing against recorded traffic.

Flag: The vendor’s only answer is to apply the change and watch for problems.

Enforce: prevention, boundaries, and exceptions

7. If our sales agent tries to send customer records to an outside tool, what stops it before the data leaves?

An alert after the transfer leaves you managing a data incident. Request a demonstration of prevention and a clear account of transfers the product can only report. Ask which controls or additional tools are needed for the workflow you run.

Flag: The vendor claims full visibility but can’t show what prevents the transfer, only what reports it.

8. Where do your controls sit, and what falls outside them?

A blocked transfer through one connection can still become a data incident if the agent reaches the same destination through another route. Ask the vendor to document where each control’s authority ends and what protection the buyer is responsible for beyond that boundary.

Flag: The vendor claims all traffic is governed but can’t identify which connections pass through the controls and which don’t.

9. What happens when a control fails or someone overrides it?

A failed control can expose data, while an unexplained shutdown can interrupt service. Ask whether the agent stops, continues, or seeks approval; who is notified; and how any override is authorized and recorded. Have the vendor explain what happens to work already in progress.

Flag: The vendor says an administrator can turn it off but can’t explain what happens to ongoing work or how that decision is recorded.

Prove: evidence and accountability

10. Can you explain an action or blocked attempt, including the agent, rules, and approvals behind it?

Boards and investigators need to understand why an action was permitted and who authorized exceptions. The record should identify the rule version and give reviewers enough context to judge whether the block was justified or interrupted legitimate work.

Flag: The log shows whether the action succeeded but not which rule applied or who approved the exception.

11. How would we know if a prevention control failed silently?

A team can believe it’s protected because alerts still fire, even when the blocking control behind them is down. Ask what evidence shows that prevention — not just detection — is still working, how a gap between the two reaches the responsible owner, and what the most recent verification looks like.

Flag: The vendor points to a green dashboard but can’t show evidence that prevention, not just monitoring, is operational.

Adapt: changes and authorization

12. When an urgent restriction is needed, what’s the fastest path to enforcement?

A critical restriction can be delayed when every change requires downtime or redeployment. Ask which updates take effect during operation and which require a maintenance window. Have the vendor walk through a time-sensitive scenario, blocking a newly discovered data exposure, for example, and explain how long enforcement takes from the moment you decide.

Flag: The vendor can’t walk through the steps or timeline for applying an urgent restriction.

13. Who can approve, change, or revoke an agent’s permissions, and is every change recorded?

Unclear authority can leave sensitive access in place after the business need ends. Ask for the approval trail, how an authorized owner can withdraw access, and when that withdrawal takes effect.

Flag: The vendor says the owner can remove access but can’t show who holds that authority or how revocation is recorded.

Across environments: consistency and portability

14. Do the same rules, controls, and evidence hold in our cloud, data center, and disconnected sites?

Uneven protection can leave a data center or remote site exposed under a policy that works in the cloud. Follow the same workflow through each environment. Ask what enforces the rule when outside services are unavailable, where records are stored, and how they reach the risk team later. Include agents built outside the vendor’s platform. Have the vendor identify what works today and what needs additional controls or rebuilding.

Flag: The vendor claims full cloud support but puts other environments on the roadmap.

15. How much depends on your infrastructure, and what can we take with us if we move?

A platform change can interrupt enforcement or make historical evidence difficult to use during an audit. Ask which rules, approvals, and records remain usable elsewhere, and which controls need replacement. Request an example of what can be exported and what your team would need to do to use it. If you replace the model or the framework used to build the agent, which rules and evidence remain valid, and what needs retesting?

Flag: The vendor says you can export your data but can’t show whether policies and audit records remain usable outside their platform.

Ask every vendor to document what its product doesn’t cover. An explicit limitation is something you can plan for. An unanswered question is unresolved risk.

Where single-environment governance stops

Governance built into the agent platform reduces integration work and keeps controls close to the agent. The question is how far that coverage reaches. Governance limited to one environment leaves your team responsible for protection beyond it.

Consider an insurer with a customer service agent in the cloud and claims data in its own data center. If it moves the agent into the data center or adds an agent built elsewhere, the test is whether the same rules, enforcement, and evidence follow. At disconnected sites, controls must work without outside services, with records kept locally until they can be transferred.

The insurer should set policy, own its evidence, and retain both when it changes infrastructure. Ask what remains usable and what needs rebuilding. Integrated governance should support your rules and your evidence across the environments where your agents run.

Establishing a standard for governed agents

A governed agent should have an identifiable owner, a current registry entry, and a traceable set of rules. Your organization should be able to show how those rules are tested and enforced, explain recorded decisions, and keep the process working as the agent changes. That standard applies wherever the agent operates.

The checklist sets a minimum evaluation standard for the complete governance process. An unanswered question identifies work that needs an owner, a control that needs to be supplied, or a deployment decision that deserves review. Vendors should make their contribution and limits clear enough for your team to act on them.

Begin with one agent that handles consequential data or actions, and follow it through the full lifecycle in the environments where it runs. Reviewing the evidence at each stage will show where your governance works and where exposure remains. The gap between claiming governance and running it is where enterprise risk lives.

See how DataRobot defines policy once and enforces it across the agent lifecycle.