Architecture-specific review
Claude API security review
Review the application you build around Claude, not only the model provider. Follow each user request through application authorization, prompt assembly, the Claude API, tool execution and the final response before deciding what can ship.
Start an AI security review →Review scope
What the reviewer needs to establish
This scope is for an application calling the first-party Claude API. Claude on Amazon Bedrock or Google Cloud has a different processor and infrastructure boundary; review the cloud deployment separately. Anthropic's model safeguards do not authorize your users or execute your application's client tools safely.
User identity and API access
Which users can submit a request, whose credential invokes the API, and where is the user's authority checked before data enters a prompt?
Evidence to request: Application access-control rules, API key storage and rotation procedure, user-to-request trace, and tests for cross-user access.
Prompt data and retention
What personal, confidential or regulated content can enter the request? Which API features are enabled, and what retention terms apply to each?
Evidence to request: Data-flow diagram, prompt and attachment inventory, contract or data-processing terms, feature configuration, and logs showing what the application stores itself.
Retrieved and user-supplied content
Can lower-trust documents or messages change the assistant's instructions or cause another user's information to be disclosed?
Evidence to request: Prompt assembly code, retrieval authorization tests, source labeling, and adversarial test cases using untrusted documents.
Client tools and consequential actions
Which tool calls does your application execute when the model requests them? Are permissions checked at execution time, and which actions need human approval?
Evidence to request: Tool schemas and handlers, server-side authorization tests, scoped service credentials, approval flow, and audit events for attempted and completed actions.
Output, gaps and clearance
How are outputs checked before display or use in another system? What remains unverified, who owns the open controls, and what decision is recorded?
Evidence to request: Output handling and test results, control owners, outstanding evidence, residual-risk rationale, and the dated clearance decision.
Architecture example
Follow authority and data end to end
A model endpoint is one component. The security decision also depends on the identity that calls it, the data it receives, the actions it can trigger, and who accepts the remaining risk.
For a support assistant: employee identity → authorized ticket retrieval → Claude API request → proposed ticket update → server-side permission check → human approval where required. The model may propose an update; the application decides whether that employee may make it.
From review to decision
Describe the system, confirm its architecture, examine threats and required controls, attach evidence, and record a human clearance decision. Unknown or missing evidence remains visible; it is not treated as a passed control.
Read the review methodology →