AIG-030 AI Prompt and Input Audit Logging
Description
For LLM-based and generative AI systems, each request is logged with sufficient detail to support incident investigation. Logs include: a request ID, timestamp, session or user identifier (anonymised or pseudonymised where required by data protection law), the system prompt or prompt template identifier (not necessarily the full user input for privacy reasons), the response or response category, model version, and any tool calls made. For high-risk applications (healthcare, legal, financial decisions), the full prompt and response are logged subject to appropriate access controls. Log access is restricted to authorised security and operations roles.
Rationale
LLM interaction logs are the primary forensic artefact for investigating misuse, jailbreak attempts, harmful output incidents, and data leakage. No existing framework specifies what these logs must contain for LLM systems.
Framework Mappings (3)
| EU-AI-Art.12.1 | Logging and Record-Keeping — Automatic Event Logging Capability | informative |
| A.6.2.8 | AI system recording of event logs | informative |
| MEASURE 2.4 | AI System Production Monitoring | informative |
Evidence (2)
LLM request-response logs for a production system demonstrating that required fields are captured: request ID, timestamp, session or user identifier, system prompt template identifier, response or response category, model version, and tool calls.
Example: CloudWatch log sample for ai-support-chat-api (50 events, 2026-04-01): each event containing request_id (UUID), timestamp (ISO8601), session_id (hashed), prompt_template_id ('support-v4'), response_category ('escalation' | 'resolved'), model_version ('claude-sonnet-4-6'), tool_calls (JSON array or null)
Test: Request a log sample (minimum 50 events) from the LLM request-response log store. Verify: (1) all required fields are present in every event, (2) full prompt/response content is logged for high-risk applications with access controls confirmed (check who has read access to that log stream), (3) session or user identifier is pseudonymised where data protection law requires, (4) log retention period is confirmed to meet minimum (6 months) and organisation's stated requirement, (5) log store is write-protected or append-only.
Log access control configuration demonstrating that LLM prompt and response logs are restricted to authorised security and operations roles, with access logging enabled.
Example: Splunk index access control configuration for ai-llm-prompts index: read access limited to security-team and ml-ops-team roles, no access for general dev role; AWS CloudTrail showing last 30 days access by authorised accounts only, access log retention: 12 months
Test: Review access control configuration for the LLM log store. Verify: (1) read access is restricted to named security and operations roles, (2) developer roles do not have unrestricted access to full prompt/response logs, (3) access to the log store is itself logged and auditable, (4) no service accounts with overly broad access exist on the log store.
Questions (2)
Are LLM request-response interactions logged with sufficient detail to support incident investigation and audit?
Net-new control: LLM interaction logs are the primary forensic artefact for investigating misuse, jailbreak attempts, harmful output incidents, and data leakage. No existing framework specifies what these logs must contain for LLM systems.
Which fields are captured in your LLM request-response logs for each interaction?
The first six fields are required for all LLM systems. Full prompt and response logging applies to high-risk applications and must be protected by access controls restricting access to security and operations roles only.