Sign up for updates
A new server-side control point for Claude Enterprise, and where it fits in a runtime control plane for agents.
Anthropic has added a capability that enterprise security teams have been asking for since agents started touching production systems: an inline control point inside the inference path itself.
Tego supports it now. Here is what the capability is, what it changes, and how it fits alongside the rest of what we do.
What Anthropic shipped
Inference hooks let a Claude Enterprise organization route governed inference requests through an AI security server before inference runs. The server is an HTTPS endpoint that the enterprise or a vendor like us operates. It receives the request, evaluates it, and returns a verdict.
Three properties make this different from what came before.
It runs server-side. The hook executes on Anthropic's infrastructure, not on the client. Nothing gets installed on user devices, nothing can be uninstalled by a user, and there is no local agent whose integrity you have to defend. For anyone who has tried to keep endpoint controls deployed across a developer population, this is the interesting part.
One hook covers the surfaces. claude.ai, Cowork, and Claude Code, across web, desktop, and CLI, from a single org-level configuration. In our own traffic, Slack-originated Claude Tag sessions arrive through the same path, presenting as Claude Code with a claude-in-slack entrypoint.
The request carries the whole session. The transcript arrives untruncated, up to 10 MB, with every prior turn, every tool call, and every tool result. Not just the latest message.
That last property is the one we care most about, and we will come back to why.
Anthropic also shipped it with the instrumentation of a team that expects operators to measure before they enforce: a shadow mode that returns verdicts against live traffic without acting on them, a rollout percentage, and role-based exclusions.

What we built against it
A signed webhook endpoint, HMAC verified, returning a verdict inside the configured timeout. Setup is an endpoint URL, a signing secret, and a failure-handling choice.
For customers already running Tego, the policy you have authored does not change. The hook becomes another place it is evaluated.
How it fits
Tego is a runtime control plane, which means the useful question is never whether a single control point exists. It is what each vantage can see and what it can do about it.
Inference hooks fill the gap in the middle of that table. We had pre-execution interception on the client and we had a complete record after the fact. What we did not have was a uniform, tamper-resistant decision point in the request path that no user can disable.
Being precise about what it does: the verdict is binary, allow or deny, with no rewrite and no redaction. And because the agentic loop returns tool results in the following request, the gate sits after a tool has executed and before the model consumes its output. So it is a gate on continuation rather than on execution.
That is worth more than it first sounds. In a multi-step agentic task the damage is rarely in step one. Stopping a session from proceeding on a poisoned tool result is the highest-value intervention available against injection, which is exactly the failure mode we published on Claude Tag in July. Pre-execution interception on the client remains the complement, not the substitute.
What it unlocks: drift detection at runtime
Now back to the untruncated transcript, because this is where the capability meets what Tego actually does.
Most controls inspect one call at a time. That framing cannot see the incident, because the individual call almost always looks fine. Here is a session we ran, driven by a Slack message rather than a person at a keyboard.
Turn one, a Notion search. A read. Any allowlist waves it through.
Turn two, the agent reaches for a shell:
{
"input": {
"command": "curl -sS -X PATCH https://api.notion.com/v1/pages/3b4f… -d '{\"archived\": true}'",
"description": "Archive the Employees page in Notion",
"tool_name": "Bash",
"type": "tool_use"
}
}The tool is named Bash. Not delete_page, not notion.archive. A policy keyed on tool names does not fire, because the destructive operation lives in the arguments.
Turn three, still the same session:
{
"type": "tool_use",
"tool_name": "tool_search",
"input": {
"query": "Google Drive delete trash remove file folder"
}
}An agent shopping for a deletion capability it does not currently have. Nothing destructive has been called yet. Nothing has been violated. And it is the most informative event in the session.
Individually: a read, a shell command, a search. As a trajectory: reconnaissance, an irreversible action against HR data, and lateral capability discovery, on behalf of an instruction source no human approved.
Because the hook delivers the full session rather than the latest message, we can score the trajectory instead of the call. Tego evaluates five dimensions:
- Identity and privilege. Who or what is driving the session, and what it currently holds.
- Data sensitivity. What the session has touched, cumulatively. HR records and a build cache are not the same target even when the API call is identical.
- Reversibility. A read is free, a write is recoverable, an archive is recoverable for about thirty days, a hard delete is not. This is the dimension most controls ignore, and it is why the Notion call matters more than its innocuous HTTP verb suggests.
- Autonomy. Is there a human in this loop, and at what interval.
- Agent chaining. Who handed this session its instructions, and what does that upstream actor's trajectory look like. Risk is inherited.
Drift is movement in that combined score. Four shapes recur: a tool result that rewrites the agent's objective, privilege that accumulates one reasonable grant at a time, scope that creeps from record to collection to export, and capability shopping like the search above. None is a policy violation at the moment it occurs. Each is a change in trajectory, and the trajectory is now in every request we receive.
Two surfaces, one policy
Video 1. A Slack message drives a session toward deleting a Notion HR database. The agent calls Bash, not anything named delete. Tego denies on the trajectory and the database survives.

Notes from the build
Two things worth knowing before you deploy anything inline, ours or anyone's.
Start in shadow mode. Any new policy has a false-positive class, and the honest way to find yours is to run it against real sessions and read the observed rate rather than reason about it. Shadow mode exists for exactly this and it costs nothing to use.
Understand your failure handling. A webhook failure is not a denial. Organization-level failure handling decides whether traffic blocks or proceeds uninspected, and a non-200 response counts as a failure rather than a deny. Unrecognized event types must return allow. Configure this deliberately, because the default posture of your gateway when it breaks is a security decision.
The schema is also explicitly in motion before GA and still carries deprecated field aliases alongside current names. We track it and will update as it settles.
Availability
Inference hooks support is live in Tego now. If you run Claude Enterprise, it is an endpoint URL and a signing secret away, and it can be running in shadow mode this afternoon.
If you would like to see it against your own traffic, get in touch.
Tego is an Agent Access Control platform: a runtime control plane for AI agents providing visibility, continuous posture management, and session-level authorization across endpoint, cloud, MCP, and browser. Inference hooks are in beta on Anthropic's side.
Related research: Claude Tag Slack integration (July 14, 2026) · Claude Code hidden project link (July 24, 2026)





