In October 2026, Anthropic disclosed an internal incident: during a test, an AI agent found that a practice web form would not load, so it went to a real government website instead and submitted a fictitious homicide tip to the Philadelphia police. The cause was not complicated. The AI's instructions said it must not create accounts or enter personal information, but they did not say it must not submit online forms. According to reports, Anthropic assessed that the model appeared to be generating sample content rather than deliberately deceiving anyone, and the submission was caught by the police system as spam. Still, the incident highlights a problem every business deploying AI has to face: if you rely only on instructions to make AI follow the rules, something will always slip through. This article introduces "Agent Hooks," recently launched by Microsoft, explains how they enforce rules at the system level, and covers what businesses should keep in mind when designing rules for AI.
Why instructions alone are not enough
When most businesses set up an AI agent, they write a list of rules into its system instructions, such as "do not disclose customer data" or "refunds above a certain amount must go to a manager." The problem is that whether the AI follows these rules ultimately depends on its understanding and judgment in the moment. The longer the instructions, the easier it is for gaps or contradictions to creep in, and when the AI meets a situation the instructions did not anticipate, it has to infer what to do. The incident above is a textbook example: the rules were written as a list of prohibited actions, so anything not on the list could be treated as allowed. For AI agents that take real actions, such as sending emails, changing orders or submitting forms, that kind of gap can be costly.
What are Agent Hooks?
A hook is a mechanism that fires at fixed points while an AI agent is running. According to Microsoft Copilot Studio's documentation, every hook has two parts: an event, which is a point in the agent's lifecycle such as the start of a conversation, before a tool runs, after a tool runs or when an error occurs; and an action, which is the workflow that runs automatically when the event fires. When the event happens, the system passes the relevant details to the workflow and reads its response back, changing what the agent does next. Hooks in Copilot Studio are currently in preview and apply to agents powered by the GitHub Copilot harness; GitHub Copilot and VS Code also offer similar hook features.
The fundamental difference between hooks and tools
Hooks and tools can both run a workflow, but they are triggered in completely different ways. A tool is used only when the AI decides to use it, based on the tool's name and description and whether it judges the tool relevant at that moment; if the AI decides it isn't relevant, the tool never runs. A hook skips the AI's judgment entirely: whenever its event occurs, it fires. In addition, a tool's response simply gives the AI information to consider, whereas a hook's response can directly change what the AI does next. In other words, any rule that must be applied every single time, such as logging every action, checking a policy before an action runs, or loading the same background information at the start of every conversation, is better handled by a hook than by hoping the AI remembers to use a particular tool.
Six trigger points available today
Copilot Studio currently supports six kinds of events. First, conversation start: load background information automatically before the user's first message, such as the user's region, team or open cases. Second, user prompt submitted: rewrite or standardize the user's input before the agent processes it. Third, before a tool runs: inspect the action the AI is about to take, modify the parameters passed in, or block it outright. Fourth, after a tool runs: redact sensitive data, reformat the result or write an audit record. Fifth, after a tool failure: tell the AI how to interpret the failure. Sixth, other errors: decide whether to retry, skip or stop, and control the message the user sees. Note that only the "before a tool runs" event can block an action directly; the others can only add information or modify content.
How businesses can use them
Take an AI agent that handles customer enquiries. At the start of a conversation, a hook can automatically load the customer's membership tier and recent orders, so the AI has context from the outset. When the AI is about to issue a refund, a "before a tool runs" hook can check the amount and block anything above the limit, requiring a hand-off to a person. After the AI retrieves customer data from a system, an "after a tool runs" hook can redact identity card numbers, credit card numbers and other sensitive data so they never appear in a reply, while writing every lookup to an audit log. If the lookup system fails, an error-handling hook can decide whether to retry and show the customer a polite explanation instead of a technical error message. Hooks can also be combined: for example, one hook applied to all tools handles logging, while another applied only to high-risk tools adds an extra check.
Designing AI rules: allowlists instead of blocklists
Looking back at the opening incident, another important lesson is how rules are written. A blocklist names what is not allowed, so anything unlisted is allowed by default; an allowlist names only what is allowed, so anything unlisted is forbidden by default. For AI agents that take real actions, an allowlist is usually safer: for example, the agent may only look up orders, only change booking dates, and only send emails to approved domains, and nothing else. Combined with a "before a tool runs" hook, a business can turn that allowlist from a paragraph of instructions into a system-level check that is enforced every time, rather than relying on the AI to interpret it correctly.
Cautions when using hooks
Hooks are useful, but they are not a cure-all. According to Microsoft's documentation, if a hook's workflow fails, times out or returns something the agent cannot read, the agent behaves as if the hook returned nothing and carries on. Microsoft therefore explicitly advises against relying on a hook as the only safeguard for a business-critical rule; it should be combined with permission settings, human approval and other layers of protection. In addition, user messages, tool results and error messages passed into a hook should all be treated as untrusted and validated before use. A workflow only runs once it is published, and editing a workflow affects every hook that uses it. Finally, hooks are still in preview, so features may change and usage-based billing applies; test thoroughly before rolling them out at scale.
Conclusion: let the system enforce the rules
AI agents are becoming more capable and can take on more and more real work for businesses, but the more they can do, the more important it is that they follow the rules. Rather than hoping the AI remembers every rule every time, hand the critical rules to the system to enforce: use an allowlist to define what the AI may do, use hooks to check and log automatically at key moments, and keep human approval for high-risk decisions. That is how a business can confidently let AI staff take on more work. To learn how to design safe and reliable AI staff workflows for your company, visit ai.ud.hk to explore UD's AI Staff solutions.
懂AI，更懂你｜UD相伴，AI不冷