Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

In previous Strategic CISOs sessions, I’ve spoken with security leaders from Andesite, IMO Health, and Cribl. They’ve built trusted programs where GRC functions as a business driver and customer assurance accelerates revenue. But every CISO I speak with is still fighting some version of the same fight. They have more obligations, more scrutiny, and more AI-related risk, but they do not have more people, more budget, or more hours in the day.

There’s a conversation happening in boardrooms, security operations centers, and developer standups that I find both thrilling and concerning: the conversation about AI-assisted development. Engineering teams are shipping features in hours that once took months. Products that would have required six-month roadmaps are being prototyped in a weekend.

Security and GRC teams have no shortage of risk mitigation activities. They are carrying more work than ever, yet many still lack confidence in the data and recommendations produced by all that manual effort. They are also operating in a risk environment that changes faster than their current operating model was designed to support. Unfortunately, the existence of risk activity does not mean actual risk has been reduced.

Your AI agents had a productive day. Nobody can tell you what data they touched. A developer opens Cursor and connects it to a GitHub MCP server and a Postgres MCP server. The agent reads the repo to understand a schema change, finds an AWS access key in a config file, and uses it to run a migration against staging. The key now lives in the agent's context, in the Postgres query log, in the chat history, and in whatever artifact the developer copies out. No alert fired. No policy triggered.