An Agent Produces Effects, Not Tickets

For most of the last few years, AI at work produced words. A model drafted the email, summarized the contract, suggested the fix, and a person decided what happened next. The output was, in effect, a ticket: a proposal waiting for someone with authority to act on it.

Agents change that. An agent writes the record, runs the command, sends the payment, opens the pull request, and hands part of the job to another agent. Its output is no longer a proposal. An agent produces effects, not tickets. And an effect, unlike a ticket, has already happened by the time anyone reads about it.

That one shift moves AI from a productivity question to an accountability question, and it lands on every leader who will be asked to sign off on an agent in production.

The three questions every action now carries

When a person takes a consequential action inside a company, three answers exist, even if nobody writes them down: who authorized it, which rule allowed it, and where the record is. Agents inherit the action without inheriting those answers. So each one has to be supplied on purpose:

• Who authorized it? Not which credential the agent held, but which person or team decided this agent may do this kind of thing at all.
• Under which policy? The specific rule, written down by your organization, that the action was checked against before it ran.
• Where is the record? A durable account of what was attempted, the decision, and who approved anything that needed approving, that an auditor or a customer can read later.

If a team cannot answer all three for an agent, that agent tends to stall in security review, and it should. The answer is not to slow the agent down. It is to make the three answers a property of the platform the agent runs on.

Five principles, in order

We find it useful to lay the work out as a chain, because each link depends on the one before it:

1. Authority. Your organization declares what each agent is for: its purpose, the tools it may use, and when its permission expires. The declaration comes from you or your agent framework, never from the agent's own reasoning.
2. Policy. Your rules, written once, apply to every agent and every model. A rule that lives inside one vendor's settings stops at that vendor.
3. Enforcement. Every action is checked against your policy before it runs, at a point the agent cannot reason its way around. The answer is one of four: allow, warn, hold for a person, or block.
4. Evidence. Every decision is recorded as it happens, including the allows, so the record shows the control operating rather than only the times it fired.
5. Accountability. A named person approves what your policy says needs approving, and the record shows who it was. The agent never approves its own request.

Skip a link and the chain fails quietly. Policy without enforcement is a document. Enforcement without evidence is a claim. Evidence without a declared authority records decisions nobody can say were right.

What a team should not have to carry

Without a governance layer, each of those links becomes somebody's job, in every agent project, rebuilt each time. The work is predictable enough to list:

• Re-implementing the policy in every agent and for every model. Instead, the policy is declared once and Shrike advocates for it on every AI interaction, whichever model the agent runs on, hosted or local.
• Trusting the agent to follow its instructions. Instead, each action is checked against your policy before it executes, outside the agent's reach.
• Building an approval step per workflow. Instead, the actions your policy marks as consequential wait for a person, with the context needed to decide.
• Reconstructing what happened from scattered logs. Instead, every decision is recorded as it is made, ready to export.
• Judging each step in isolation. Instead, the whole session is read, so a sequence of individually harmless steps that adds up to something your policy forbids is still caught.

None of this asks a team to trust Shrike's judgment over its own. You declare the policy; Shrike enforces it. The authority stays with your organization.

What it looks like for risk and compliance

For a risk or GRC team, the useful property is that evidence is a by-product of enforcement rather than a separate project. The decision record, the approver on each held action, and an exportable evidence pack exist because the actions were governed, mapped to the frameworks your auditors already use: SOC 2, ISO 27001, HIPAA, GDPR, PCI DSS, NIST AI RMF, the EU AI Act, and the OWASP LLM Top 10 (2026). Those are control mappings, not certifications; your assessor still makes that call. We go deeper on what an assessor asks for in how to prove AI-agent governance to an auditor.

Where to start

Start with one agent, in observe mode. Shrike checks every action against your policy and records what it would have refused, while blocking nothing. When the record shows the policy is right, enforce that agent, then the next. The scope declaration guide covers the first step, and the Trust Center covers the mappings.

Agents act. Your policy should answer for every action before it happens, not after.