loading…
[OK] dns resolved
[OK] tcp handshake
[..] waiting on payload
Docker announced AI Governance audit logs for organizations using Docker Sandboxes under enforced governance policy. The practical change is simple: policy decisions made by Docker’s agent sandbox layer can now be searched in Docker Cloud, exported, or streamed into SIEM tools such as Splunk, Datadog, Dynatrace, and Grafana.
That sounds like a checkbox feature until you remember what normal logs do not show. Application logs can tell you what ran. They are much worse at telling you what almost ran but was blocked before it touched the network, filesystem, or a credential. That is where agent governance has been weirdly theatrical: lots of policy language, not always enough evidence. Security teams, famously, prefer evidence over vibes. Strange habit.
Docker says AI Governance now produces a searchable record of policy decisions and sandbox session events for Docker Sandboxes. According to the audit log documentation, each record captures metadata such as the principal, action, target, decision, and time. Docker also states that records do not include prompt content, agent output, or parameter values.
There are two delivery paths:
The delivery docs say both modes can be enabled independently or together. Cloud delivery is on by default when AI Governance is enabled, though organizations that were already using local audit logging start with cloud delivery off until an owner opts in.
The hosted view can filter by decision and time range, and search by principal, resource, event type, or agent. Docker’s view/export docs also note that CSV exports can include up to 1,000,000 rows and that download links expire after 24 hours.
The interesting bit is not “Docker added logs.” Everyone adds logs. Logs multiply like rabbits with a procurement department.
The interesting bit is where the record is created: at the enforcement point. For agent systems, that matters because the most important security event may be the thing that never executes:
If your observability pipeline only watches process output, it sees successful activity and some failures. It does not necessarily see the rejected intent. For AI agents, rejected intent is often the whole story.
This also moves agent governance closer to the operating model security teams already use. Instead of asking a separate AI tool dashboard for proof, teams can route these records into the same SIEM workflows they use for endpoint, identity, and cloud activity. That makes agent controls easier to review, correlate, and eventually automate around.
Docker’s record reference describes a shared schema across local JSONL files and cloud-delivered records. It includes categories such as management, evaluation, and execution, plus decisions like allow, deny, approval required, approved, and rejected.
That gives operators a few useful handles:
This is not a universal agent audit layer. Docker’s docs say the current coverage is Docker Sandboxes policy decisions and sandbox session events. Docker says other AI sources can emit records through the same schema as they become available, but that is future expansion, not present coverage.
It is also a paid, organization-scoped feature. The docs say AI Governance Audit Logs require a Docker AI Governance plan, an enforced organization governance policy, and appropriate owner or custom-role permissions. Users without both an AI Governance license and enforced org policy do not generate these audit records.
The metadata-only design is a good privacy posture, but it is not magic. If you need forensic reconstruction of prompts, tool parameters, or generated output, these audit records are intentionally not that. You still need application logs, sandbox telemetry, endpoint logs, and whatever unpleasant spreadsheet your compliance process insists is “temporary.”
Agent security is slowly becoming normal security: identity, policy, enforcement, logs, retention, exports, SIEM pipelines. That is good. Boring controls are usually the ones that survive contact with production.
Docker’s audit log update is useful because it treats agent policy decisions as first-class operational evidence, not a sidebar in an AI dashboard. If your team is putting coding agents or sandboxed tool users anywhere near real systems, start asking the same dull questions you ask everywhere else: who did what, what was blocked, where is the record, how long is it retained, and can your security tools see it?