Amazon Q Security at the AI Request Boundary
Amazon Q teams need evidence that connects each AI request to an authenticated actor, policy decision, and timestamp. This article separates provider administration records from independent request-layer evidence and maps the HTTP controls that regulated enterprises can verify during a security review.
TL;DR
- Amazon Q security controls should connect each routed AI request to an authenticated actor, a policy decision, and a timestamp.
Provider administration records support operations, while an independent request-layer record supports a later security or compliance review. The relevant control point sits in HTTP traffic between the application and the LLM endpoint.
The request record
An enterprise AI request begins when an authenticated user or agent sends prompt content through an application to a model endpoint. The record worth retaining identifies the acting principal, the route, the policy evaluated, the decision, and the event time. That structure makes a specific request reconstructable after an incident, a customer inquiry, or a regulatory review.
This is the useful unit of evidence. A team can start with the request timestamp and ask what happened at that moment. The answer should identify the principal that acted, the endpoint selected, and the policy state applied to the prompt. It should also show the decision that governed delivery. Without those fields, a log may describe activity while leaving the security decision itself unclear.
Amazon Q's documentation is the first source to consult for provider-specific logging and security behavior. The second source is the NIST AI Risk Management Framework, which frames governance as a set of documented practices rather than a dashboard setting. A 15-inch laptop on a review-room table can show a console log, but an auditor needs evidence that ties the log to the actual decision.
The distinction matters during review because a console record and a request record answer different questions. The console can establish what the provider exposes for administration. The request record establishes what your control point saw and decided when a user or agent sent prompt content. Both can belong in the evidence set, provided their roles remain clear.
Provider records and independent evidence
Provider logs can show account activity, configuration changes, and service events. Those records help the platform team operate the deployment. The request-level security question has a different shape: who initiated this prompt, what data classification applied, which policy version evaluated it, and did the model receive the request?
I distrust an audit story that depends only on the same application that sent the prompt. Application-owned logs can omit policy context or arrive after the response path has already completed. A decoupled control point records its own decision at the AI request boundary. The AI gateway architecture and audit-trail requirements explain the difference between a traffic control point and a general application log.
Independence here has a practical meaning. The application remains the place where a user or agent creates a request. The control point observes the HTTP exchange, evaluates the applicable policy, and writes evidence about its own decision. That separation gives a reviewer another record to examine when the application log is incomplete or its timing is disputed.
The record also needs to preserve the decision boundary. A permitted request should be identifiable as permitted. A blocked request should be identifiable as blocked. The review does not need a vague statement that policy exists. It needs the policy outcome associated with the particular request and event time. This is why request-layer evidence belongs beside provider administration records rather than being treated as a substitute for them.
Security review criteria
Review Amazon Q against the HTTP path used in the deployment. Confirm which model endpoints the service covers, which identity context arrives with the request, and how a policy outcome is recorded. Then retrieve one permitted request and one blocked request by their timestamps. That exercise exposes gaps more clearly than a generic controls inventory.
Use the same review sequence for both examples. Start with the actor. Follow the route. Identify the policy evaluated. Inspect the recorded outcome. Finish by checking whether the model received the request. The point is to reconstruct the event, not merely to confirm that a log export exists.
The permitted example tests whether the record can show normal delivery with enough context for later examination. The blocked example tests whether enforcement leaves evidence when content is stopped before reaching the model. Together, the two timestamps give the reviewer a concrete pair of events instead of an abstract description of controls.
The scope also has a hard boundary. Local execution, device compromise, and stolen credentials fall outside a proxy that only receives HTTP AI traffic. Security teams need separate controls for those paths. The request boundary remains the correct place to enforce policy on prompt and response content that actually traverses it.
That boundary keeps the review honest. A request-layer control can explain the HTTP traffic it receives and the decision it makes. It cannot turn provider administration records into proof of every activity around a device or credential. The review should therefore test the traffic path directly and assign other security questions to the controls designed for them.
DeepInspect
DeepInspect is a stateless proxy between authenticated users or agents and HTTP LLM endpoints. It evaluates identity-bound policy and prompt-level classification before the request reaches the model, then produces a per-decision audit record outside the application write path.
For teams using Amazon Q, this adds request-level enforcement and evidence without claiming to replace the provider's own controls. The application can continue to send the request through its normal route. DeepInspect supplies a separate decision point for the HTTP traffic and a record that a reviewer can connect to the actor, policy evaluation, outcome, and event time.
That division gives the security review a clear boundary. Amazon Q documentation remains the source for provider-specific logging and security behavior. The request-layer record answers what happened at the traffic control point. The two records can be examined together without confusing administration history with enforcement evidence.
Book a technical deep dive at deepinspect.ai.