Docker AI Governance: Audit Logs, Now Where Your Security Team Already Works

Now in Docker AI Governance: a single searchable record of every policy decision your agents trigger, streamed to the SIEM your security team already runs, so you can show what your agents did and what your policy stopped.

Today, Docker AI Governance now streams every policy decision in your organization into the SIEM your security team already runs, with a searchable record of all of it in Docker Cloud. You can see what your agents did, and what your policy stopped them from doing.

Enforcement is step one

When we launched AI Governance in May, our perspective was that controls have to live at the runtime layer where the agent actually executes, not as advisory rules a clever prompt can route around. Audit was one of the three layers we shipped on that principle, and the enforcement point has produced a structured event for every policy evaluation since day one.

Today, we’re making it easier to view and consume those events.

Why audit records matter

Security leads need to answer questions about agent behavior: what did that agent do, was it allowed, and which policy made the call.

Answering it should not require assembling evidence from machines they don’t administer. It should mean querying a system they already use. Increasingly it also comes first rather than after: security teams want a demonstrable audit record before they approve agent deployment at all.

What only the enforcement point can see

A policy decision has three outcomes. The action was allowed, it was denied, or it was held for a human.

A log collector can reconstruct the first one. Nothing outside the enforcement point can see the other two. A collector reads what an agent produced, so it never sees the tool call that was refused, the domain that was unreachable, or the credential that was requested and withheld. Those events leave no trace in output, because the process that would have produced the output never ran.

That is the difference between a record generated at the point of decision and logs gathered after the fact. A record of allowed actions shows that agents are active. A record of denials shows whether your controls are doing anything.

Audit Logs: Streamable to your SIEM tools

Audit logs are now available in Docker Cloud, and audit events can stream directly to your SIEM. Both are included with Docker AI Governance.

Audit logs in Docker Cloud. One searchable view for the whole organization, with 90 day retention and CSV export. Local disk delivery keeps working, and both modes can run at once.

Native SIEM streaming. Point Docker at your endpoint and forward audit records to the tools you already run, including Splunk and Dynatrace, via a generic HTTPS connection.

Coverage

Records cover Docker Sandboxes policy decisions and sandbox session events, for users with an AI Governance license under an enforced organization policy. Other source records (MCP Gateway enforcement decisions, for example) will share records through the same schema as they become available, so coverage will expand without extra integrations on your end.

Records are metadata only. They never contain your prompt content, agent output, or parameter values.

What’s next

Records are step one.

Once every decision an organization makes about its agents lands in one place, the useful question stops being what happened and starts being what should change. That is the direction we’re building toward: a system that tells you when something is off and what to do about it. More on that soon.

Available today

Audit logs are live for organizations on Docker AI Governance with an enforced organization policy. Read more here.

Quelle: https://blog.docker.com/feed/

AWS Transform for full-stack Windows modernization now supports offline schema transformation to Aurora PostgreSQL

Today, AWS Transform for full-stack Windows modernization announced general availability of offline source transformation, enabling customers to modernize Microsoft SQL Server databases to Amazon Aurora PostgreSQL without requiring a live database connection. AWS Transform now converts SQL Server storage objects, powered by AWS DMS, and code objects (stored procedures) using an agentic, interactive experience. Enterprises modernizing legacy .NET applications and their dependent SQL Server databases can now start their modernization by directly uploading the Data Design Language (DDL) source files from their databases.
With offline source transformation, customers upload SQL Server data design language (DDL) files, assess database and stored procedure complexity, and generate a customizable transformation plan. AWS Transform converts tables, schemas and converts code objects such as stored procedures and functions, validates functional equivalence, and deploys the converted schema to Aurora PostgreSQL. The same workflow transforms database dependent .NET applications to be PostgreSQL compatible .NET applications with updated connection strings, ADO.NET and Entity Framework data-access calls. To address remaining conversion issues, customers can iterate directly in the web console or hand off to their preferred IDE using the AWS Transform MCP server. A separate synthetic data workflow populates Aurora PostgreSQL with test data for end-to-end application validation.
AWS Transform for full-stack Windows modernization and offline source transformation is available in US East (N. Virginia). To get started, you can go to AWS Transform product page or see AWS Transform for full-stack Windows documentation.
Quelle: aws.amazon.com

AWS WAF now supports Miggo Security managed rule groups for emerging threats and AI/ML application protection

AWS WAF now supports two new partner managed rule groups from Miggo Security, available through AWS Marketplace: Miggo Rules for AWS WAF – High Emerging Application Threats, and Miggo Rules for AWS WAF – AI/ML Application Protection. These rule groups give AWS WAF customers continuously updated protection against vulnerabilities that are being actively exploited, have public proof-of-concept code, or appear in the CISA Known Exploited Vulnerabilities (KEV) catalog, without writing or maintaining custom rules. The High Emerging Application Threats rule group focuses on vulnerabilities under active exploitation, and the AI/ML Application Protection rule group focuses on generative-AI application stacks such as AI agent frameworks, LLM gateways, and model-serving infrastructure. You can subscribe to either rule group and add it to a web ACL directly in the AWS WAF console through AWS Marketplace, with no additional configuration. Both rule groups support versioning, and pricing is set by Miggo through AWS Marketplace. To get started, visit the AWS WAF console or find the Miggo rule groups in AWS Marketplace. For more information, see the AWS WAF Developer Guide. For a full list of supported Regions, visit the AWS Regional Services page.
Quelle: aws.amazon.com

Amazon ECR now supports image layers up to 200 GB

Amazon Elastic Container Registry (Amazon ECR) has increased the maximum image layer size limit to 200 GB, for images pushed via Docker push.
Previously, packaging assets required splitting data across multiple layers or offloading to external storage systems. With this update, customers can store up to 200 GB in a single image layer, eliminating extra complexity for use cases like embedding large language models, bundling genomics datasets, or packaging large binary dependencies directly into your container images. Images pushed using the AWS SDK or CLI; (UploadLayerPartAPI) remain limited to 50 GB.
This feature is available in all AWS Regions and partitions where Amazon ECR is available except the Middle East (Bahrain) and Middle East (UAE) Regions. To learn more, visit the Amazon ECR product page and refer to the Amazon ECR User Guide. For pricing information, see the Amazon ECR pricing page.
Quelle: aws.amazon.com

AWS Config now supports 15 new resource types

AWS Config now supports 15 additional AWS resource types across key services including Amazon Bedrock,  Amazon OpenSearch Serverless, and Amazon SageMaker. This expansion provides greater coverage over your AWS environment, enabling you to more effectively discover, assess, audit, and remediate an even broader range of resources. With this launch, if you have enabled recording for all resource types, then AWS Config will automatically track these new additions. The newly supported resource types are also available in Config rules and Config aggregators. You can now use AWS Config to monitor the following newly supported resource types in all AWS Regions where the resources are available: Resource Types:

AWS::AppSync::DomainName
AWS::OpenSearchServerless::AccessPolicy

AWS::Bedrock::AutomatedReasoningPolicy
AWS::OpenSearchServerless::LifecyclePolicy

AWS::Bedrock::AutomatedReasoningPolicyVersion
AWS::SageMaker::ImageVersion

AWS::Bedrock::Blueprint
AWS::SageMaker::InferenceComponent

AWS::Bedrock::DataAutomationProject
AWS::SageMaker::PartnerApp

AWS::BedrockAgentCore::ApiKeyCredentialProvider
AWS::SageMaker::Project

AWS::Connect::UserHierarchyGroup
AWS::SageMaker::Space

AWS::Glue::Trigger

Quelle: aws.amazon.com