跳转到主要内容

Audit record reference

Docker AI Governance audit records use one schema across delivery modes. Local JSON Lines files and cloud-delivered records contain the same metadata fields.

Records capture metadata only. They don't contain prompt content, agent output, or parameter values. Parameter keys may appear when they help identify an action.

Common fields

Field Description
audit_event_id Unique ID for the audit event.
timestamp UTC time when Docker recorded the event.
schema_version Version of the record schema. Pin SIEM field mappings to this value.
category Event category, such as AUDIT_CATEGORY_MANAGEMENT, AUDIT_CATEGORY_EVALUATION, or AUDIT_CATEGORY_EXECUTION.
decision Governance decision for evaluation records.
username The signed-in Docker user's Docker Hub username.
user_email The signed-in Docker user's email address.
org_id ID of the organization whose governance policy is in effect.
org_name Display name of the organization whose governance policy is in effect.
audit_session_id Identifies the daemon session that produced the record.
resource_id Target of the evaluation, such as a host and port, file path, or tool.
os Operating system that produced the record.
app_version Version of the Docker component that produced the record.
client_name Source component, such as sbx for Docker Sandboxes.
hostname Hostname of the machine that produced the record.
deny_reason Why a denied request was blocked. Present on deny decisions.
enforcement_mode Governance mode in effect when Docker evaluated the request. See Enforcement modes.
approval Approval details. Present when the decision involves an approval. See Approval fields.
action_type Payload discriminator that identifies the action-specific object in the record.
agent AI agent associated with the event, when Docker knows it.

Categories

Category Description
AUDIT_CATEGORY_MANAGEMENT Session lifecycle, policy sync, and configuration events.
AUDIT_CATEGORY_EVALUATION Governance policy decisions, such as allow, deny, or consent.
AUDIT_CATEGORY_EXECUTION Outcomes after an evaluated action runs.

Decisions

Decision Description
AUDIT_DECISION_ALLOW Docker allowed the action.
AUDIT_DECISION_DENY Docker denied the action.
AUDIT_DECISION_APPROVAL_REQUIRED The policy requires a user to approve the action.
AUDIT_DECISION_APPROVAL_ALLOW A user approved a pending request.
AUDIT_DECISION_APPROVAL_DENY A user denied a pending request.

Enforcement modes

The enforcement_mode field shows how governance applied to the request when Docker evaluated it.

Mode Description
enforce Your organization's governance policy is enforced.
audit Docker records the decision for observability but doesn't enforce policy.
off Governance isn't active. Docker still writes the record to the local audit log.

A record that resolves a network approval doesn't include enforcement_mode, and neither does the record of a declined MCP approval. An approved MCP request is evaluated again, so its record includes enforcement_mode.

Approval fields

When network access requires approval, Docker blocks the request and writes an AUDIT_DECISION_APPROVAL_REQUIRED record. If the user approves, Docker writes a second record with AUDIT_DECISION_APPROVAL_ALLOW. Both records carry the same approval.approval_request_id, so you can join them to reconstruct the full approval. The approval applies to later requests from the sandbox. It doesn't retry the request that was blocked. If the user dismisses the request, it isn't resolved, so no second record is written and the destination is requested again the next time the sandbox reaches it. For how approval works, see Approval-required access.

For MCP approvals, an approved request is evaluated again and recorded with AUDIT_DECISION_APPROVAL_ALLOW, and a declined request is recorded with AUDIT_DECISION_APPROVAL_DENY. Neither record includes approval.approval_request_id or approval.grant_scope.

Field Description
approval.reason_codes Policy reasons for requiring approval. Present on AUDIT_DECISION_APPROVAL_REQUIRED records when the policy supplies reasons, and on declined MCP approvals when reasons are available.
approval.approval_request_id ID that links an approval required record to the record that resolves it.
approval.grant_scope Scope the user accepted. Present only on AUDIT_DECISION_APPROVAL_ALLOW records.
approval.context_digest SHA-256 digest of the request that was resolved, which shows it matches the request that was held. Present only on declined MCP approvals.

For network approvals, Docker Sandboxes records approval.grant_scope as AUDIT_APPROVAL_GRANT_SCOPE_PERSISTENT, which means that the approval applies to later requests.

If a user approves a request but Docker can't apply the grant, the record has an AUDIT_DECISION_DENY decision and includes the approval object.

Action types

The action_type field identifies the action-specific payload in the record.

Action type Description
session Sandbox daemon session lifecycle event.
network_egress Network access evaluation.
http_request HTTP request evaluation. See HTTP request payload.
filesystem_mount Filesystem mount or path access evaluation.
tool_invocation Tool invocation evaluation.
resource_read Resource read evaluation.
server_registration Server registration event.
prompt Prompt-related metadata event.
network_egress_execution Outcome of a network action.
filesystem_mount_execution Outcome of a filesystem action.
tool_execution Outcome of a tool invocation.
resource_read_execution Outcome of a resource read.
prompt_execution Outcome of a prompt request.
policy_sync Policy synchronization event.
pii_detection Metadata event for a data detection result.
c_score_report Metadata event for a C-score report.
policy_action Policy configuration or policy action event.

HTTP request payload

When a network policy requires each HTTP request to be authorized, Docker evaluates the request method and path in addition to the network connection. These evaluations produce records with an action_type of http_request, separate from the network_egress record for the connection.

Field Description
http_request.method HTTP method, such as HTTP_METHOD_GET or HTTP_METHOD_POST.
http_request.host Destination hostname or IP address. IPv6 addresses appear without brackets.
http_request.port Destination port.
http_request.path URL path, without the query string or fragment.

Sample record

{
  "audit_event_id": "95e7257f-93c9-4f29-bde7-88830e2dae80",
  "timestamp": "2026-05-28T19:15:00.728933Z",
  "schema_version": "1.82.0",
  "category": "AUDIT_CATEGORY_EVALUATION",
  "decision": "AUDIT_DECISION_DENY",
  "username": "jordandoe",
  "user_email": "jordandoe@example.com",
  "org_id": "9f8e7d6c-5b4a-3210-fedc-ba9876543210",
  "org_name": "Acme Inc",
  "audit_session_id": "8a3bc076-79d0-4502-baf3-cc6ad35fb578",
  "resource_id": "example.com:443",
  "os": "macos",
  "app_version": "v0.31.0",
  "client_name": "sbx",
  "hostname": "host-machine",
  "deny_reason": [
    "no applicable policies for op(action=net:connect:tcp, resource=net:domain:example.com:443)"
  ],
  "action_type": "network_egress",
  "network_egress": { "protocol": "tcp" },
  "agent": "claude"
}

The following sample shows a user approving an HTTP request that required approval:

{
  "audit_event_id": "3c1f6a2e-8b47-4d0a-9e55-2f7b1d6c9a04",
  "timestamp": "2026-09-25T17:42:08.114502Z",
  "schema_version": "1.216.0",
  "category": "AUDIT_CATEGORY_EVALUATION",
  "decision": "AUDIT_DECISION_APPROVAL_ALLOW",
  "username": "jordandoe",
  "user_email": "jordandoe@example.com",
  "org_id": "9f8e7d6c-5b4a-3210-fedc-ba9876543210",
  "org_name": "Acme Inc",
  "audit_session_id": "8a3bc076-79d0-4502-baf3-cc6ad35fb578",
  "resource_id": "api.example.com:443",
  "os": "macos",
  "app_version": "v0.46.0",
  "client_name": "sbx",
  "hostname": "host-machine",
  "approval": {
    "approval_request_id": "b7e2c9d1-4f60-4a8e-93c2-5d1e8f7a6b30",
    "grant_scope": "AUDIT_APPROVAL_GRANT_SCOPE_PERSISTENT"
  },
  "action_type": "http_request",
  "http_request": {
    "method": "HTTP_METHOD_POST",
    "host": "api.example.com",
    "port": "443",
    "path": "/v1/items"
  },
  "agent": "claude"
}