How is agent governance different from prompt-level guardrails?

A prompt-level guardrail instructs a model. Prompt injection and jailbreaks exist to defeat instructions, and a compromised agent will happily explain that its dangerous tool call is legitimate. Agent governance sits outside the model: the checkpoint evaluates the proposed call itself against a policy the organization owns, so a model that has been talked into something still cannot execute it.

What checks run on a proposed agent action?

Three action checks. A tool allow-list blocks calls to tools the agent is not permitted to use. A privilege-scope check escalates actions that exceed the permissions the agent was granted. A parameter-risk check escalates actions whose parameters look dangerous. The content detectors for personal data, safety and prompt injection also run against the action's parameters, so a tool call carrying a national ID is caught the same way an output carrying one is.

Why must an agent's granted scopes be attested rather than self-declared?

Because a scope the model supplies is a claim, not a fact. If the AI model itself declares which permissions it holds, a manipulated agent simply claims broader permissions and the privilege-scope check approves whatever it asked for. The granted scopes must be attested by the calling service, which knows what the agent was actually issued. This is the single most common way an agent authorization design is defeated.

Which OWASP risk does agent governance address?

OWASP LLM06, Excessive Agency, which covers an AI system having more functionality, permissions or autonomy than it should. Tool allow-lists, privilege-scope checks and parameter screening turn that risk from a line in a policy document into an enforced control with an evidence record behind every decision.

Use case

AI agent governance

Q: What is AI agent governance?

AI agent governance is deciding whether an autonomous AI agent may perform an action before it performs it, rather than reviewing what it did afterwards. In practice that means the agent submits a proposed tool call, with the tool name, the parameters and the scopes it was granted, to an authorization checkpoint that returns allow, block or escalate. Governing outputs is not enough once an AI can act, because the damage from an action is done at execution time.

Q: Does Turrigan execute the agent's actions?

No, and this is deliberate. Turrigan authorizes or denies the decision to act, and the agent's own orchestrator executes or abandons the call. Turrigan is a control point, not the agent's runtime, which keeps the blast radius of the control plane small and means adopting it does not mean handing over execution.

AI agent governance is deciding whether an agent may perform an action before it performs it. The agent submits a proposed tool call, with the tool name, the parameters and the scopes it was granted, and gets back allow, block, or escalate. Turrigan authorizes the decision to act. It never executes anything itself.

Why governing outputs stopped being enough

Text governance assumes a human sits between the model and the consequence. That assumption held while AI only answered questions. It does not hold for an agent that reads a ticket, decides a refund is warranted and calls the payments tool, all before anyone reads a word of it.

The difference matters because of when the damage lands. A bad output is harmful when someone reads it, which leaves a gap where review is still possible. A bad action is harmful at execution. There is no gap. Whatever control you want has to sit before the call, not after it.

Why prompt-level controls do not provide this

The usual answer is to instruct the model: tell it which tools it may use, tell it to be careful with payments, tell it to refuse suspicious requests. That is a request, not a control. Prompt injection and jailbreaks exist precisely to defeat instructions, and an agent that has been talked into something will argue fluently that its dangerous tool call is the legitimate one.

Worse, the failure is quiet. A model that has been manipulated does not report that it has been manipulated. It executes, logs a plausible reason, and moves on. The control has to live outside the model, where an argument cannot reach it.

The three action checks

Every proposed action is submitted to POST /v1/govern/action with the tool, the parameters, the agent identifier and the granted scopes. Three checks run against it:

Tool allow-list. Blocks calls to tools this agent is not permitted to use. An agent that was never granted the payments tool cannot call it, regardless of how convincingly it explains why it should.
Privilege scope. Escalates actions that exceed the permissions the agent was granted. The agent may hold email:send and still be stopped from reaching for email:send_all.
Parameter risk. Escalates actions whose parameters look dangerous, because the tool being permitted does not make every possible argument to it safe.

The content detectors run against the parameters as well, so a tool call carrying a national ID or a prompt-injection payload is caught the same way an output carrying one is. An agent exfiltrating data through a permitted tool is a real pattern, and screening only the tool name misses it entirely.

The mistake that defeats most agent authorization designs

A privilege-scope check is only as good as the scopes it is given, and there is one way to get this wrong that quietly disables the whole control.

The granted scopes must be attested by the calling service, not supplied by the AI model. If the model declares its own permissions, a manipulated agent claims broader ones and the scope check dutifully approves whatever it asked for. The check still runs, still logs, still reports green, and enforces nothing. Scopes have to come from the service that issued them and knows what the agent actually holds.

This is worth saying plainly because it is the most common way an otherwise sound design is defeated, and because a control that reports success while enforcing nothing is more dangerous than no control at all.

Authorize, do not execute

Turrigan returns a verdict to the agent's orchestrator, which then executes the call or abandons it. Turrigan is a control point, not the agent's runtime.

That boundary is a design decision, not a limitation. A governance layer that executes actions becomes a system with every permission every agent has, which is an unusually attractive target and an unusually large blast radius. Keeping authorization separate from execution also means adopting agent governance does not mean rewriting how your agents run.

Excessive agency, as an enforced control

OWASP LLM06, Excessive Agency, describes an AI system holding more functionality, permissions or autonomy than it should. Most responses to it are organizational: scope the agent carefully, review the tools, write it down. Those are worth doing and none of them stop a specific call at a specific moment. Tool allow-lists, scope checks and parameter screening do, and each verdict is evidence that the control was in force when it mattered.

Every action leaves the same evidence

Authorized and denied actions land in the same append-only, hash-chained log as governed outputs, redacted and explainable, mapped to the controls they satisfy. Months later you can show not only which actions were blocked, but that the authorization step ran on the ones that were allowed. For anyone answering an EU AI Act record-keeping or human-oversight question about an autonomous system, that is the difference between an assertion and an answer.

What this release does not do

Turrigan's agentic plane covers the three action checks above, applied per call. Multi-agent oversight, tool supply-chain verification, runtime kill-switches and per-agent behavioural drift are on the roadmap and are not in this release. They are named here rather than left ambiguous, because discovering the boundary of a control during an incident is the worst time to find it.

Frequently asked questions

What is AI agent governance?

Deciding whether an agent may perform an action before it performs it, rather than reviewing what it did afterwards. The agent submits a proposed tool call to an authorization checkpoint that returns allow, block or escalate.

How is it different from prompt-level guardrails?

A prompt-level guardrail instructs the model, and instructions can be argued with. Agent governance evaluates the proposed call itself against a policy you own, outside the model, so a model that has been talked into something still cannot execute it. See guardrails versus governance.

Does Turrigan execute the agent's actions?

No. It authorizes or denies; your orchestrator executes or abandons. Turrigan is a control point, not a runtime.

How much latency does the check add?

The core is deterministic with no LLM in the hot path, so verdicts land in milliseconds rather than seconds. An authorization step that costs a second per tool call would not survive contact with a real agent loop.

Can it run without an external AI service?

Yes. The deterministic core needs no external AI service in the decision path, so agent governance works in self-hosted and air-gapped deployments.

Pilot agent governance on your real traffic