Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Two weeks ago, we published the Agent Baseline alongside Docker and Keycard. In it, we describe six security outcomes, 35 controls, and an open reference architecture for running AI agents at the enterprise level. Last week, we stress-tested it: we took it to a panel at Black Hat and spent about one hour being asked hard questions about it. Play Video: Snyk x Docker x Keycard | Agent Baseline Panel @ Black Hat 2026 The most useful question came from someone who had actually already read it.

Many observability platforms authenticate to Microsoft Azure by using client secrets. Teams must create, store, and periodically rotate these secrets to keep receiving the telemetry data that they need. This recurring maintenance adds operational overhead and increases the risk of ingestion outages that occur when secrets expire.

Building a DLP strategy has two failure modes. The first is skipping the planning and going straight to deploying a tool. The second is over-planning and never actually deploying anything. These 10 Data Loss Prevention Best Practices cover the full arc. From picking the right DLP tool, setting up your program properly, and keeping it from drifting once it's live. Teams that get DLP right tend to follow roughly the same best practices.

Your data leaks in ways you don't expect. A developer pastes source code into ChatGPT. A finance employee emails a payroll spreadsheet to a personal inbox. A salesperson uploads a client list to a personal Google Drive before their last day. All of these are breaches, rather, potential breaches. That's exactly why data loss prevention (DLP) tools exist. But picking the right one? That's where it gets complicated.

To detect and govern shadow AI, organizations need to discover which AI tools employees are using, understand who is using them and why, then turn that visibility into an enforceable AI app policy. The goal is not only to find unsanctioned AI use, but to control which GenAI and AI-enabled apps are allowed, blocked or monitored across the organization.

Every security architecture review this year eventually lands on the same question: does the existing data security stack already cover AI, or does AI security need its own budget line? The instinct to treat this as one more tool to evaluate and buy is understandable. It is also the wrong framework for modern data security. Traditional data security and AI security answer different questions about the same data. One assumes data stays inside known applications and moves through known channels.

Autonomy breaks traditional security operations workflows because AI agents can act continuously and independently inside approved environments. When activity is initiated and executed without a human in the loop, event-by-event review and short correlation windows fail to capture progression, intent, and accumulated risk.

Veracode I have been going to Black Hat for more than 25 years, and I have spent many of those years on the Review Board. New technologies keep changing the shape of the systems we secure. The questions I find myself asking stay remarkably familiar. Where does untrusted data enter? What authority does a component have? Which boundary controls a sensitive operation? How do we know that control worked?