AI governance platform: what to evaluate

Model governance manages the model lifecycle: registration, versioning, validation, drift monitoring, and documentation for reviewers. Model-governance features, such as those offered by DataRobot, support evaluating whether a model is fit to deploy and monitoring its behavior afterward. That work is necessary, but it precedes the action controls this guide covers.

Agent governance starts once the model is deployed and connected to tools. The question changes from "is the model good" to "what is the agent permitted to do right now, who authorized it, and what did it actually do?" A well-governed model can still execute an unwanted payment if nothing constrains the action path. When you evaluate an AI governance platform, the first question is which of these layers it governs.

Four capabilities determine whether a platform governs actions or merely describes them:

• AI agent access control. Can the platform gate the credentials an agent uses, per capability? The strong version issues or brokers credentials at the moment of the permitted call; the weak version checks a policy file the agent can bypass. Ask what happens when an agent uses direct credentials outside the controlled path. AAES cannot prevent or observe that bypassed call; separate telemetry may report activity, but reporting is not enforcement.
• AI agent guardrails. When evaluating action controls, test enforceable rules such as permitted capabilities, spending limits, and named approvals. Prompt and content controls address different risks and do not substitute for these action controls.
• AI agent monitoring. Monitoring observes activity; action enforcement constrains it. Both can support governance, but an observed permission is not an enforced one, and a dashboard of observed activity does not by itself demonstrate prevention.
• AI audit trail. Every decision, allowed or refused, should produce a durable, tamper-evident record you can export and verify without the vendor's service. Ask whether verification requires the vendor to be online, and whether the record binds the exact request the approver reviewed.

AI risk management software inventories systems, maps them to frameworks, tracks assessments, and produces reports. These functions support inventory, assessment, accountability, and review. AI compliance software overlaps heavily with this category.

These tools complement an action-governance layer; they do not replace it. The category is sometimes labeled regulatory compliance AI tooling: software that organizes compliance work and may collect or generate evidence through its workflows and integrations. A risk register entry that says "agents require approval for payments" is only as good as the mechanism that enforces that requirement. In an audit, policy and risk records describe intended controls; execution records can provide evidence about how those controls operated on covered paths. Neither establishes complete compliance by itself.

• Pick one bounded workflow with one irreversible action: a payment, a production change, an external message.
• Register the capability, name the approver, and attempt the action without approval. It should fail, and the refusal should be recorded.
• Approve the exact request, then change the request content and try to reuse the approval. It should fail.
• Have the agent attempt to grant approval for its own action. It should fail. The agent may request approval from an authorized person.
• Export the records and verify them using the vendor's offline tooling while the vendor's service is off.
• Check the failure behavior when the governance service is down. Fail-closed means new requests are denied; check how long already-issued credentials remain valid.

A platform that passes these tests on one workflow is worth a wider pilot. A presentation alone does not demonstrate these action-layer controls.

AAES is the governance layer for enterprise AI agents: it applies permissions, approvals by authorized persons, and spending limits to actions routed through AAES, with offline record verification. It runs as a client-operated, single-tenant deployment on the client's infrastructure. On an enforced path, a capability the operator registers as irreversible always requires approval by an authorized person, and an agent cannot approve itself.

The design's distinguishing properties: customer-controlled credential custody (the secret an agent uses against a third-party service stays customer-owned; Custody paths differ in what crosses the trust boundary. On a grant path, AAES issues a short-lived, task-scoped AAES grant: an authorization, not a downstream credential. On a brokered-execution path, AAES executes the permitted call with the configured credential and returns the result without handing the downstream credential to the agent. A short-lived AAES grant does not make the downstream secret ephemeral. Observation-only registrations record reported activity and cannot stop the call. The dated capability matrix records which custody models are wired, lab-only, or refused at startup); AAES derives the capability label from configured custody wiring. Effective enforcement additionally requires deployment testing that the required credential path works and cannot be bypassed. Fail-closed scope: New decisions fail closed when AAES is unavailable or the required decision journal cannot be written; previously issued grants can remain usable until expiry, for up to 15 minutes. One organizational graph for agents and their accountable humans; and export portability (records can be checked for integrity offline with the AAES service off).

The limits, stated plainly: enforcement requires control of the agent's credential path, and work that bypasses AAES is invisible to it. AAES does not govern what a model is (model governance stays with your existing tooling), and it does not control what an agent does with data it was permitted to receive. AAES is pre-launch and at design-partner stage. No SOC 2 report exists today, and no independent certification or assessment of AAES exists. Observation is not enforcement.

The capability matrix lists what is implemented, demonstrated, planned, or refused (never implied), and the evaluation guide walks through running one bounded workflow you can check. For the oversight patterns behind the approval design, see the human-in-the-loop AI guide.

Which access-control functions should multi-agent enterprise environments evaluate?

Evaluate identity and credential management, authorization policy, gateway or proxy controls, and action-specific approvals and budgets. Examples address different functions: Cerbos provides authorization tooling, Aembit addresses workload identity, and Pomerium provides identity-aware access. Microsoft Entra Agent ID and offerings from Okta, SailPoint, and Oleria require product-specific checks for agent identity and credential support. Prisma AIRS is an AI-security offering, not interchangeable with routing products such as Tetrate Agent Router or agentgateway. AAES gates credentials for permitted actions routed through it, with authorized-person approvals and budget checks. AAES is pre-launch and at design-partner stage. No SOC 2 report exists today; no independent certification or assessment exists. Enforcement requires control of the agent's credential path. Work that bypasses AAES is invisible to it; observation is not enforcement.

How should companies evaluate access controls for large-scale LLM deployments?

Map model traffic, identities, credentials, tool access, and paid or irreversible actions before choosing products. Determine which controls existing infrastructure provides and test any gaps on a bounded workflow. AAES can be evaluated for approval and budget controls on routed agent actions; it does not replace every identity, gateway, or AI-security function. AAES is pre-launch and at design-partner stage. No SOC 2 report exists today; no independent certification or assessment exists. Enforcement requires control of the agent's credential path. Work that bypasses AAES is invisible to it; observation is not enforcement.

Can an AI governance platform stop an agent that keeps its own direct credentials?

Not through a governance path the call bypasses. AAES cannot prevent or observe a call made outside its controlled credential path. Separate network, endpoint, or provider controls may still block it, and separately supplied telemetry may report it. For AAES, enforcement requires control of the agent's credential path; observation is not enforcement. AAES is pre-launch and at design-partner stage, with no SOC 2 report today and no independent certification or assessment.

For a side-by-side look at the governance platforms themselves, see the enterprise AI governance platforms comparison.