AI agent governance maturity self-assessment.

Governance is four layers, and they only work together: identity (who is calling), permissions (what each agent may do), audit (proof of what happened), and data residency (where your data and model run). Your overall maturity is your weakest layer, not your average, because a single ungoverned layer undermines the rest. Pick the option that honestly describes you today. The model behind this is explained in The State of AI Agent Governance.

Private by design: this assessment runs entirely in your browser. Your answers are never transmitted, stored, or logged, and there is no analytics on what you pick. Check it yourself: answer with your browser's network tab open and scoring fires no requests.

Question 1 of 7

Identity

1. Accounts: how do people sign in?

Everyone shares one login or token. Each person has an individual account. Individual accounts, centrally managed (created and revoked by an admin). Individual accounts tied to a verified identity (SSO or per-user invite).

Next

Go deeper: the full twelve-question audit (optional)

The seven questions above place each layer. For a board-ready picture, this longer version asks three questions per layer (the model, where it is enforced, and the detail), so a single strong answer cannot mask a weak one. A layer's level is the lowest its three answers support. Everything still runs in your browser.

Identity

Whether the system can tell, per action, which real person is behind it.

Accounts: how do people sign in?

Everyone shares one login or token. Each person has an individual account. Individual accounts, centrally managed (created and revoked by an admin). Individual accounts tied to a verified identity (SSO or per-user invite).

Roles: is access differentiated by who someone is?

No roles: everyone can do everything. An informal split (a couple of people are "the admins"). Defined admin and member roles, enforced by the system. Roles plus group scoping, so access narrows to the right team.

Attribution: when an agent acts, who is it acting as?

A shared service account: actions trace to no one. One bot account for everyone's agent use. Actions are attributable to the user who triggered them. Every action carries the real user's identity end to end.

Permissions

What an agent can actually reach, and how that limit is enforced.

Model: how is an agent's access decided?

Broad access by default, kept in line by a prompt. Broad access, with some tools turned off (a deny-list). Each agent is given a specific set of tools. Per-agent allow-list, default-deny: nothing until explicitly granted.

Enforcement: where does the limit actually live?

In the system prompt or the agent's instructions. In configuration the agent could be talked around. In the application, checked before most actions. In code, outside the model, checked on every tool call.

Granularity: how specific are the grants?

Whole integrations on or off ("the agent can use email"). A few coarse toggles per integration. Per-tool grants ("send email", not "use the mailbox"). Per-tool grants scoped further by data or action ("read sales orders").

Audit

Whether you could prove, to a third party, what an agent did.

Coverage: what gets recorded?

Nothing reliable, or only scattered app logs. Logs exist but are not centralized. Centralized logging of agent actions. Every agent action and tool call is recorded in one place.

Integrity: could the record be quietly altered?

Yes: log files anyone with access can edit. Edits are possible but would need elevated access. Logs are append-only. Each entry is signed and tamper-evident; alteration is detectable.

Verifiability: could someone else check it?

No: you would have to take our word for it. An admin can view the logs. Logs can be exported for review. Exports are independently verifiable by a party who was not there.

Data residency

Where your prompts, documents, and the model itself actually run.

Application: where does the agent platform run?

A vendor's cloud SaaS. A managed cloud instance you rent. Self-hosted on infrastructure you control. Self-hosted, and able to run with no inbound internet (air-gappable).

Model: where does the model run?

A cloud model API; every prompt leaves your boundary. A cloud model with a data-processing agreement, but data still leaves. A local model is an option but not the default. A local model runs in your boundary; prompts never leave.

Egress: what else reaches out to the internet?

Unknown: the platform calls out and you cannot fully say where. Several external services are in the loop (telemetry, search, storage). External calls are limited and known. No external calls are required to operate.

Show my detailed result