A security review of a Claude deployment is mostly not about AI. It is about the same things every review is about: data flows, identity, logging, and failure modes. The AI-specific parts are real but small. Walk in with written answers to the ten questions below and the review becomes a working session instead of an interrogation.
Data questions
1. What data do we send, and where does it go? Name the platform, the region, and the categories of data in your prompts. A good answer is specific: "Support ticket text, with emails and phone numbers redacted, sent to Claude on Amazon Bedrock in our primary AWS region." A bad answer is "just some text."
2. Is our data retained or used for training? Do not answer from memory. Cite the current data-handling terms of the specific platform you use, with a dated copy attached. These commitments are contractual and vary by provider; confirm specifics with your provider, especially for beta features.
3. What do we log, and who can see it? Your own logs of prompts and responses usually hold more sensitive data than anything the platform retains. Bring your logging policy: what is captured, retention period, access controls, and where the log store lives.
Access and boundary questions
4. Who and what can call the model? The right answer names identities, not people: which IAM roles, service accounts, or resource keys can invoke Claude, scoped per environment. Because 3P access rides on your cloud's identity system, this should look exactly like your answer for any other managed service.
5. How are credentials stored and rotated? Secret manager or workload identity, never keys in code or config files. If you cannot describe rotation, expect a finding.
6. What network path does the traffic take? Encrypted via TLS at minimum; private endpoints if your policies require traffic to stay off the public internet. Know which requirement applies to this workload before the meeting.
7. Could the model take actions or reach data beyond the user's own? This is the prompt-injection question in operational form. If the model has no tools, say so; that bounds the risk to bad text. If it has tools, show that each tool is scoped to the requesting user's permissions and that consequential actions require human confirmation.
Operational questions
8. Would we notice misuse or anomalies? Point to your audit trail: cloud-native logging (such as CloudTrail on AWS or Cloud Audit Logs on Google Cloud) for who called what, plus application-level metrics for volume and error anomalies. "We would see it in the invoice" is not monitoring.
9. What happens when the model is wrong? Every LLM produces incorrect output sometimes. Show where humans review or approve before output causes consequences, and how users report bad results. Reviews go badly when teams claim the model is always right; they go well when teams show the failure path is designed.
10. What is the incident plan? Have a one-page runbook covering the three realistic scenarios: harmful or wrong output reaching users, sensitive data sent that should not have been, and quota exhaustion or platform outage. Named owner, kill switch, escalation path.
How to run the review
Prepare a two-page packet: an architecture diagram showing the data flow from user to platform endpoint and back, the data map from question 1, the identity scoping from question 4, and the runbook from question 10. Send it before the meeting. One more preparation tip: because 3P deployments run inside your existing cloud, your reviewers likely already trust the underlying platform controls; the workload inherits that provider's compliance posture, though inheritance is not a blanket approval and specifics should be confirmed with your provider. Frame the review as "a new workload on an already-reviewed cloud," because that is what it is, and reserve the discussion time for the genuinely new part: questions 7 and 9.
Where to go next
Question 7 deserves its own reading: Prompt Injection 101. For question 8, see Audit Logging Claude Usage, and for question 10, Incident Response for LLM Apps.