Technical guide

Governed AI Agents: Authority, Approval, and Evidence

A practical architecture for governing tool-using AI agents with identity, purpose, action tiers, approvals, replayable evidence, and human stop conditions.

Direct answer

Direct answer: Governed AI agents

A governed AI agent is not merely a model with a safety prompt. It is a runtime system in which the agent’s identity and purpose are explicit, every tool is classified by the effect it can cause, high-impact actions require policy checks or human approval, and each decision and side effect leaves evidence that can be reviewed and replayed. The control boundary belongs around the action, not only around the text the model produces.

Written for AI platform teams, financial services, security engineers, governance leaders, and operators deploying tool-using agents.

Architecture

The operating principles

01

Bind identity to purpose

An agent needs a workload identity and a declared purpose. Policy should be able to distinguish the same tool used for two different jobs, customers, or risk contexts.

02

Classify effects before tools

Reading public data, proposing a payment, changing a customer record, and executing an irreversible transfer are different authority classes even when one API exposes all four.

03

Authorise the exact action

Approval should cover the concrete resource, value, destination, and time window—not a broad tool name or a conversational promise that the agent will behave.

04

Separate decision from execution

A model may recommend an action while a deterministic policy layer decides whether it can proceed, needs a person, or must be refused.

05

Preserve evidence and a stop path

Policy inputs, decisions, approvals, tool receipts, and recovery state need a durable record. Operators also need a kill switch that works independently of the model.

Evidence

What supports this view

Public reference system

CloseGate

A Python and MCP policy layer with 19 tools, action tiers, segregation of duties, materiality and sensitive-account routing, mandatory approval for irreversible actions, and hash-chained replayable audit.

Inspect the source ↗
Public reference system

Regulus

A runtime-governance architecture for agent identity and purpose, policy, PII, residency, model-risk tiers, kill switches, human oversight, evidence export, and agent-to-agent controls.

Inspect the source ↗
Delivery experience

Regulated banking AI

At Aveni, Dipankar architected enterprise banking AI with conduct-risk workflows, evidence generation, human review, escalation, evaluation, versioning, and release controls. He was part of the Aveni team in the first FCA Supercharged Sandbox cohort.

Inspect the source ↗

Scope and limitations

Where the result applies

  • CloseGate and Regulus are public reference systems. Neither has a published independent certification or customer deployment.
  • Mapping controls to NIST AI RMF or ISO/IEC 42001 does not constitute certification or legal compliance.
  • The appropriate approval and evidence model depends on the organisation, jurisdiction, action, and accountable human owner.

Common questions

Answers in plain language

What is the difference between an AI guardrail and agent governance?+

A guardrail usually constrains model input or output. Agent governance also controls identity, authority, tool effects, approval, evidence, recovery, and organisational accountability after a model has made a decision.

Should every AI agent action require human approval?+

No. Low-impact, reversible, well-observed actions can be automatic. Approval should be reserved for material, sensitive, ambiguous, or irreversible effects, with policy deciding which class an action belongs to.

Where should policy enforcement happen in an MCP system?+

At or immediately before the boundary that can cause the real effect. A policy decision in the prompt is insufficient if the MCP tool or downstream API can still execute a broader action.

What evidence should a governed agent retain?+

At minimum: workload identity, declared purpose, policy version and inputs, decision, approval if any, exact tool request, redacted response or receipt, state transition, and recovery or reconciliation outcome.

Continue exploring

Apply the architecture to a real system.

Bring a specific outcome, failure mode, or audience. The next step can be an architecture review, prototype, talk, or workshop.