# Your AI policy just became enforceable

- Link: https://xanadu.co/your-ai-policy-just-became-enforceable/
- Published: 2026-08-17T17:21:57+04:00
- Author: Daragh McGrath

Every enterprise I work with has an AI policy. Almost none of them can enforce it.

The policy exists. Someone wrote it, legal reviewed it, it went into the induction
pack. It says the sensible things: don’t paste customer data into public tools, 
don’t use AI output without review, be careful with anything regulated. Then it 
sits there, and enforcement becomes a matter of trust and training.

Ask a CIO what actually happens if someone pastes a client file into a chat window
this afternoon. The honest answer is usually nothing. Not nothing as in it’s permitted.
Nothing as in no system in the building would notice.

That gap between what the policy says and what the infrastructure can enforce is
where most AI risk in the enterprise actually lives. It has been the hardest part
of this to solve, because the enforcement point has never existed. Until now it 
has been laptops, browser extensions and hope.

## What changed

Anthropic has added a capability to Claude Enterprise called Inference hooks, currently
in beta.

The mechanism is simple. When someone in your organisation submits a prompt, Anthropic
sends the conversation transcript to a security server that you operate, over HTTPS,
and waits for a verdict. Your server evaluates the content and answers allow or 
deny. On allow, inference proceeds as normal. On deny, the request is rejected before
it ever reaches the model, the user sees a message explaining why, and the denial
is written to your organisation’s activity feed.

Your policy stops being a document people agree to and becomes code that runs before
the model does.

## The placement is the point

The detail that matters most is where this runs. Not on user devices. Not as an 
extension somebody can disable, or a proxy that only covers the corporate network,
or an agent that stops working the moment someone opens their laptop at home.

It runs on Anthropic’s side, after the request leaves the client and before the 
model sees it. There is nothing to install and nothing to deploy. Which means it
applies to every governed request in the organisation, uniformly, whether the person
is working in the browser, the desktop app or the command line, and whether they
are in a chat, in Cowork, or in Claude Code.

Anyone who has tried to roll out data loss prevention across a real workforce will
understand why that matters. Coverage has always been the problem. Controls that
depend on endpoint installation are only as good as your worst-managed device, and
there is always a worst-managed device.

## What your server actually sees

It receives what the user sees: transcript text, tool calls and their results, and
text extracted from attachments. It does not receive raw file or image bytes, system
prompts, or Anthropic’s internal context. Requests are signed to the Standard Webhooks
specification, so you can verify they came from Anthropic and not from someone who
found your endpoint.

The default verdict timeout is five seconds, which is a real engineering constraint
rather than a footnote. Whatever you build has to reach a decision inside that window
on every prompt your organisation sends.

## The decision nobody talks about

If your security server is unreachable, errors, or fails to answer in time, you 
choose what happens. Block the request, or let it proceed without inspection.

Fail closed and an outage in your own infrastructure stops your organisation using
Claude. Fail open and your enforcement quietly disappears at exactly the moment 
something is wrong, which is usually the moment you would most want it.

There is no correct answer. There is only the answer your regulator, your risk appetite
and your uptime requirements can live with, and it needs to be a decision somebody
made deliberately rather than a default nobody looked at. In regulated environments
I would expect that conversation to take longer than the implementation.

## What it does not do yet

This is beta, and worth reading honestly.

It cannot see inside images. Attachments arrive as metadata and extracted text, 
so a screenshot of a contract is not inspected. Anyone who wants to route around
it will work that out quickly, which means this reduces accidental exposure far 
more than it prevents deliberate exfiltration. Those are different problems and 
it is worth being clear which one you have solved.

Verdicts are allow or deny. There is no redaction, no rewriting a prompt to strip
the sensitive part and letting the rest through. A prompt with one account number
in it is blocked entirely.

It covers the prompt, not the response. Response-side enforcement is described as
planned, which means model output is not yet inspected on the way back.

Voice mode is not covered. Neither are Platform organisations using API access directly.

And it is not available on Amazon Bedrock or Google Cloud. That one deserves attention
in this region, because buying frontier models through a hyperscaler is a common
route to satisfying residency requirements. If that is how you have solved data 
residency, this control is not currently available to you, and those two requirements
are in tension until that changes.

## Where this sits in the stack

We publish a standard for how AI content operations should be governed inside an
enterprise, built around five control points. Inference hooks land squarely on two
of them.

Access and permissions moves from a question of who has licences to a question of
which requests are permitted, evaluated individually. That is a meaningful upgrade.
A licence tells you who could do something. A verdict tells you what was actually
allowed.

Audit and telemetry gets a second mechanism. Until now the honest answer for most
organisations was retrospective: pull the logs, reconstruct what happened, hope 
the questions came late enough that the data was still there. Inference hooks give
you a record at the point of use, and the ability to stop something rather than 
document it afterwards. Anthropic’s own framing distinguishes the two clearly: hooks
act inline before inference, the Compliance API answers questions after the fact.
Most organisations need both, for different reasons.

## What I would do about it

If you are running Claude Enterprise and you are in financial services, healthcare,
government or anything with a regulator, this is worth a conversation this quarter
rather than next year. Not because it is finished, but because the shadow mode path
means you can observe verdicts on live traffic without blocking anything, and find
out what your organisation is actually sending before you decide what to stop.

That is the part I would do first. Most organisations discover their real exposure
is nothing like the one described in their policy, and it is a great deal cheaper
to learn that in observation mode than in an incident report.

The broader shift is the one to pay attention to. For three years AI governance 
in the enterprise has meant writing rules and hoping. It is starting to mean enforcing
them. The organisations that move first will be the ones who already know what they
want to enforce, which is a strategy question rather than a technical one, and it
is worth having the answer before the capability lands rather than after.

---

_Reference: [Anthropic’s Inference hooks documentation](https://platform.claude.com/docs/en/manage-claude/inference-hooks).
Our full standard for governing AI content operations is at [xanadu.co/ai-content-supply-chain](https://xanadu.co/ai-content-supply-chain/)._