BlogIndustry News

AI Guardrails That Always Run: Microsoft Adds Hooks to Agents

Copilot Studio hooks move AI guardrails out of the prompt and into checks that fire on every tool call. Here's what they do, where they fail open, and how to layer them.

MagicMakers Lab07 Oct 20267 min read

Microsoft shipped a preview feature in Copilot Studio this week that sounds small and isn't: hooks. A hook runs a workflow every time a specific event happens during an agent's run, like a session starting, a tool being called or an error firing. The agent doesn't get a vote. As Microsoft's announcement puts it, a workflow defines the logic, and a hook decides when that logic runs.

That's the piece missing from most AI guardrails we see in the wild. Teams write "never refund more than $500" into a system prompt and hope the model remembers. Hooks move that rule out of the prompt and into code that fires every single time. If your agents touch money, customer data or production systems, this pattern matters far more than which vendor ships it.

TL;DR#

Copilot Studio hooks (preview) run a workflow on fixed agent events, and the "pre tool use" hook can block or rewrite a tool call before it executes.
Hooks are deterministic, but they fail open: if the workflow errors or times out, the agent carries on as if nothing happened.
Treat hooks as one layer. Put hard limits where the action actually executes, and route high-stakes calls to a person.

What Microsoft actually shipped#

According to the Copilot Studio documentation, hooks attach to six events in an agent's lifecycle. Each passes the workflow some context and reads a response back.

Event	When it fires	What the hook can do
Start (pre-loop)	Before the first user message	Add context
User prompt submitted	Before the agent processes a message	Replace the prompt
Pre tool use	Before a tool call	Block, change arguments, add context
Post tool use	After a tool succeeds	Change the result, add context
After tool failure	After a tool errors	Add guidance
Error	On errors outside tool calls	Retry, skip or abort

Only "pre tool use" can stop an action. It returns permissionDecision: deny plus a reason the agent can read. Hooks are configured from the agent's command bar, and they currently apply to agents running on the GitHub Copilot harness.

Cloud Wars' write-up lists the intended uses: pulling open support cases at session start, blocking a tool call that breaks a business rule, redacting sensitive data from a tool result, writing an audit record, and deciding what to do when a tool fails.

Why a prompt isn't a guardrail#

Here's the core distinction. An agent chooses whether to call a tool. A hook fires whether the agent likes it or not.

A system prompt is a strong suggestion. Most of the time the model follows it. But "most of the time" is a bad property for a refund limit or a data deletion rule. Long conversations, ambiguous requests and text injected through tool results can all push a model off script, and you won't know until it's happened.

Microsoft isn't alone. Anthropic's Claude Code has had a similar system for a while: its hooks reference describes PreToolUse, PostToolUse, SessionStart and other events, where a script can deny a tool call before it runs. When two major agent platforms land on the same design, that's a signal. The shape is settling: a probabilistic model in the middle, wrapped in a deterministic layer that enforces the rules you can't afford to have skipped.

If a rule matters, it shouldn't live only in the prompt.

The trade-offs nobody puts on the slide#

Hooks are a real step forward, with sharp edges worth knowing about.

They fail open#

Microsoft's docs are blunt: if the hook's workflow fails, times out or returns something unreadable, the agent continues as though the hook returned nothing. Claude Code behaves similarly, where a hook that times out doesn't block the tool call. So a hook is a checkpoint, not a locked door. Microsoft itself says not to use one as your only safeguard for a business-critical rule.

The inputs aren't trustworthy#

Prompts, tool results and error messages can contain text the agent didn't write. A hook that reads a tool result and acts on it needs to validate that content, not trust it.

Shared workflows cut both ways#

A hook stores a reference to a workflow, not a copy. Fix a bug once and every agent gets the fix. Ship a bug once and every agent gets that too.

What AI guardrails with hooks mean for your business#

On Microsoft 365 with Copilot Studio agents, you can try this now. On other stacks, you can build the same pattern in any agent framework that exposes a tool-call step.

Here's how we'd think about where each rule should live:

Where the rule lives	Runs every time?	If it breaks	Good for
System prompt	No, the model decides	Silently ignored	Tone, style, defaults
Pre-tool hook	Yes, on the event	Fails open	Policy checks, routing to a human
Post-tool hook	Yes, on the event	Fails open	Redaction, logging, formatting
Check inside the API or database	Yes	Fails closed, if built that way	Money limits, deletes, compliance

A support agent issuing refunds is the classic case. The refund API should reject anything over your limit, full stop. A pre-tool hook should catch the same thing earlier and return a clear reason, so the agent can tell the customer a manager will approve it instead of failing with a cryptic error. That's human in the loop AI done properly: the person sees only the decisions that need them, not every routine action.

A checklist for layering AI guardrails#

The flow we aim for on any agent that writes data:

agent plans tool call: refund $740
        |
PRE-TOOL HOOK  -> rule: refunds over $500 need approval
        |-- deny + reason -> request manager approval
        |-- allow -------> refund API (re-checks the limit)
                                |
                    POST-TOOL HOOK -> redact, write audit log

The steps:

List every tool your agent can call and mark each one read or write.
For each write tool, write the business rule in one plain sentence.
Enforce hard limits inside the system that executes the action, so they fail closed.
Mirror those rules in a pre-tool hook that returns a readable reason.
Send high-stakes or unusual actions to a human approval step.
Use post-tool hooks to redact sensitive fields and log every call.
Decide your error policy up front: how many retries, and when to stop.
Alert when a hook fails, since a silent hook failure means no check ran.
Test with hostile inputs, such as tool results that contain instructions.

How MagicMakers Lab approaches this#

Our agentic development work starts from the same principle: give agents scoped tools, put approval gates in front of anything that moves money or data, and log every decision so you can see why the agent did what it did. For Framico, an e-commerce business, that approach means 200+ orders a day ship with zero manual steps. Automation at that volume depends on rules enforced by the system, not hoped for in a prompt. Hooks are a useful addition to that toolbox, not a replacement for it.

Key takeaways#

Copilot Studio hooks bring deterministic checks to agent runs, and only the pre-tool hook can block an action.
A rule written only in a prompt can be skipped. A hook can't be skipped, but it can fail open.
Hard limits belong where the action executes, so failure means "no" rather than "yes".
Use hooks for policy checks, redaction, audit logs and routing to a human approver.
Monitor your hooks. A guardrail that silently stopped running is worse than one you know is missing.

FAQ#

What are AI guardrails?#

AI guardrails are the checks that keep an AI system inside the boundaries you set. For agents, that means rules on which tools they can call, with what arguments, and when a person must approve. Good guardrails sit outside the model, in code and in the systems the agent touches, so they hold even when the model gets confused or manipulated.

What is a hook in an AI agent?#

A hook is a piece of logic that runs automatically at a fixed point in an agent's run, such as before a tool call or after an error. Unlike a tool, the agent can't choose to skip it. Hooks are used to block risky actions, edit tool inputs or outputs, add context and write audit logs.

Do you still need human in the loop AI if you use hooks?#

Yes, for high-stakes actions. Hooks decide automatically, based on rules you wrote in advance. Some decisions, like large refunds, contract changes or deleting records, need judgment that's hard to encode. The best setup uses hooks to spot those cases and route them to a person, while routine actions run without waiting for anyone.

Are Copilot Studio hooks generally available?#

Not yet. As of October 2026, hooks are in preview and apply to agents powered by the GitHub Copilot harness. The documentation is marked prerelease, doesn't publish timeouts or limits, and notes that building and testing with hooks can consume Copilot Credits. Pilot it, but don't rest production rules on it alone.

If you're running AI agents (or planning to) and you're not sure which of your rules are enforced and which are just hoped for, that's a quick thing to find out. We'll map your agent's tools, flag the gaps and tell you honestly what's worth fixing first. Book a free audit.