Claude AI security review — what a procurement team should assess

A vendor security review for an LLM provider is structurally different from reviewing a traditional SaaS product. The “application” is a model — a statistical artefact whose behaviour changes between versions in ways that are not captured by a changelog. The data flows are bidirectional: your prompts go in, completions come out, and what happens to both in between is the core of the review.

This review covers Claude accessed via the Anthropic API (api.anthropic.com). If you are accessing Claude through AWS Bedrock or Google Cloud Vertex AI, the infrastructure layer is different and some data-handling guarantees come from the cloud provider rather than Anthropic directly. That changes the review scope — you are reviewing two vendors, not one.

The first domain of any LLM vendor review is what happens to the data you send. For Claude, this breaks into three questions:

1. Are prompts and completions used for training?

Anthropic's commercial API terms (as of 2026) state that data submitted through the API is not used to train models. This is the baseline expectation for any enterprise LLM vendor. However, a review should verify:

• Whether this commitment applies uniformly or has carve-outs (e.g., for abuse detection, safety research, or model improvement with explicit opt-in).
• Whether the commitment is contractual (in the DPA/MSA) or only in a usage policy that can change unilaterally.
• What the mechanism is — technical (data deleted after response) or policy (data retained but ring-fenced).

2. How long are inputs and outputs retained?

Anthropic has disclosed that API inputs may be retained for a limited period (historically 30 days) for trust and safety purposes — detecting abuse, responding to legal process. A review should confirm the current retention window, what triggers access to retained data, and whether enterprise customers can negotiate shorter retention or zero-retention terms.

3. Where does processing occur?

Anthropic's infrastructure runs primarily on GCP and AWS. For organisations with data residency requirements (EU, regulated sectors), the question is whether inference happens in a specific region and whether prompts transit through other regions en route. The Bedrock and Vertex deployment options provide regional guarantees from the cloud provider, but direct API usage may not offer the same regional pinning.

Model governance is the domain most traditional vendor reviews miss entirely. A SaaS vendor ships feature updates; an LLM vendor ships new models whose behaviour is fundamentally different from the previous version — even when the API endpoint stays the same.

Versioning and deprecation

Anthropic uses dated model versions (e.g., claude-sonnet-4-20250514). However, a review should clarify:

• What the deprecation timeline is for a specific model version once a successor ships.
• Whether “pinned” version strings guarantee identical behaviour or only API compatibility.
• What advance notice is given before a version is retired — and whether that notice is contractual or best-effort.

Change notification

When a new model version is released, existing integrations may behave differently. The review should establish whether your organisation will receive advance notice of changes that affect your specific use case, or whether you discover regressions through your own testing. Anthropic publishes a model card and changelog for major releases, but behavioural changes within a version family may not be announced with the same formality.

System prompt confidentiality

If your integration uses a system prompt to steer Claude's behaviour, the review should assess whether that prompt is visible to Anthropic staff, how it is handled in retained data, and whether it could be extracted by adversarial user inputs (prompt leakage). Claude has built-in resistance to prompt extraction, but this is a statistical defence, not an absolute guarantee.

The access control surface for an LLM API is narrower than a full SaaS product, but the consequences of a leaked key are immediate and expensive.

API key management

Anthropic's console supports multiple API keys per organisation, with the ability to create and revoke keys. A review should verify:

• Whether keys can be scoped to specific models, rate limits, or IP ranges.
• Whether key usage is logged with sufficient detail to attribute requests to internal teams or services.
• Whether there is anomaly detection or alerting on unusual usage patterns (e.g., a 10x spike in token consumption).
• What the key rotation mechanism is — can keys be rotated without downtime?

Rate limiting and spend controls

A compromised or misconfigured integration can burn through token budgets in minutes. The review should confirm whether Anthropic provides hard spend caps (not just alerts), per-key rate limits, and whether those limits can be set granularly enough to match your internal cost allocation model.

Authentication for enterprise features

Beyond API keys, the review should assess the authentication model for the Anthropic Console (the admin interface) — whether it supports SSO/SAML, MFA enforcement, role-based access, and audit logging of administrative actions like key creation or policy changes.

Output safety is the domain where LLM reviews diverge most sharply from traditional application security. The model's outputs are non-deterministic, and “safe” output depends heavily on context.

Hallucination risk

Claude, like all LLMs, generates plausible-sounding text that may be factually incorrect. A security review should ask: what is the downstream consequence of a hallucinated output in your specific use case? If Claude is summarising legal contracts, a hallucinated clause is a different class of risk than a hallucinated code comment. The review should document what mitigations exist (retrieval grounding, citation verification, confidence calibration) and where the residual hallucination risk is accepted.

Content filtering and refusals

Anthropic applies safety filters that may cause Claude to refuse certain requests. For enterprise use cases, the review should clarify:

• Whether safety filters can be tuned for your use case (e.g., medical or legal contexts that trigger false refusals).
• Whether refusal rates are measurable — can you get metrics on how often Claude refuses legitimate requests?
• What the escalation path is when a safety filter blocks a valid business use case.

Prompt injection resistance

If your integration passes user-controlled input to Claude (e.g., a customer support agent that processes customer messages), prompt injection is a direct security concern. Claude has architectural mitigations — including a distinction between system, user, and assistant turns — but these are probabilistic defences. The review should document what injection testing has been performed, what the residual risk is, and what compensating controls exist at the application layer.

Anthropic's compliance posture has matured significantly since Claude's initial release. A review should verify current certifications and assess their scope:

SOC 2 Type II

Anthropic holds SOC 2 Type II certification. The review should confirm: which trust service criteria are covered (Security, Availability, Confidentiality, Processing Integrity, Privacy), whether the report covers the API service specifically or only corporate infrastructure, and whether a copy of the report is available under NDA. A SOC 2 that covers corporate email but not the inference pipeline is not useful for this assessment.

Responsible use and acceptable use policies

Anthropic publishes an Acceptable Use Policy (AUP) that restricts certain use cases. The review should check whether your intended use case is clearly permitted, borderline, or excluded — and what happens if a policy change reclassifies your use case after you have deployed. Policy changes that restrict your use case mid-contract are a business continuity risk.

Regulatory alignment

For organisations subject to the EU AI Act, GDPR, or sector-specific regulation (healthcare, finance), the review should assess whether Anthropic provides the documentation needed to demonstrate compliance. This includes: DPAs with appropriate SCCs for cross-border transfers, technical documentation for AI Act conformity assessments, and data processing records that match your ROPA entries.

Every vendor review surfaces gaps — things the vendor does not disclose publicly and that must be resolved bilaterally (through the enterprise sales process, under NDA, or contractually). For Claude, the most common evidence gaps as of mid-2026 include:

These are not criticisms. They are the normal gaps that exist between a vendor's public documentation and what an enterprise security review requires. The purpose of listing them is to give procurement teams a starting point for bilateral conversations with Anthropic's enterprise sales team.

A structured security review of Claude for enterprise adoption should cover the following minimum set of questions. Each maps to the domain sections above:

This is a minimum set. Your specific use case will add domain-specific questions — healthcare use adds HIPAA BAA requirements, financial services adds model risk management (SR 11-7) considerations, and any use case involving PII adds data subject rights obligations.

Claude is, by the standards of the current LLM market, a relatively transparent vendor. Anthropic publishes model cards, maintains a responsible scaling policy, and holds SOC 2 certification. That puts it ahead of many competitors on disclosure. But “ahead of competitors” is not the same as “sufficient for enterprise security review” — and the gaps listed above are real gaps that a procurement team needs to close before signing.

The underlying challenge is structural: LLM vendors are a new category of supplier. They do not fit cleanly into existing vendor risk frameworks designed for SaaS, IaaS, or professional services. A security review of Claude requires asking questions that your standard vendor questionnaire does not contain — about model versioning, about behavioural guarantees, about the distinction between policy commitments and technical controls.

The right approach is not to force Claude into your existing SaaS vendor template. It is to extend the template with LLM-specific domains — data handling for model inputs, governance for model versions, safety for non-deterministic outputs — and then assess Claude against that extended framework.

The goal of a Claude security review is not to produce a pass/fail verdict. It is to produce a clear-eyed assessment of what is known, what is not, and what controls your organisation needs to add at the application layer to bridge the gap. That assessment is the foundation for a risk-informed procurement decision — not a reflexive approval or rejection.