AI agent governance: approvals, identity and audit

AI agent governance is the set of mechanisms that decide, before an agent's action runs, who is acting, whether they are allowed, whether a person must approve, and what is recorded. It is enforced in software on every call. Policy documents, risk registers, and dashboards describe and observe governance; the mechanisms are what make it hold.

Why are policy documents not enough?

A policy document says agents must not make payments above a limit without approval. It cannot stop the agent that tries. Agents call tools, and a tool call either reaches the payment system or it does not. The decision has to be made by something in the path of that call, before it runs, using the call's actual arguments.

The same is true of inventories and dashboards. Knowing which agents exist and charting what they did is useful and often the first step. But a registry describes agents, and a dashboard reports after the fact. The test of which kind of governance you have is simple: ask for the record of one call that was refused, and what the caller saw. Governance that only watches cannot produce it. Governance is not a dashboard works through this distinction, and Agent control planes vs application platforms explains where each layer sits.

What are the mechanisms of AI agent governance?

Seven mechanisms carry most of the weight. Each answers one question, and each can be tested.

Agent identity: who is acting?

Every action needs an actor the enterprise can name. Three patterns cover most cases. An agent with its own identity, for system or scheduled work, holding credentials scoped to the systems it needs and nothing more. An agent acting on behalf of a user, carrying a delegated token that names both the person and the agent, so the record shows who asked and which agent did the work. A workflow running as a service principal. What governance rules out is the shared service account that every agent borrows, because the record then says the account did it and cannot say who asked.

Two rules keep identity honest as work moves between agents. A child call never has more authority than its parent: when an agent delegates to a subagent or calls a tool, the callee's permissions are a subset of the caller's. And the actor chain is kept, not flattened: person, agent on behalf of person, workflow.

Authorization on every call: is this allowed?

Authorization must run on every call, from every entry point, against the same model. If the user interface checks permissions one way, the chat another, the API a third, and scheduled jobs not at all, the four will drift. One check, before dispatch, covering membership, role, and the specific entity being touched (this cost center, this project, this review queue), is the target. It should fail closed: any uncertainty is a refusal.

Reading a record and approving a change are separate permissions. So are running an operation and changing the policy that governs it.

Human in the loop as policy: does a person need to approve?

Approval should be a policy over the action's typed arguments, not a flag on the tool. A flag approves the tool, so every call to it either always needs a person or never does. A policy can say: below 25,000 USD, run directly; at or above, require the controller group; if the invoice reference is missing, deny. Thresholds, membership, existence checks, and compound rules over them.

When a call trips the policy, four details decide whether the approval means anything:

• Frozen invocation. The exact operation, arguments, scope, and evidence are held under a hash while people decide. The agent cannot change them while it waits.
• Named lanes. Each required group is a separate obligation. One approver cannot satisfy two lanes, and the person who proposed the action is not an eligible reviewer of it unless the policy says so.
• Eligibility at decision time. Whether the reviewer may approve is checked when they click, not when the request was assigned. A reviewer removed from the group yesterday cannot approve today.
• Revalidation before dispatch. After approval, the frozen call is checked again against current policy and authority, then dispatched once, idempotently, so a retry returns the original receipt rather than repeating the effect.

Approval is a policy, not a boolean walks through the failure cases this design prevents.

Audit written before execution: what is the record?

The audit record should be written before the action runs, in the same transaction that claims the call's idempotency key. Then a refused call leaves the same evidence as an admitted one, and a crash between decision and effect leaves a record rather than a gap. A useful record names the actor chain, the application version that governed the call, the operation and scope, the exact resource versions touched, the policy outcome and who satisfied each approval, the effects and their receipts, and the context the agent used.

Non-disclosure: what does a refused caller learn?

When a caller is not allowed to see something, it should be absent, not denied. A "permission denied" on a named record confirms that the record exists. Unauthorized items should be missing from listings and return not-found on direct requests, with the refusal kept in the audit record rather than in the response.

Versioning and rollback: which rules governed this call?

Agent configuration, tools, and approval policies change. Governance requires knowing which version governed a given call, and being able to return to a prior one. Configuration should compile into immutable versions; activating a version should be an audited act by an authorized owner; rollback should be the activation of a prior version, not an edit.

Evaluation: is the agent still doing the job?

Agents drift as models, prompts, data, and tools change. Evaluation runs deterministic checks first (tool error rates, token growth, required fields present) and model-based judgment second, on test sets before release and on production runs after. It is a governance mechanism because it is how an owner knows that an approved configuration still behaves the way it did when it was approved.

What is the difference between human in the loop and human on the loop?

Human in the loop means a person acts before a specific action runs. The action waits for an eligible reviewer, and nothing happens until they decide. Human on the loop means the agent acts on its own while a person supervises, with the ability to intervene, pause, or reverse.

Neither is better in general. The governance question is which applies to which action, and the answer should be a policy, not a product setting. Drafting a variance commentary can run with people on the loop: they read and revise the output afterward. Posting a journal entry above a threshold, paying a new vendor, or sending an external notice should put people in the loop. Good governance lets one application use both, chosen per call by the action's arguments.

What is durable execution for AI agents?

Durable execution means a run's state is persisted as it progresses, so it survives process crashes, restarts, and deployments and resumes where it stopped. Temporal, a widely used durable workflow engine, describes it this way: once a workflow starts, it runs to completion, "whether that takes a second or a year."

For agents, durable execution is what makes human in the loop workable. An approval can take three days. The run must wait without holding a server, survive the deployment that happens on day two, and resume exactly once when the decision arrives. Durable execution is necessary but not sufficient: it guarantees the run resumes, while the approval design above guarantees that what resumes is what the reviewer approved.

How does agent governance map to frameworks and regulation?

Frameworks set outcomes. The mechanisms above are ways to meet them and produce the evidence that they were met.

Two notes on scope. The EU AI Act's Article 14 and Article 12 obligations apply to systems classified as high-risk, not to every agent. And the dates have moved: the Council of the EU states that, under the AI omnibus it approved in 2026, high-risk rules apply from December 2, 2027 for stand-alone high-risk systems and August 2, 2028 for high-risk AI embedded in products. Whether a specific agentic application is high-risk is a legal determination for counsel. None of these frameworks certifies a product, and meeting them is a property of an organization's whole program, not of one tool.

How Pyrana implements agent governance

Pyrana builds these mechanisms once into the platform, and every agentic application inherits them. Every call into a Pyrana App, from its pages, the copilot, the API, MCP, a schedule, or an external event, passes one eight-step gate: identity and idempotency key, active App version, target and caller, exact resource versions, one authorization check, idempotency claimed with the execution row and audit record written in one transaction, dispatch, and outcome recorded. The gate fails closed, and unauthorized things read as absent.

Identity is explicit: an agent with its own identity, an agent on behalf of a user, or a workflow as a service principal, all on the same authorization path through tenant, App membership, access profile, and scope entitlement, with OpenFGA for relationship checks. Tool approval policies over typed arguments freeze qualifying invocations under a hash and queue them to named approval lanes; reviewer eligibility is checked at decision time, the frozen invocation is revalidated before dispatch, and dispatch is idempotent. Workflows run on Temporal workers, so a run waiting for an approval survives a restart or deploy and resumes.

Push compiles an App configuration into an immutable version, activation is audited and requires an App owner, and rollback is an activation of a prior version. The eval pipeline runs deterministic checks, then LLM-as-judge in Agent Studio. cortIQ accounts for the knowledge each run retrieved, injected, and cited, so the context behind an action is part of its record. Pyrana is SOC 2 aligned and supports customer programs under HIPAA, SOX, ISO 27001, and PCI DSS. For the runtime in depth, see the Pyrana Harness and Security.