Agentic AI governance: what it is, and the controls it takes
Agentic AI governance is deciding in advance what an autonomous agent is allowed to do, enforcing that decision on every action it takes, and keeping a record a reviewer can check afterwards. It is not model governance, which asks whether a model is fit to use, and it is not observability, which tells you what an agent did once it had already done it. Three controls carry it: a certification gate before production, an inline decision on every action at runtime, and an append-only audit trail. This page sets out each control, the standards it answers to, and where a programme should start.
Four things AI governance already means, and why none of them covers this
Most enterprises already run at least two of these. Each one is correct for its own problem, and each one stops short of the action an agent takes.
- Model governance
- Asks whether a model is fit to be used at all: training data, bias, documentation, approval to deploy. Agent governance: Takes the model as given and governs the actions the agent takes with it. A fully approved model can still issue a refund it should not have.
- Observability and evals
- Tell you what an agent did, after it did it, and how a version scored on a test set before release. Agent governance: Runs in the execution path. The decision is returned to the SDK before the downstream action executes, so a wrong action is prevented rather than reported.
- Prompt guardrails
- Instruct the model to behave, inside the same context window an attacker can write into. Agent governance: Runs outside the model. Guardrails are evaluated independently of the agent's instructions, so they cannot be argued away by the text the agent was given.
- Application security
- Protects the system the agent runs on — identity, network, secrets, dependencies. Agent governance: Protects against what an authenticated, authorised agent decides to do with permissions it legitimately holds.
Three controls, in the order an agent meets them
Before production, during every action, and afterwards for whoever asks. Each is a product page of its own; this is what each one is for.
A gate before production
Six engines run before an agent ships: discovery, attack, reliability, reasoning, compliance, and the aggregate certification score. The attack engine covers prompt injection, jailbreaks, tool abuse, memory poisoning and role escalation; the reliability engine runs the same agent thousands of times to measure variance rather than take one passing demo.
A decision on every action
Validation runs six deterministic checks — schema, evidence grounding, tool trust, contradiction, consistency, active policy. Confidence is a weighted composite of seven signals. Risk converts that into a tier using the business exposure of the action. The decision engine then returns approve, block, escalate, request_evidence or retry, before the action executes.
A record a reviewer can read
Every execution is appended to the audit ledger with the full envelope — agent id, framework, SDK version, input, output, every engine score, the decision, and the policy clause that produced it. Hash-chain verification is available on the enterprise tier, so a record cannot be rewritten after the fact.
The product that implements all three is AgentTrust OS — the platform overview is the page for what it is and how it deploys. The architecture is documented under how it works.
A governance decision is one of five outcomes
Every action an agent takes resolves to one of these, evaluated against the policy version in force at that moment and returned to the SDK before anything downstream runs.
approve- Every check passed and the risk tier is inside the policy's threshold. The action proceeds.
block- A policy or risk threshold was failed. The action does not execute, and the failure is recorded with the rule that caused it.
escalate- The decision is pushed to a human review queue, carrying the validation failures, the confidence breakdown by signal and the risk factors — so the reviewer sees why, not only what.
request_evidence- The agent is asked to produce sources for a claim it has not grounded, and the action waits.
retry- A transient confidence problem, re-run as an explicit outcome rather than an unbounded loop.
Each decision carries a risk tier — low, medium, high or critical — derived from the validation flags, the confidence score and the business exposure of the action. The reference for the outcomes is in the decision-outcomes documentation.
The same control set, three kinds of obligation
None of these frameworks asks for a governance product. They ask for controls that operate and evidence that they did.
ISO/IEC 42001
An AI management system needs documented controls and evidence they operate. The ledger and the compliance reports are that evidence, generated from execution history rather than written up afterwards.
EU AI Act
High-risk obligations include human oversight, logging and traceability. Escalation is the oversight mechanism, and the append-only ledger is the log.
SOC 2, HIPAA, GDPR, PCI DSS, SOX
Compliance packs for each ship with Trust Certify, and Trust Audit exports reports from your own execution history — decision counts, block rates, escalation logs and retention summaries mapped to control requirements.
The detail, standard by standard, is on AI compliance for agents. For the security-risk taxonomy rather than the regulatory one, see the OWASP Top 10 for Agentic Applications crosswalk.
The governance writing on this site, in reading order
Start with the gap
How the enforcement works
If the agents you need to govern are not all on a list yet, start at shadow AI — an inventory is the precondition for every control above.
The obvious questions
- What is agentic AI governance?
- Agentic AI governance is the practice of deciding in advance what an autonomous agent may do, enforcing that decision on every action it takes, and keeping a record a reviewer can check afterwards. It covers the actions an agent performs, not only the model it performs them with.
- How is it different from AI governance generally?
- AI governance in the broad sense is largely about models and data: what a model was trained on, whether it is documented, who approved it. Agent governance begins after that, at the point where an approved model is given tools, permissions and a loop, and starts taking actions nobody reviews individually.
- Is observability enough?
- Observability tells you what happened. For an agent that can refund a customer, write to a ledger or call an external API, knowing afterwards is not a control — the action already landed. Enforcement has to run in the execution path, which is what distinguishes a gate from a dashboard.
- Where should a governance programme start?
- With measurement, not policy. Run the pipeline against your existing agents with enforcement switched off and read your own block rate and risk distribution. Writing policy before you know what your agents actually do produces a document, not a control.
- Who owns agent governance inside a company?
- In practice it is shared, which is why the evidence matters: the engineering team owns the contracts and the integration, risk and compliance own the thresholds and the reporting, and both need to be looking at the same execution record rather than two reconstructions of it.
- Do we have to change our agent code?
- Not necessarily. A single @harness decorator wraps a function, and the auto-instrumenter patches OpenAI, LangChain and LangGraph in place for agents you would rather not touch. Both are reversible — remove_patches(), or AGENTRUST_ENABLED=false and a restart.
