An AI agent governance platform built around authority
Governing an agent means governing authority, not output. Register every agent with an accountable owner, evaluate its authority per action, narrow it on delegation, and keep the record of what it did.
The problem
What this is actually about
Model governance asks whether an output is accurate. It is the right question until the software can act, and then it stops being the interesting one: the risk is no longer what the model said but what it did, with whose authority, to which system.
The common modelling error is treating an agent as one identity. A privileged action involves three distinguishable things — the agent, the principal it acts on behalf of, and the credential it presents downstream — and collapsing them makes attribution impossible. When an audit asks who approved a change, "the automation account" is the absence of an answer.
What the platform does about it
Read from the product architecture rather than written here, so this page cannot promise something no module ships.
Who owns each agent, and can it prove what it is?
- A stable agent identity that does not change when the model, infrastructure, credential or deployment does
- Business, technical and security ownership, with an orphaned-agent warning when nobody holds it
- A declared purpose that later becomes part of the authorization decision
- Machine authentication by workload identity, mutual TLS, signed JWT and short-lived tokens rather than permanent keys
- A lifecycle from discovery through review, approval, production, recertification and retirement
What is this agent allowed to reach?
- Role and attribute rules evaluated with agent, user, tenant, data, tool, environment, time, risk and declared purpose in context
- Action-level permissions, so reading a supplier and changing its bank details are separate grants
- Five sensitive action classes from read through draft, reversible execution, human approval and dual approval
- Just-in-time privileges that are issued for one action and expire rather than accumulating
- A credential broker that issues scoped, short-lived secrets on request, so an agent never holds a permanent key
Under which rule was this decided?
- Rules authored in natural language, compiled to structured policy, and verified by a human before activation
- Conditions over agent, owner, department, tool, action, resource, data class, geography, environment, time, risk, user, transaction value and tenant
- Simulation against historical traffic, so a rule states what it would have blocked before it blocks anything
- Versioned policy, with every decision recording the version that produced it
Has it been tested, and is it still the version we approved?
- Security tests for prompt injection, privilege escalation, data leakage and unsafe external calls
- Permission tests that try to exceed the role and cross the tenant boundary
- Tool behaviour tests for dangerous calls the task never required
- Regression testing between agent versions
- Certification from development through internal, approved, production and high-risk
- Recertification when the model, prompt, tools, MCP servers, permissions, data sources or owner change
What it leaves behind
The artefacts these modules produce. Evidence generated by a decision, rather than assembled for an audit afterwards.
- An owner of record for every production agent
- A purpose declaration an out-of-scope action can be measured against
- A permission inventory showing where an agent exceeds its purpose
- An expiry on every elevated grant
- A credential ledger: which agent held what, against which system, and when it lapsed
- A simulated impact figure before activation
- A policy version stamped on every decision
- A certification record per agent version
- A diff between versions with the resulting risk change
See it working
Every claim above has somewhere on this site you can go and check it.
- Questions answered from the estate
Which identities reach customer data, move money or hold a secret that never expires.
- Delegation that narrows
Why a receiving agent must never end up with more authority than the one that handed it work.
- The lifecycle, specified
Registration, certification, recertification triggers and retirement as written requirements.
Common questions
- Can our existing IAM govern AI agents?
- Partly. IAM represents identities and grants well, but it was built for humans and long-lived service accounts. It usually has no model for an agent acting on a person’s behalf, delegating to another agent, or having its authority evaluated per action rather than at grant time.
- What has to be recorded per agent?
- An accountable owner with a review date, a stated purpose, the provider, model and framework, the environment and trust state, the authority currently reachable rather than the authority originally requested, and delegation relationships in both directions.
- What happens when an agent changes after it was approved?
- A change to a sensitive attribute — the model, the purpose, the owner, the permissions, the tools — moves its configuration hash, and the next consequential action it takes is held for review rather than allowed on a certification that describes something else.
- How is an agent retired?
- Retirement is terminal and it is not just a status change: the credentials it held are revoked, and the estate can be asked to prove no retired agent still holds an active privileged credential.