What is an AI security server?

By Nolan Sullivan, Founding Growth Engineer

·Published September 16, 2026·Updated September 18, 2026

An AI security server is the HTTPS service that a model provider calls, with the transcript of a governed request, before inference runs, so the organization can allow or deny that request under its own policy. It runs on the provider’s request path rather than on the user’s device or network, which is why one endpoint governs every user on every covered surface.

The term is Anthropic’s. Inference hooks, a Claude Enterprise feature in beta at the time of writing, hold each governed prompt, POST the conversation to an endpoint the organization names, and proceed only on allow. Anthropic’s documentation calls that endpoint the AI security server, whether the customer runs it or a security vendor runs it on the customer’s behalf. Inference hooks are the only implementation of the pattern we know of from a major model provider, so this page describes the pattern with Anthropic’s version as the worked example, and the details below should be re-checked against Anthropic’s docs before anyone builds on them.

The pattern exists because the controls a security team already operates stop at the edge of the hosted model. Email DLP reads outbound mail, web DLP inspects uploads through the forward proxy, and endpoint DLP watches file copies and clipboard events. A prompt typed into claude.ai crosses none of those in a form they can read; from the network’s point of view it is a TLS session from a sanctioned application to a sanctioned domain. The Cloud Security Alliance put numbers on the resulting gap in its April 2026 research note: in the survey it cites, 71% of 235 large-enterprise CISOs and CIOs said AI already has access to core business systems, and 16% said that access is governed effectively.

An AI security server has five parts. The first three define the protocol, and the last two are what let an organization turn it on without blocking anyone on day one:

1. A signed request. The provider sends an HTTPS POST for each governed inference request. Anthropic signs it per the Standard Webhooks specification with a secret the organization generates once, and can attach up to 16 static custom headers so the server can authenticate the caller.
2. The transcript, as the user sees it. The body carries the conversation up to the point of inference: text, tool calls and their results, text extracted from attachments, and prior turns, plus the actor, the originating application, and the model.
3. A verdict. The server returns HTTP 200 with a small JSON body. {"action": "allow"} lets inference proceed. A deny carries a deny_reason the end user sees and an optional reference_id the organization can join to its own records.
4. A timeout and a failure posture. The provider waits a configured interval for the verdict. If none arrives, the organization’s failure handling setting decides whether the request is blocked or proceeds uninspected.
5. Rollout controls. Shadow mode returns verdicts without blocking anything, a rollout percentage inspects a fraction of requests, and role exclusions exempt chosen groups, so enforcement can start at zero and climb.

How does an AI security server work?

The round trip is synchronous and sits in the user’s critical path. A user submits a prompt on a governed surface. Before inference begins, the provider holds the request and POSTs the transcript to the configured endpoint. The server evaluates it against whatever policy the organization runs, which might be a regex for API keys, a PII classifier, a model allowlist, a working-hours rule, or an LLM judge, and answers. On allow, inference proceeds. On deny, the request is rejected before the model sees it, and the user reads a blocked-by-policy message assembled from the server’s deny_reason followed by a standing message the administrator configured, such as who to contact for an exception.

{
  "action": "deny",
  "deny_reason": "This prompt appears to contain customer payment card data, which your organization's policy does not allow.",
  "reference_id": "scan_01HXPT4R9V"
}

Availability engineering is most of the operational work. On Claude Enterprise the verdict timeout is configurable from 1 to 10,000ms with a 5,000ms default, and the budget covers the whole exchange, including connection and TLS handshake. A slow verdict counts as an unreachable server. Anthropic retries once, after 100ms, and only when the connection attempt itself failed; once the server has responded, the exchange is never retried. Sustained failures trip a circuit breaker: Anthropic stops contacting the server and applies the failure posture to every request, then checks in the background, starting ten minutes after the trip, for a valid verdict before resuming. A non-200 status, a redirect, or an unparseable body is a webhook failure rather than a deny, so a server cannot signal “block this” with an error code.

Because the check runs on the provider’s infrastructure, there is nothing to install on user devices, no proxy to insert in front of claude.ai, and no client version to keep current. One administrator setting applies to every user on every governed surface the same day. That is the property that makes the pattern attractive to security teams, and it is also the source of every limit described below, because the server sees exactly what the provider chooses to send and nothing else.

Why not point the hook at the DLP scanner you already run?

For many organizations that is the right first move, and Anthropic says DLP forwarding is the most common deployment it sees. The scanner already knows the organization’s data classes. Its regexes for card numbers, national identifiers, and API-key formats work as well on a chat transcript as on an email body. The security team already trusts its verdicts and already has a workflow for its findings. If the whole policy is “no regulated data enters a hosted model,” a DLP engine behind an HTTPS endpoint answers that question in an afternoon of integration work, and a fifty-line always-allow server that archives every transcript is a legitimate deployment on its own, as a push-based alternative to polling the Compliance API.

The scanner starts to strain when the policy needs more than a data class. An engine built for mail returns a verdict per message with no memory of the conversation, so it cannot distinguish a user pasting a customer record into a fresh chat from a tool result that returned one three turns ago. It has no concept of which connector produced a tool result, so it cannot say that a payload from the Salesforce tool is fine while the same payload from an unknown MCP server is not. Its findings land in a DLP console, separate from the transcript that produced them, which means an investigator joins two systems to reconstruct one event. And the transcript arrives untruncated, so a scanner behind a proxy with a 1 MB body limit will reject long conversations, and under fail-open handling those rejected prompts reach the model uninspected.

The scanner is still worth deploying. The useful exercise is naming which question each endpoint can answer. A DLP engine answers “did a forbidden data class appear.” A purpose-built server, or an AI Control Plane acting as the endpoint, answers “given who this user is, what tool produced this content, and what the rest of the conversation says, should this request proceed,” and it can apply the same policy engine to the tool and MCP traffic the hook never sees. Agent DLP is the broader control both are enforcing.

AI security server vs classic DLP vs AI agent hooks: what’s the difference?

Three controls that all claim to govern AI usage sit in three different places, and the place determines what each can see.

Classic DLP inspects channels the organization controls; an AI security server inspects a request the provider controls. The first sees a prompt as encrypted traffic to an approved domain. The second receives it decoded, from the party that was about to act on it. When an organization forwards the hook to its DLP engine, the engine’s detection logic is reused, but the vantage point is new.

AI agent hooks are the closer comparison, because the vocabulary overlaps and both fire on prompts. A hook is a handler that runs inside the agent, on the machine that hosts it, at lifecycle events such as UserPromptSubmit, PreToolUse, and PostToolUse. Claude Code, Cursor, Codex, and VS Code Copilot all expose them. A hook sees a shell command before it executes and can block it; it governs the one agent it was configured for; and it has to be present on every machine, because an agent launched without the configuration is ungoverned. An AI security server trades depth for breadth. It sees inference requests rather than tool invocations, so it cannot stop rm -rf before it runs, but it covers every user in the organization from a single admin setting, on surfaces such as claude.ai where no client-side hook exists.

The two compose. Hooks govern coding agents on developer machines, where the consequential actions are local. The server governs the chat and web surfaces that make up most of a non-engineering workforce’s Claude usage. Anthropic’s Compliance API is the after-the-fact complement to both; it retrieves what happened, and an AI security server decides whether it happens.

What are Anthropic Inference hooks?

Inference hooks are the Claude Enterprise feature that calls an AI security server. Anthropic labels the feature beta and warns that field names, request shapes, and headers may change, so everything in this section is a snapshot of the docs at the time of writing rather than a contract.

• One hook, many surfaces. A single organization-level endpoint governs conversations across claude.ai, Cowork, and Claude Code, whether they run on the web, in the desktop or mobile apps, or in the CLI.
• Prompt side only. The only event is prompt, which fires once per governed inference request. Anthropic describes response-side enforcement as a planned later event.
• Allow or deny. Verdicts cannot rewrite or redact. A prompt carrying a secret is blocked whole or passed whole.
• Owner-level permission. Configuration requires organization:manage, held only by the Owner and Primary owner roles. The Admin role is not sufficient.
• Three enforcement states. Off, shadow, and enforcing. Allowing the feature for the organization always forces enforcement off first, so turning it on never starts inspection by itself.
• Rollout controls. A rollout percentage from 0 to 100, rolled once per conversation turn; exclusions for custom roles the organization created (built-in roles cannot be excluded, and machine-credential traffic is always inspected); and a custom blocked-prompt message of up to 500 characters.
• Out of scope. Amazon Bedrock, Google Cloud, Platform organizations using the Claude API, and voice mode are not covered. Ancillary requests such as title generation are never sent.

The endpoint requirements are firm. The URL must be https:// on port 443, on a publicly routable host, with a certificate that validates against the public CA store, reachable without redirects. Reverse-tunnel services such as ngrok are blocked by Anthropic’s network policy, so testing happens on a domain the organization controls. Verdicts must return as HTTP 200. Requests originate from a published Anthropic egress range, which can be allowlisted, though Anthropic notes that allowlisting does not replace signature verification.

Anthropic’s Configure Inference hooks and Develop an Inference hooks integration pages carry the request and verdict schemas, the signature procedure, and the operational semantics, and they are the source to trust over this page when the two disagree.

What does an AI security server not see?

The server’s view is bounded by what the provider sends, and the gaps shape the policy more than the contents do. On Claude Enterprise today:

• Tool calls before they run. The transcript carries tool_use blocks and their results, so the server reads them, but the hook gates inference requests rather than tool invocations. A destructive connector call is visible in the turn that reports its result, after it has already executed. The server can deny the next inference on the strength of that result; it cannot prevent the call.
• Tool definitions and system prompts. Neither is ever included. A poisoned tool description that steers the model is invisible to this control, which is one reason tool-path governance stays a separate problem.
• Attachments as bytes. Attachments arrive as metadata and extracted text. Raw file and image bytes are never sent, so image-only content, such as a screenshot of a spreadsheet, is not inspected.
• Claude’s hidden reasoning and Anthropic-internal context. Only the conversation as the user sees it is sent.
• Sampled-out and excluded traffic. A request outside the rollout percentage or from a member of an excluded role is never sent, so the server can neither evaluate nor record it. Under fail-closed handling, sampled-out requests still proceed.
• Everything off the governed surfaces. Another provider’s model, a personal Claude account, a Bedrock deployment, or a local agent calling an MCP server directly all sit outside this path. That is the shadow AI problem, and an AI security server does not solve it.

These are Anthropic’s stated limits at the time of writing, and the beta is still moving. Check the Inference hooks overview before treating any of them as permanent.

What are the trade-offs?

An AI security server adds its round trip to the latency of every governed request in the organization. A 200ms verdict on a 3-second generation is invisible; a 4-second verdict on a one-line question is not. Anthropic advises load-testing the server before a large rollout, and a server that calls an LLM judge for every prompt should expect to spend most of its timeout budget doing so.

Fail-closed enforcement couples Claude’s availability to the server’s uptime. If the endpoint is down and failure handling is set to block, every governed user in the organization is blocked until the circuit breaker resets or an administrator intervenes. Fail-open removes that coupling and reintroduces the gap the server was meant to close, since every request during an outage reaches the model uninspected. There is no setting that avoids both costs; the choice is which failure the organization prefers.

The protocol is one vendor’s beta. Anthropic reserves the right to change field names and request shapes, the verdict vocabulary is two words, and no other major provider has shipped an equivalent. An organization that builds policy logic against this contract should expect to revise it, and should not assume the same server will govern a second provider’s traffic without a second integration. Allow-or-deny also means a blocked prompt is blocked whole, so a user who pasted one card number into a long, otherwise legitimate request loses the whole request and has to try again.

Do I need an AI security server?

You need one if three things are true at once: your organization runs Claude Enterprise, it has a written policy about what may enter a hosted model, and no control you operate today can enforce that policy on claude.ai, Cowork, or Claude Code on the web. The third is true by default on the web surfaces, because the existing DLP stack cannot read the traffic and there is no client to install a hook into, so the decision usually turns on whether the second exists in writing.

You do not need one if audit is the requirement rather than enforcement. The Compliance API retrieves transcripts and activity after the fact, and a records-retention or investigations workflow is well served by it. You also do not need one for coding agents on managed developer machines if agent hooks are already deployed there, though the server still covers the surfaces hooks cannot reach.

If the answer is yes, the decision that follows is which endpoint. Choose the DLP engine you already run if the policy is a set of data classes and the findings workflow already exists. Choose a purpose-built server or an AI Control Plane if the policy depends on conversation context, tool provenance, or user identity, if findings should sit on the transcript that produced them, or if the same policy engine has to govern the MCP and tool path as well.

A note on Speakeasy

The Speakeasy AI Control Plane can be configured as the AI security server for a Claude Enterprise organization. The Anthropic inference hooks docs and the Claude security use case walk through the setup; in outline, Speakeasy generates an organization-specific HTTPS endpoint, an Owner pastes it into Claude’s Inference hooks settings, and the signing secret Claude reveals once is saved back into Speakeasy.

Each governed prompt is evaluated against the project’s risk policies, using the same detection rules and classifiers that cover the organization’s other agent traffic, and a denied request never reaches the model. Every turn lands in Agent Sessions with the verdict attached and the person behind the prompt resolved through the identity provider, so an investigator reads one record rather than joining a findings log to a chat export. Tool calls, connectors, and MCP servers are governed separately through the MCP gateway, which terminates each call with the caller’s identity attached and can block or redact before forwarding. That is the surface Inference hooks do not gate, and it is where the destructive actions live.

Two limits apply. Speakeasy is one of several possible endpoints, and a DLP engine the organization already trusts is a reasonable alternative for a data-class-only policy. The inference hook is also the broadest control Speakeasy offers for Claude rather than the deepest; for Claude Code and Cowork, the logging and telemetry integration and managed Anthropic plugins add tool-level visibility and hooks that see a tool call before it runs. The recommended rollout mirrors Anthropic’s own safeguards: shadow mode at 100% inspection, tune policies against live verdicts, then switch failure handling to block.

If you want to see what your Claude Enterprise traffic would have produced under these policies last week, talk to us.