AI Governance Platform / Criteria

How We Compare: The Evaluation Criteria

Every platform on this site is held to the same seven criteria. For each one, we record whether the vendor's own public pages or documentation describe it, link the source, and give you the steps to verify it yourself in a demo or trial.

Documented

The vendor's site or docs describe the capability directly.

Partial

Described with a narrower scope, on a higher plan, or on request only.

Not documented

Not found in public sources. It may exist; ask the vendor and ask for it in writing.

These are statements about what is published, not star ratings. We don't score vendors on prices, reviews or numbers they haven't published. Where a fact isn't public, the table tells you where to check it.

Criterion 1

Coverage of agents and MCP

Which AI traffic the platform actually sits in front of or sees: MCP servers and tool calls, the AI clients employees use (Claude, ChatGPT, Cursor and others), agents your engineers build, and agents running inside SaaS products.

Why it matters

A platform can only govern what passes through it or what it can observe. Most gaps in AI governance programs come from traffic that never reaches the control point: a local MCP server on a laptop, a coding agent, an agent built into a SaaS tool.

Documented

Public docs describe coverage of MCP tool calls and agents across several clients or environments.

Partial

Coverage is limited to one kind of traffic (for example MCP only), or the platform records AI systems without sitting in their runtime path.

Not documented

Not described in public sources.

How to verify it

  • List the AI clients and agent frameworks you use today and check each against the vendor's published client and integration list.
  • Ask for a demo with a local (stdio) MCP server, a remote MCP server and one agent your team built, and watch each call appear.
  • Check whether model (LLM) calls are covered as well as tool calls, if you need both.

Ask the vendor

  • Which AI clients and agent frameworks are supported today, and which are on the roadmap?
  • Do local MCP servers on employee devices pass through your controls, and how?
  • Do you cover agents built into SaaS platforms, or only agents we connect ourselves?

Where each platform stands

Criterion 2

Identity and permissions

How the platform ties each AI action to a person or an agent identity, connects to your identity provider, and scopes what each user, group, agent and tool is allowed to do.

Why it matters

Shared service accounts and long-lived tokens pasted into config files make agent actions impossible to attribute or revoke. Delegated, scoped credentials are what make an agent's access accountable.

Documented

Public docs describe identity-provider integration plus per-user or per-agent scoping of tools and credentials.

Partial

Role-based access exists, but per-agent identity or delegated credentials are not described.

Not documented

Not described in public sources.

How to verify it

  • Confirm the SSO protocols (SAML, OIDC) and user provisioning (SCIM) you need are listed, and on which plan.
  • Ask to see how one agent gets its own credentials and how they are revoked without affecting the user.
  • Check how OAuth tokens for downstream tools are stored and refreshed.

Ask the vendor

  • Can an agent act as its user without inheriting all of that user's permissions?
  • Where are downstream OAuth tokens stored, and who can read them?
  • Is SSO or SCIM limited to a higher plan?

Where each platform stands

Criterion 3

Audit logs

A record of who (person or agent) called which tool, with what inputs and outputs, what policy decided, and when; plus the ability to export that record to your SIEM or observability stack.

Why it matters

When something goes wrong, or an auditor asks, the log is the evidence. Logs that can't leave the vendor's console, or that don't attribute the call to a real identity, rarely satisfy either.

Documented

Public docs describe tool-call level logs with attribution, and an export path.

Partial

Logs exist, but attribution detail or export is not described.

Not documented

Not described in public sources.

How to verify it

  • Ask for a sample log record and check it names the user, the agent, the tool, the decision and the time.
  • Confirm the export path (OpenTelemetry, SIEM connector, API) and whether it is on your plan.
  • Ask how long logs are retained and where they are stored.

Ask the vendor

  • Can we redact sensitive values before they are logged?
  • Do you export over OpenTelemetry, and to which SIEMs have customers connected?
  • Are logs tamper-evident?

Where each platform stands

Criterion 4

Policy enforcement

Whether the platform can act on a request as it happens: allow or block tools, require human approval, redact sensitive data, and detect prompt injection, tool poisoning or exfiltration before an action reaches your systems.

Why it matters

Visibility tells you what happened; enforcement decides what is allowed to happen. The depth that matters is the tool call: a policy that can only allow or deny a whole server is much coarser than one that inspects each call and its result.

Documented

Public docs describe inline, per-call enforcement such as blocking, approval or redaction, plus runtime threat detection.

Partial

Policies exist but are not described as enforced inline on each call, or cover a narrower set of actions.

Not documented

Not described in public sources.

How to verify it

  • Write one policy you actually need (for example: block deletes in production, redact customer emails) and ask the vendor to show it enforced live.
  • Check whether detection can run in alert-only mode first, so you can set a baseline before blocking.
  • Ask what happens to latency when inspection is on.

Ask the vendor

  • Is enforcement in the request path, or after the fact?
  • Can a risky action be routed to a human for approval?
  • Who maintains the detection rules, and can we add our own?

Where each platform stands

Criterion 5

Shadow AI discovery

Finding AI use you didn't approve: unmanaged MCP servers, AI client configs, skills, plugins and agents on employee devices or in SaaS, so they can be brought under policy or removed.

Why it matters

Governance that only sees the approved path misses the usage most likely to cause an incident. Discovery tells you how big the unmanaged surface is before you decide what to approve.

Documented

Public docs describe a discovery capability (device, SaaS or cloud) for unmanaged AI.

Partial

Unmanaged usage is addressed indirectly, for example by routing traffic through a gateway or observing specific clients only.

Not documented

Not described in public sources.

How to verify it

  • Ask how discovery is deployed (MDM package, browser extension, API connectors) and whether employees must opt in.
  • Check which operating systems and clients discovery supports.
  • Run discovery on a pilot group and compare the findings with what you thought was in use.

Ask the vendor

  • Does discovery need an agent on each device?
  • Can discovered tools be moved onto the approved path in one step?
  • Which operating systems are supported, and with what limits?

Where each platform stands

Criterion 6

Compliance mapping

Whether the platform maps its controls and evidence to frameworks such as the EU AI Act, NIST AI RMF and ISO/IEC 42001, and what attestations the vendor itself holds (SOC 2, HIPAA).

Why it matters

Risk and compliance teams need evidence organized the way auditors ask for it. A vendor's own SOC 2 report tells you the vendor is run carefully; it doesn't map your AI use to a framework.

Documented

Public docs describe mapping controls or evidence to named AI frameworks.

Partial

The vendor holds its own attestations or produces logs for audits, but framework mapping is not described.

Not documented

Not described in public sources.

How to verify it

  • Ask for the vendor's SOC 2 report and any HIPAA or ISO certificates through its trust center.
  • If you need framework mapping, ask to see a report mapped to the framework you are audited against.
  • Check whether framework content is updated when regulations change, and by whom.

Ask the vendor

  • Which frameworks do you map to, and can we export that evidence?
  • Is your SOC 2 Type I or Type II, and when was it last issued?
  • Will you sign a BAA or DPA?

Where each platform stands

Criterion 7

Deployment

Where the platform runs: multi-tenant SaaS, single-tenant hosted, self-hosted in your cloud, on-premises or air-gapped; and where your data and logs reside.

Why it matters

Regulated teams often can't send tool inputs and outputs to a shared vendor cloud. Deployment options decide whether a platform is even eligible before features are compared.

Documented

Public docs describe a self-hosted or customer-cloud option alongside the hosted service.

Partial

Hosted only, or self-hosting is available on request without published detail.

Not documented

Not described in public sources.

How to verify it

  • Read the vendor's deployment documentation, not only the marketing page, for supported clouds and requirements.
  • Confirm the data residency regions available today, not on the roadmap.
  • Ask whether self-hosted customers get the same features and update cadence.

Ask the vendor

  • Is the hosted service single-tenant or multi-tenant?
  • Which clouds and Kubernetes distributions do you support for self-hosting?
  • Which regions can store our logs today?

Where each platform stands

Back to the comparisonUse the buyer's checklist