{"id":15964,"date":"2026-03-17T07:06:22","date_gmt":"2026-03-17T07:06:22","guid":{"rendered":"https:\/\/newestek.com\/?p=15964"},"modified":"2026-03-17T07:06:22","modified_gmt":"2026-03-17T07:06:22","slug":"runtime-the-new-frontier-of-ai-agent-security","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=15964","title":{"rendered":"Runtime: The new frontier of AI agent security"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

AI agents are already operating inside enterprise networks, quietly doing some of the work employees once handled themselves \u2014 writing code, drafting emails, retrieving files, and connecting to internal systems.<\/p>\n

Sometimes they also make costly mistakes.<\/p>\n

At Meta, an employee asked an AI assistant<\/a> to help manage her inbox. It deleted it instead. At Amazon, an internal agent autonomously decided<\/a> to tear down and rebuild a deployment environment, knocking an AWS service offline for 13 hours.<\/p>\n

These incidents offer glimpses of a larger shift security leaders are confronting: Autonomous software is now acting inside corporate environments with real permissions and real consequences.<\/p>\n

\u201cAgents are like teenagers,\u201d Joe Sullivan<\/a>, former chief security officer of Uber, Cloudflare, and Facebook, and now head of Joe Sullivan Security, tells CSO. \u201cThey have all the access and none of the judgment.\u201d<\/p>\n

For years, most efforts to secure AI have focused on prevention<\/a> \u2014 scanning models, filtering prompts, and analyzing AI-generated code before it reaches production. But as enterprises deploy autonomous agents that interact directly with internal systems, some security leaders say the real risk begins only after those agents are live<\/a>.<\/p>\n

\u201cIn security, we always assume prevention will fail,\u201d Sullivan says. \u201cThat\u2019s why detection and monitoring are equally important.\u201d<\/p>\n

The speed and autonomy of AI agents mean mistakes or unexpected actions can cascade quickly across systems. That dynamic is why a growing number of security leaders are rallying around, at least conceptually, what Sullivan calls runtime security<\/a>, or continuously monitoring agents as they operate inside enterprise environments.<\/p>\n

In simple terms, runtime security focuses on what software does while it is running, rather than only evaluating it before deployment.<\/p>\n

Why agents change the security model<\/p>\n

CISOs have spent years governing human behavior inside enterprise networks. They have identity management, role-based access controls, user behavior analytics, and endpoint detection tools.<\/p>\n

The question is whether those same frameworks \u2014 and those same tools for tracking employees \u2014 can be extended to AI agents<\/a>. Security leaders studying the problem say the answer is: only partially. The traditional frameworks still apply conceptually, but the mechanisms required to observe agent behavior are fundamentally different.<\/p>\n

\u201cThe what isn\u2019t new \u2014 the how is new,\u201d says Hanah-Marie Darley<\/a>, co-founder and chief AI officer of Geordie AI. \u201cHow do you actually get this data, where you actually get the agent\u2019s behavioral information mostly through logs, and not every AI agent platform will mean that you are getting logs, that you have logs in the first place.\u201d<\/p>\n

Traditional security tools were built to intercept human behavior at perimeter checkpoints where employees access the internet, log into systems, or move data across boundaries. Agents frequently bypass those checkpoints entirely. They operate through API calls and MCP connections<\/a> that may never pass through the security tooling that would ordinarily flag anomalous behavior<\/a>.<\/p>\n

They also generate dramatically more activity. Where a typical employee might produce 50 to 100 log events in a two-hour period, an agent can generate 10 to 20 times that volume in the same window. And \u2014 critically \u2014 they often don\u2019t produce any logs.<\/p>\n

Some agent platforms generate robust audit trails by default. Others don\u2019t. Coding agents can overwrite their own session logs when a previous session is replayed, meaning a security team investigating an incident may find the record of what happened has been erased.<\/p>\n

\u201cHaving the logs in the first place is often a bigger step than people realize because not every agent natively has logs,\u201d Darley tells CSO.<\/p>\n

The inventory problem<\/h2>\n

Before a CISO can monitor what agents are doing, they face a more elemental challenge: knowing which agents exist.<\/p>\n

This simple idea is harder than it sounds. In many large enterprises, agents are proliferating faster than any central inventory can capture. Marketing teams deploy AI assistants. HR departments use agents for resume screening. Engineers run coding agents with broad filesystem access. Non-technical employees connect AI productivity tools such as note-takers<\/a>, email managers, and scheduling assistants to corporate accounts, often without formal IT approval.<\/p>\n

\u201cCISOs right now are getting the hard question from their board and their CEO,\u201d Sullivan says. \u201cWhat AI is being run inside the company right now? You\u2019ve got to answer that question. What AI is being run, and what\u2019s it doing?\u201d<\/p>\n

Darley recommends starting with a structured inventory effort, ideally using tools built specifically for agent discovery, since general-purpose application management systems often can\u2019t see agents living in the cloud, in code repositories, or inside third-party SaaS platforms.<\/p>\n

\u201cStart with at least one system,\u201d she advises. \u201cIt will give you a sense of scale, help you understand who the owners are, and start to educate you on the kind of tooling you actually need.\u201d<\/p>\n

Without inventory, behavioral monitoring has nothing to which it can anchor. Security teams can watch the logs of the agents they know about. But the agents they have missed are precisely the ones most likely to deliver unwelcome consequences.<\/p>\n

What runtime monitoring looks like<\/h2>\n

Once an organization knows where its agents are, the question is what to watch for \u2014 and how.<\/p>\n

Elia Zaitsev<\/a>, CTO of CrowdStrike, tells CSO that existing endpoint detection and response (EDR) tools<\/a> already capture the kinds of behavior needed to track AI agents. They instrument operating systems like a flight data recorder, recording every application that runs, every file it touches, every network connection it makes, and every command it spawns.<\/p>\n

CrowdStrike\u2019s EDR, for example, builds a threat graph: a connected map of behaviors and their upstream causes. If a suspicious network connection occurs, the threat graph can trace it back through many degrees of separation to the application or agent that initiated the chain.<\/p>\n

\u201cEDR technology can associate this end behavior with the fact that it came from an application ultimately being driven by an agentic system,\u201d Zaitsev explains. \u201cA firewall just tells you something on this computer is trying to communicate with an AI model in the cloud. EDR allows you to say: This specific application is talking to this specific model.\u201d<\/p>\n

For AI agents specifically, this creates a new set of controls. A system that recognizes a known agent application \u2014 Claude Code, OpenAI\u2019s Codex, OpenHands \u2014 can apply a different policy to that application than it would to the same application running under human control. \u201cThere are activities that may be benign if a human is responsible,\u201d Zaitsev says, \u201cbut if it\u2019s an AI agent I don\u2019t necessarily trust, I may want to apply different policies on the fly.\u201d<\/p>\n

Build-time security still has a pivotal role to play<\/h2>\n

Not all enterprises will be solely introducing AI agents off the shelf. Many will be building such systems themselves.<\/p>\n

Because of this, runtime monitoring does not mean that build-time security \u2014 scanning code, evaluating models before deployment, and checking prompts \u2014 is yesterday\u2019s problem. Varun Badhwar<\/a>, CEO of Endor Labs, pushes back on that kind of framing.<\/p>\n

\u201cI\u2019ll never say runtime isn\u2019t important,\u201d Badhwar tells CSO. \u201cBut you want to fix as much as you can early. The average cost of a runtime security finding is $4,000, versus $40 at build time. So, guess what? You want to fix as much as you can before it ever gets there.\u201d<\/p>\n

A vulnerability caught while a developer is still writing code takes minutes to fix. That same vulnerability, once deployed into a container, run through QA, and pushed to a production environment, requires retracing every step of that journey before it can be addressed \u2014 at roughly a hundredfold the cost. Badhwar uses the analogy of a car manufacturing line: Quality controls on the assembly line are always cheaper than recalling 70,000 cars from the street.<\/p>\n

His framework is simple: Shift left, shield right. Shift as many security controls as possible into the development process \u2014 catch problems while agents are being built, not after they\u2019re running. Then shield right with runtime monitoring as your last-mile safety net, because some things will always slip through, and zero-day vulnerabilities by definition can\u2019t be anticipated at build time.<\/p>\n

What CISOs should do now<\/h2>\n

For CISOs, the shift is less about a single new tool and more about a new way of thinking about AI risk. Instead of focusing solely on how agents are built, security teams increasingly need visibility into how they behave once they begin operating inside enterprise systems.<\/p>\n

The path forward for CISOs is therefore not a single new product or a rip-and-replace of existing infrastructure. It is a methodical extension of security discipline to a new category of actor inside the enterprise.<\/p>\n

Zaitsev frames it using the security-in-depth model: You don\u2019t stop securing agents at build time just because runtime monitoring is available. You build both. \u201cEDR and runtime security is that last-level safety net,\u201d he says. \u201cYou still want all those other layers.\u201d<\/p>\n

But the experts say the following starting points could be practical first steps toward implementing runtime security for most CISOs:<\/p>\n

Build an inventory first.<\/strong> Pick one system \u2014 a major SaaS platform, your code repositories, your endpoint fleet \u2014 and map the agents operating within it. Identify the owners, the permissions, and the protocols. Without visibility, nothing else is possible.<\/p>\n

Extend behavioral monitoring to agents.<\/strong> Whether through EDR, dedicated agent security tooling, or a combination, establish what normal looks like. What systems should each agent touch? What data should it process? Who should it communicate with? Deviations from that baseline are your signal.<\/p>\n

Apply agent-specific policies.<\/strong> Don\u2019t govern agents with the same controls you use for employees. They have different access patterns, different risk profiles, and different failure modes. Agent-aware tools can differentiate policy based on whether an application is AI-driven.<\/p>\n

Design for incident response before you need it.<\/strong> Know how you\u2019ll stop a misbehaving agent without destroying the evidence of what it did. Behavioral logs need to be captured in separate, write-protected stores \u2014 not just in the agent platform\u2019s native logging, which may be overwritten.<\/p>\n

Plan for AI solutions to AI problems.<\/strong> You won\u2019t hire your way out of the volume challenge. Security teams will need automation to monitor systems that operate at machine speed.<\/p>\n

See also:<\/strong><\/p>\n