Claude Enterprise Security: Anthropic''s Controls and the Authorization Layer You Own
Anthropic gives enterprise Claude buyers a real control set: SSO and SCIM provisioning, a default of not training on your data, configurable retention, and an audit log surface. Those controls govern the account and the vendor relationship. They stop at whether a specific authenticated user or agent is permitted to send a specific prompt to Claude. This piece walks the controls Claude Enterprise and the Anthropic API provide, marks where they stop, and gives the identity-aware authorization pattern that closes the post-authentication gap on Claude traffic, with request-level detail for engineers.
A Claude API request is an HTTPS POST to https://api.anthropic.com/v1/messages, authenticated with an x-api-key header and an anthropic-version header. Whether your team reaches Claude through that API or through the Claude Enterprise application, Anthropic's security controls govern the account, the data-handling terms, and the sign-in path. What they do not evaluate is whether the authenticated person or agent behind the key is permitted to put this particular prompt in front of the model. I want to walk what Anthropic secures, mark where it stops, and show the authorization pattern for the part that stays with you.
What Claude Enterprise and the Anthropic API secure
The enterprise control set is real, and turning it on is the baseline.
Identity and provisioning. Claude Enterprise supports single sign-on through SAML and user lifecycle management through SCIM, so accounts are created and de-provisioned from your identity provider rather than by hand. Role-based roles separate owners, admins, and members.
Data handling. Anthropic's default for commercial API and enterprise traffic is not to train its models on your inputs and outputs. Retention is configurable, and enterprise agreements can tighten it, which matters when prompts carry regulated data.
API key and workspace scoping. The Anthropic Console lets you segment usage into workspaces, issue scoped API keys per workspace, and set spend limits, so a compromised key has a bounded reach.
Audit surface. Enterprise plans expose administrative activity and usage records that feed your reporting, giving an account-level view of who did what in the application.
Where those controls stop
Each control has an edge. SSO and SCIM authenticate the user and manage the account, and neither reads the content of a request. The no-training default protects how Anthropic handles your data on its side and says nothing about which of your employees is permitted to send that data in the first place. Workspace-scoped keys bound blast radius by workspace, not by the individual end user delegating a task to an agent that holds the key. The audit surface records account and usage activity, written from Anthropic's vantage point, so it lacks your policy state at the moment a specific prompt was sent.
The post-authentication gap on Claude traffic
The gap opens after sign-in. SSO confirms the user is who they claim. It does not answer whether this user, in this role, may send this prompt, carrying this data classification, to Claude right now. A provisioned employee with a valid session can paste a privileged legal memo into a message request, and every Anthropic control passes it: the SAML assertion is valid, the workspace key is authorized, the data is not used for training, and the usage record logs the call. This is the post-authentication gap, an authorization problem at the request layer that vendor account controls do not reach. It widens with agents, because a Claude-powered agent acting on a workspace key records the service identity rather than the person who delegated the task.
Identity-aware authorization on Anthropic API calls
Closing the gap means evaluating the request on the path to Claude, against the caller's identity and the data in the prompt. That is a policy decision point in front of api.anthropic.com. A raw call looks like this:
An identity-aware enforcement layer intercepts the request, resolves the caller identity, classifies the prompt, evaluates policy, and either forwards the call or returns a decision before Claude is reached:
The check is deterministic and fail-closed, and it commits that record independently of the calling application before any response returns.
Compliance framing
For regulated Claude workloads, the vendor usage log is not the audit record a regulator expects. EU AI Act Article 12 requires automatic, traceable event logging for high-risk systems, including inputs and the natural persons involved, applying from August 2, 2026 per the European Commission. An account-level log written from the vendor's vantage point sits in a weaker position than an identity-bound record produced independently of the application under review, which is the self-attestation problem applied to AI logs.
DeepInspect
This is exactly what DeepInspect does. DeepInspect is a stateless proxy that sits inline in front of the Anthropic API, and because it is model-agnostic, the same layer governs Claude alongside OpenAI, Bedrock, Vertex, Azure OpenAI, and self-hosted models. For every request it evaluates the caller's identity, role, the data classification in the prompt, and organizational policy, then returns a pass or block decision before the traffic reaches Claude. Enforcement adds under 50 milliseconds in internal testing, invisible against the model's response time, and defaults to deny on ambiguity.
For every decision it commits an identity-bound audit record before the response returns, written independently of the calling application. That record carries the identity, policy, data classification, and outcome that Anthropic's usage logs never held. DeepInspect does not replace Anthropic's SSO, SCIM, or data-handling terms. It adds the authorization-and-audit layer above them, on the request itself. Book a demo today.
Frequently asked questions
- Is Claude Enterprise secure enough on its own for regulated data?
Claude Enterprise provides SSO, SCIM, a no-training default, and configurable retention, which is a strong account baseline. It does not evaluate whether a given authenticated user may send specific regulated data in a prompt, so request-level authorization remains your responsibility.
- Does Anthropic's no-training default cover my compliance obligations?
It covers how Anthropic handles your data on its side, which is part of vendor due diligence. It does not govern which of your employees may send regulated data to the model, and it does not produce the independent audit record a regulator asks for under EU AI Act Article 12.
- How do agents change Claude enterprise security?
A Claude-powered agent typically acts on a workspace-scoped API key, so the usage record shows the service identity rather than the person who delegated the task. Carrying user identity onto each downstream call requires an authorization layer at the request boundary.
- Can I block a user from sending privileged content to Claude?
Yes, by evaluating the request on the path to the model against the caller's identity and the prompt's data classification, and blocking it before it executes. That decision sits above SSO and workspace keys, at the AI request boundary.
- Do Anthropic's audit logs satisfy EU AI Act Article 12?
They give an account-level view from the vendor's vantage point. Article 12 traceability is better served by an identity-bound record that includes policy state and data classification and is produced independently of the application making the call.