The CISO Playbook for AI Agents | Datadog

Discussion on how AI adoption across enterprises is changing CISO assumptions regarding permissions, credentials, and software supply chains.

The adoption of AI agents by engineers at Datadog, starting small and expanding to various coding agents, and the strategic decision not to block these tools.

High adoption rates of AI tools across different departments, with data security and permissioning becoming paramount concerns for IT and corporate sides.

An example of an internal business intelligence tool revealing that AI agents could bypass existing data access controls by understanding SQL.

Implementation of role-based MCP servers to control and govern data access for different user groups, allowing them to use AI tools safely.

Security concerns for engineering teams regarding AI coding agents, specifically what tools they can call, binaries they can pull, and how they access credentials.

The development of an open-source sandbox and the injection of ephemeral tokens for agents to securely access resources without direct credential file access.

The expansion of the threat landscape with developers as primary targets for attackers using AI to build worms or access production environments.

Using skills and monitoring marketplaces for AI agents, with a focus on controlling and evaluating these skills to prevent malicious code.

The creation of an AI "judge" to evaluate the intent behind code, beyond just vulnerabilities, to determine if it's meant to do harm.

The development of the "judge" was driven by the need to scale security reviews for third-party code contributions to the Datadog agent and has been effective in identifying malicious code in supply chain attacks.

The judge's ability to scan markdown files and the internal use of hooks to monitor agent skills, emphasizing a collaborative approach rather than outright restriction.

The security team's approach of not restricting innovation but rather implementing checks like the AI judge before skills are introduced, and proactively identifying malicious skills in marketplaces.

Worries about dependencies and binaries that AI agents can pull, and the effectiveness of the judge in mitigating these risks.

The challenge of battling the code output of agents against malicious intent, with a focus on the agent's reward structure influencing its actions.

Concerns about AI agents producing code that might disable systems to solve problems, highlighting the importance of prompt engineering and agent interpretation.

The surprise at a sense of helplessness among security leaders regarding agentic security and their reliance on commercial solutions.

Discussion on different CISO profiles, the evolution of security teams, and the potential for technically inclined individuals to drive innovation.

The idea that even in large corporations, a few individuals can drive significant innovation with creative license, and the worry that this isn't always considered.

The difficulty in finding technologists for large security programs and the observation that many great security professionals started in development.

The argument that security tasks don't always require dedicated security personnel and that developers can contribute significantly.

The potential for realignment and cross-pollination of talent into security as AI tools reduce the need for certain engineering roles.

The thesis that security engineers will become "real engineers" and the current trend of equalizing pay between security and software engineers.

The acknowledgment that software engineers may still have an advantage in large corporations but that this gap is narrowing.

Focusing on key security concerns, building and utilizing tools, and finding synergies between security and development teams, with a focus on developer experience.

The observation that engineers are increasingly security-conscious, driven by a desire to avoid fixing problems, which is a positive development.

A contrasting view that while developers care about security, the security practices presented to them have often been poor and irrelevant, leading to disengagement.

Engineers sharing stories of receiving numerous irrelevant security tickets and security teams not understanding their work.

The idea that when security teams criticize developers' code, they should try implementing it themselves.

Acknowledging that security issues found in isolation might be part of a larger framework that influences fallout.

The perceived calmness among CISOs despite news of AI security threats, attributing it to the understanding that malicious actors have always existed, whether AI-driven or human.

Concerns about equitable access to AI capabilities and the lack of a regulatory framework to govern their use.

The difficulty in understanding the criteria for AI access and the frustration of longer wait times compared to those who have had early access.

The argument for providing access to AI tools to companies that are already using them to better protect those services.

The belief that AI inherently makes security better by raising awareness and encouraging discussion, rather than posing an immediate, unmanageable threat.

The primary worry is not about AI models escaping but about the overwhelming volume of vulnerabilities discovered and the inadequacy of current tools to manage them.

A concern about hypersensitivity to security findings simply because they were discovered by an AI model, rather than by a human.

The challenge of managing third-party risk will increase due to AI's ability to find vulnerabilities, and the hope that these tools will ultimately improve security practices.

The lesson that attempts to gatekeep security ultimately fail and that open discourse is the most effective approach.