Copilot Studio Hooks put hard rules around AI agents - but they fail open

Microsoft has put a feature called Hooks into preview in Copilot Studio. A hook runs one of your workflows automatically at a fixed point in an agent's life: when a session starts, when the user sends a message, before a tool runs, after it runs, when it fails, or when the agent hits an error. Cloud Wars covered the preview on 6 October. Microsoft's documentation for it is dated 29 September.

That sounds like plumbing. It matters more than most model launches this month, because it addresses the question every business asks before letting an agent touch real systems: what stops it doing the thing we told it not to do?

What is actually new

Until now, most low-code agent platforms gave you two places to put a rule. You could write it in the instructions, or you could build it as a tool and hope the agent called it. Both depend on the model deciding to follow the rule. Most of the time it does. "Most of the time" is not a standard you would accept from a payments clerk.

Microsoft's documentation draws the line clearly. A tool runs "only when the agent judges it relevant". A hook runs every time its event fires. The agent does not get a vote.

The event that matters most is **Pre tool use**. Before the agent calls a tool, your workflow receives the tool name and the arguments the agent wants to pass. It can let the call through, rewrite the arguments, or return `deny` with a reason. According to the docs, this is the only event that can block an action. The others can add context, rewrite inputs, or change how errors are handled, but cannot stop the agent.

You can scope a hook to specific tools. So one hook can write an audit record for every call, and a second, stricter one can sit in front of the single tool that issues refunds.

What this means if you run a business

This is the pattern we already build for clients on other stacks. The model decides what to do. Plain code decides whether it is allowed. The two are kept apart on purpose.

Concrete examples of rules that belong in a pre-tool hook rather than a prompt:

• Refunds over a fixed amount go to a person, every time.
• The agent can only email addresses on your own customer list.
• Discounts cannot exceed what the pricing sheet allows.
• Nothing gets written to the CRM outside business hours without a flag.

None of these needs AI judgment. They are if-statements. Putting them in a prompt asks a probabilistic system to enforce a deterministic rule, which is the wrong tool for the job. Hooks give Copilot Studio users a supported place to put them.

The Post tool use hook is useful in a different way. It can redact sensitive values from a tool's result before the model sees it, and it can write a log of what happened. If you have read our view on logging every agent run, this is the hook that makes that easy on Microsoft's platform.

On cost: Microsoft says usage-based billing applies and that building, testing and running these agents can consume Copilot Credits. Every hook is a workflow run. A hook on every tool call in a busy agent will add up. Price it before you switch it on everywhere.

The honest caveat

Read this line in Microsoft's own documentation before you build anything on it: hooks "don't stop the agent when they fail". If the workflow errors, times out, or returns something the agent cannot read, the agent carries on as though the hook returned nothing.

That is fail-open. For a logging hook, fine. For a hook that is meant to block a $5,000 refund, it means a slow or broken workflow quietly removes your safeguard. Microsoft says it directly: don't rely on a hook as your only safeguard for a business-critical rule.

So the hard limits still need to live in the system being called. If the payments API refuses refunds over a threshold without a second approval, it does not matter whether the hook ran. The hook is a useful first check, not the last one.

Other limits worth knowing:

• It is a preview. Behaviour and field names can change.
• It applies to agents built on what Microsoft calls the GitHub Copilot harness in Copilot Studio, not to every agent in your tenant.
• It only helps if you are on Microsoft's stack. If your agents run elsewhere, this changes nothing for you, though the pattern is worth copying.
• Editing a workflow changes every hook that uses it. Shared workflows need change control.

What to do about it

If you already run Copilot Studio agents, list every rule currently written into their instructions. Mark each one as either judgment ("be polite", "summarise clearly") or policy ("never above $500", "only these recipients"). Move the policy ones into a Pre tool use hook. Then ask, for each one, what happens if the hook fails. If the answer is "the money moves anyway", put a second check in the system the agent is calling.

If you are not on Microsoft, run the same exercise anyway. Any rule your agent must never break should not depend on the agent remembering it.