Tool Access Audit Log Prompt Template

This prompt is designed for compliance engineers and platform operators who need a structured, machine-readable justification for every tool access decision an agent makes. The job-to-be-done is not simply logging that a tool was called or denied; it is producing an auditable record that links the decision to a specific policy clause, captures the risk factors present at decision time, and provides a clear rationale that a human reviewer or automated compliance system can evaluate later. Use this prompt when you are building an agent platform that must satisfy internal governance requirements, external regulatory audits, or customer contractual obligations around AI decision traceability.

The ideal user is an engineer integrating this prompt into an agent harness where tool access decisions are already being made by a gating or authorization step. You must have the following context available before invoking this prompt: the user's role and session state, the specific tool and arguments requested, the risk score or risk category assigned to the request, the relevant policy document or clause identifier, and the final allow/deny decision. Without these inputs, the prompt will produce vague or ungrounded justifications that fail audit scrutiny. Do not use this prompt as the primary tool access control mechanism; it is a post-decision documentation step, not a policy enforcement point. The access decision must be made upstream by a deterministic or model-based gating system, and this prompt only documents that decision.

This prompt is inappropriate for real-time user-facing explanations. The output is structured for machine consumption and internal audit systems, not for end-user display. If you need a user-facing denial explanation, pair this with a separate prompt from the 'Tool Denial Explanation Prompt for End Users' or 'Safe Alternative Suggestion Prompt for Denied Tools' playbooks. Additionally, do not use this prompt in environments where the policy itself is ambiguous or undocumented; the model cannot invent policy citations and will hallucinate references if forced. Before deploying, ensure you have a validation step that checks the output schema, verifies the policy citation exists in your known policy set, and confirms the decision field matches the actual access decision made by your system. For high-compliance environments, always route a sample of generated logs to human review as a calibration check.

This template is designed to be inserted into the agent's decision loop immediately after a tool invocation is proposed. It instructs the model to produce a machine-readable justification record before the tool call is executed or denied. The output is a single JSON object that can be ingested by your SIEM, compliance database, or monitoring dashboard. Use this template when you need every tool access decision—allow or deny—to be traceable to a specific policy, a risk assessment, and a human-auditable rationale.

codeCopy
You are an audit logging module. Your only job is to produce a structured justification for a tool access decision. Do not execute the tool. Do not continue the conversation. Output only the JSON object described below.

## Input
- Proposed Tool Call: [TOOL_CALL]
- User Context: [USER_CONTEXT]
- Session Risk Score: [SESSION_RISK_SCORE]
- Active Policy Document: [POLICY_DOCUMENT]
- Decision: [DECISION] (must be exactly "ALLOW" or "DENY")

## Output Schema
Return a single JSON object with these fields:
- `decision`: string, must match [DECISION]
- `policy_citation`: string, the exact clause or rule from [POLICY_DOCUMENT] that governs this decision
- `risk_factors`: array of strings, the specific risk factors from [USER_CONTEXT] and [SESSION_RISK_SCORE] that influenced the decision
- `rationale`: string, a concise explanation of why the decision was made, referencing the policy and risk factors
- `tool_name`: string, extracted from [TOOL_CALL]
- `tool_arguments_summary`: string, a sanitized summary of the tool arguments that excludes any PII or secrets
- `timestamp`: string, ISO 8601 timestamp of when this log entry was generated
- `log_id`: string, a unique identifier for this log entry (UUID v4 format)

## Constraints
- Do not include any text outside the JSON object.
- Do not execute, simulate, or describe the tool's output.
- If [DECISION] is DENY, the rationale must explain what policy clause was violated.
- If [DECISION] is ALLOW, the rationale must explain why the request is within policy bounds.
- Sanitize tool arguments: replace any value that appears to be a secret, token, password, or PII with "[REDACTED]".
- The `policy_citation` must be a verbatim quote from [POLICY_DOCUMENT] whenever possible.

Adaptation guidance: Replace the square-bracket placeholders with values from your application context. [TOOL_CALL] should be the raw function call object (name and arguments). [USER_CONTEXT] should include role, authentication level, tenant ID, and any relevant attributes. [SESSION_RISK_SCORE] is a numeric or categorical value from your upstream risk classifier. [POLICY_DOCUMENT] should be the full text of the policy section relevant to tool access. [DECISION] must be supplied by your authorization system before this prompt runs—this template documents the decision, it does not make it. For high-compliance environments, add a reviewer_id field and route DENY entries with elevated risk scores to a human review queue before the log is finalized.

This prompt is designed to be called after a tool access decision has been made but before the tool is executed. In a production agent loop, you should intercept the proposed tool call, invoke the audit log prompt with the decision context, validate the structured output, and only then proceed with execution. The audit log entry should be stored immutably alongside the tool call record, not as a separate asynchronous process that could be lost or reordered. Treat the audit log generation as a synchronous gate: if the prompt fails to produce a valid, complete log entry, the default behavior should be to deny the tool call and escalate to human review rather than executing without a record.

Validation and retry logic is critical here. The prompt outputs a JSON object with fields like decision_id, policy_citation, risk_factors, and rationale. Your harness should validate that all required fields are present, that policy_citation references an actual policy clause from your policy registry (not a hallucinated one), and that the decision field matches the actual access decision. If validation fails, retry once with the validation errors appended to the prompt context. If the retry also fails, log the failure, deny the tool call, and route to a human review queue. For high-risk tools, consider requiring a second model call with a different temperature setting to confirm consistency before accepting the log entry.

Model choice matters. This prompt requires strong instruction-following and structured output discipline. Use a model that supports strict JSON mode or function calling to enforce the output schema. Avoid models that are prone to creative embellishment in structured outputs. For compliance-critical deployments, pin the model version and run regression tests against a golden set of tool access scenarios before any model upgrade. Logging and observability should capture the raw prompt, the raw response, the validation result, and the final stored log entry. This four-part trace is essential for audit review and for debugging when the prompt produces unexpected policy citations or risk assessments. Finally, ensure that the audit log storage is append-only and tamper-evident—the prompt produces the evidence, but your infrastructure must protect it.