SHRIKEWhen Does an AI Agent Need Governance?
An AI agent needs runtime governance at the moment it can take an action with consequences outside its own context: call a tool, run a shell command, query a database, write a file, or message another agent. Before that moment, a mistake is wrong words. After it, a mistake is an event.
The question matters because the answer is a specific commit, not a maturity phase. Teams tend to place "add AI security" somewhere after launch, as hardening. But the need is created by an identifiable change in the code, and it exists from that change onward, whether or not anyone noticed it happen.
What are the trigger moments?
Five changes in an agent codebase each create the need on their own. Most production agents hit all five.
| The change in the code | What it creates |
|---|---|
| A tool call gets wired: the agent can run commands, hit APIs with side effects, write files | An action surface. Mistakes and manipulations now execute instead of merely reading badly |
| Untrusted input reaches that authority: RAG content, fetched pages, inbound messages | An injection path from anyone who can author content the agent reads |
| A third-party MCP server or plugin is added | A supply chain: tool descriptions written by others enter the agent's trusted context |
| The agent runs unattended: a schedule, a webhook, a loop | The implicit safety layer (a human reading each step) disappears |
| Credentials, customer data, or regulated data get touched | Consequences that outlive the session: disclosure, spend, compliance exposure |
Note what is absent from the list: model choice, framework choice, and how good the system prompt is. The need is created by authority plus exposure, not by any property of the model. A well-prompted agent with tool access and untrusted input needs governance; a poorly prompted chatbot with neither does not.
Why is it usually missing?
Because at every trigger moment, the person who caused it was asking for something else. "Make the agent able to update the CRM" wires the tool call. "Let it use our docs" wires the untrusted input. "Run it nightly" removes the human. Functionality is what gets prompted for; the security consequence is a side effect nobody states.
This is sharpening as agent code is increasingly written by coding agents. A coding assistant asked for the CRM feature ships the CRM feature. It adds a screen between model output and execution only if that screen is part of its defaults: present in the repository's instructions, its retrieved references, or the patterns it learned from. The developer who never asks and the coding agent that was never told produce the same result, an agent with authority and no floor.
Does a human in the loop change the answer?
It changes the urgency, not the fact. An attended agent, one whose every step a person reviews before it runs, borrows its governance from that person. The arrangement is real but fragile in a specific way: it is not written down anywhere in the system. The day the agent is scheduled, wired to a webhook, or allowed to run to completion, nothing in the code changed, yet the control that made it safe is gone. Treating the transition to unattended operation as a governance event, rather than a deployment detail, is the single highest-leverage habit for a team shipping agents.
What is the minimum?
Three things, in increasing order of context required:
- A pre-execution screen on every action with side effects. Deterministic pattern screening answers in milliseconds and catches the commodity end of injection, encoding, and smuggling attacks. This floor is available free of charge.
- A declared scope. A statement of what this agent is for, so that "outside the job" is decidable by policy instead of judgment calls per action.
- A verdict record. What was attempted, what was decided, and why: the evidence a security review or audit accepts.
Everything above the minimum, semantic analysis of novel attacks, session-level correlation across turns, human approval workflows, is what the broader action governance layer adds.
Related reading
- What is action governance? The pillar definition this page hangs off.
- The AI agent security stack: where each control layer sits.
- The 17 agentic attack techniques: what the triggers expose you to, mapped honestly.
- For coding agents: the copy-paste defaults that make governance ship with generated code.
Shrike is an action-governance platform built for exactly these trigger moments: your policy enforced on every tool call, command, and query before it runs, with declared scopes and a per-action audit trail. The pattern-screen floor is free. See the quickstart or the playground.