Amazon Q Audit Logs 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 audit evidence 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.
The record should answer one question quickly: what happened to this request?
That answer depends on connected fields rather than an isolated timestamp. An identity field names the user or agent. A route field shows where the request was sent. The policy field identifies the rule or policy version that was evaluated. The decision field records whether the request was allowed, blocked, or handled according to another defined outcome. The event time fixes the sequence.
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.
A useful review record also preserves enough context to distinguish similar requests. One employee may submit a financial forecast through an internal assistant in the morning, then send source code to a different model route after lunch. A timestamp alone cannot establish which decision belongs to which request. The surrounding request context supplies that connection.
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?
Those questions belong to the request path. They concern the moment when content, identity, and policy meet. A provider administration record may document a configuration change, while a request-layer record documents the decision applied to an individual prompt. Both records can matter during review, but they answer different questions.
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 matters when the application has an outage, a logging defect, or an incomplete implementation. The application may still be the place where a user enters a prompt, but it should not be the only place that records the policy decision. An external record gives the security team another account of what crossed the boundary.
That record should also make review practical. A security engineer should be able to start with an actor, timestamp, route, or decision and locate the corresponding event. If every search requires reconstructing application state first, the evidence takes longer to verify and is more likely to be misread.
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.
Start with the allowed request. Confirm that the record names the actor, identifies the destination, shows the policy evaluation, and records the decision time. Then inspect the blocked request. The event should show the same basic chain, with the policy outcome explaining why the model did not receive the request.
The test is simple. The evidence is often scattered.
A review should compare the request event with the provider administration record and the application record. Matching timestamps can support the reconstruction, but matching timestamps alone are weak evidence. The records need a shared request identifier or enough stable context to show that they describe the same event. Otherwise, an auditor may see three plausible entries without a reliable chain between them.
Keep the review focused on the deployed route. Confirm whether the application sends requests directly to the model endpoint, whether an intermediary handles the traffic, and where identity is attached. Document the policy decision at the point where the request can still be allowed or blocked.
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.
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.
That placement gives the security team a distinct request-layer record to compare with provider and application records. The record can connect the authenticated principal, the policy evaluation, the decision, and the time of the event. It also keeps the enforcement question tied to traffic the proxy can inspect.
For teams using Amazon Q, this adds request-level enforcement and evidence without claiming to replace the provider's own controls. Book a technical deep dive at deepinspect.ai.