AI Agents Break Enterprise Security Playbook as 54% of Organizations Report Incidents

AI Agents Broke the Security Playbook. Here's What Replaces It.

For most of the last two decades, enterprise security ran on a workable assumption: the environment was knowable. Security teams could buy tools, inventory users, map systems, define policies, and rely on vendor-built dashboards and workflows to manage most of what happened next. The model was imperfect, but it worked because the environment changed at human speed. AI agents broke that assumption, and with it, the playbook. Agents are not ordinary applications. They act autonomously, invoke tools, acquire access across systems, and change behavior based on context. Some are sanctioned and run in SaaS platforms. Others are unsanctioned and run locally. They can borrow human access and disappear before the next inventory scan. They also vary enormously in what they can reach; Token Security research on how enterprises are actually deploying agents found everything from human-triggered chatbots to autonomous production services, with more than a fifth of local agents already holding direct access to production data sources. The build-vs-buy conversation in cybersecurity has now fundamentally changed. The old question was simple: should we buy a tool or build one ourselves? In the agentic era, that framing is too narrow. Security teams do not need to rebuild the entire stack, but also can't rely on fixed workflows someone else created months earlier. The better question is: which layer should security teams own? The Limits of Fixed Security Workflows AI agents make environments more specific, more dynamic, and harder to anticipate. A vendor can build a dashboard for common risks: overprivileged service accounts, stale credentials, dormant admin users, excessive permissions, and identities with access to production systems. That is useful, but the most important questions are often specific to a single environment. * Which agents created in the past two weeks can reach production through inherited human credentials? * Which local coding agents still have active tokens after a project ended? * What is a potential attack path from one system to another using AI agents? These questions do not fit neatly into a generic workflow. They depend on the organization's cloud footprint, SaaS stack, development practices, ownership model, compliance requirements, and AI adoption patterns. No vendor roadmap can anticipate every combination. That is the operationalization gap. Security teams can often identify risk categories, but they cannot always translate them into the exact remediation path their environment requires. AI agents widen this gap because they move faster than traditional tooling cycles. Waiting two quarters for a vendor feature while agents continue accumulating access is not an effective security strategy. It is a queue. Why "Just Build It" Is Not the Answer AI-assisted development has changed what teams can build. Retool's 2026 Build vs. Buy report found that 35% of teams had already replaced at least one SaaS tool with something they built themselves, and 78% expected to build more this year. This trend has real security implications, since AI has made building custom tools far faster and easier. Work that once took weeks of engineering can now be prototyped in hours. But cybersecurity has a harder problem than most business functions: the data layer. A useful security workflow is only as good as the identity, access, permission, ownership, and activity data underneath it. Building a custom app is one thing. Connecting it safely to live enterprise systems is another. Security teams should not have to rebuild integrations across AWS, Azure, GitHub, Salesforce, Okta, secret managers, CI/CD pipelines, SaaS platforms, agent frameworks, and on-prem systems. They should not have to normalize every schema themselves or maintain fragile scripts that break when an upstream API changes. That is the hidden cost of "just build it." The hard part is not generating code but building on data that is live, normalized, secure, and complete enough to support real decisions. Buy the Foundation to Own the Operational Layer The future of cybersecurity is not pure build or pure buy. It is building on the right foundation. Security teams should invest in the layers that are structurally complex and widely adopted across organizations: continuous discovery, integrations, normalization, identity correlation, access mapping, governance controls, auditability, and secure execution boundaries. Those capabilities require depth, scale, and constant maintenance. They are not where most security teams should spend their scarce engineering time. But teams should own the operational layer: the workflows, applications, reports, reviews, and automations that reflect their specific environment. That is where differentiation lives. That is where security teams encode how their organization actually works: who owns which agents, which systems matter most, what access is acceptable, which exceptions are allowed, how risk is prioritized, and what remediation should happen next. The winning model is not "buy everything" or "build everything." It is "buy the foundation, build the operating layer." Identity is the layer that holds For AI agents, the foundation has to be identity. Every meaningful agent eventually requires access. It authenticates, uses credentials, invokes tools, and reaches data. Often, it does not even have an identity of its own and instead borrows one from an employee, which is why the agents already running within enterprises can be indistinguishable from the people they impersonate in your audit logs. That is why identity is the only control plane that actually governs agentic AI, and why it is the foundation on which to build. It is the one place your team can see and enforce discovery, ownership, access, and lifecycle for every agent at once. Guardrails, prompt filtering, and behavior controls act on what an agent says. Identity governs what an agent can reach, and reach is what determines blast radius. A live identity foundation gives security teams the context they need to ask and answer the questions that matter: * Who owns this agent? * What is it supposed to do? * Which identities does it use? * What systems can it reach? * Does its access match its intent? * What happens when it is abandoned, compromised, or changed? Without that foundation, custom workflows sit on sand. They rely on stale exports, partial inventories, and one-off scripts. With it, security teams can build operational logic that stays connected to the real environment as agents appear, change, and disappear. The teams that stay effective The security playbook built for a knowable environment is not coming back. AI agents made sure of that. The next playbook is more adaptive. It assumes the environment will keep changing. It assumes no vendor can prebuild every workflow. It assumes security teams need the ability to compose controls, reports, reviews, and remediation paths that fit their own reality. But it also recognizes that teams should not rebuild the foundation themselves. The teams that stay ahead will not be the ones with the longest tool list or the most generic dashboards. They will be the ones who know which layer to own. For agentic AI, the answer is clear: build on a live identity foundation and own the operational layer that must adapt. In the agent era, that is how security teams move fast without losing control. If you're looking to secure your agentic AI, book a quick technical demo with Token Security to see how they can secure your organization as you scale.

The agent security gap: 54% of enterprises have already had an AI agent incident, and most still let agents share credentials

Across 107 enterprises, AI agents are being given real access to systems and data while the controls meant to contain them lag behind. More than half have already had a confirmed agent security incident or a near-miss; only about a third give every agent its own scoped identity, and most agents still share credentials; and only three in ten isolate their highest-risk agents. The security stack is overwhelmingly borrowed from the model providers and hyperscalers rather than purpose-built for agents, spending remains a thin slice of the security budget, and enterprises are evenly split on whether their defenses are keeping pace with AI-enabled attackers. The result is an agent security gap -- autonomous agents proliferating faster than the identity, isolation, and enforcement controls needed to hold them. This wave of VentureBeat Pulse Research examines how enterprises secure their AI agents: what tooling they run, how they manage agent identity and isolation, what has already gone wrong, how much they spend, and whether they believe their defenses are keeping pace with AI-enabled attackers. The central finding is an agent security gap -- the distance between the autonomy enterprises are granting their agents and the controls in place to contain them. More than half of organizations (54%) have already experienced a confirmed agent security incident (18%) or a near-miss caught before harm (36%). The structural weakness beneath those numbers is identity: only about a third (32%) give every agent its own scoped, managed identity, while the rest report that some agents share credentials or that agents mostly run on shared API keys and human or service-account credentials. When agents share credentials, a single compromised or over-permissioned agent carries a wide blast radius -- and only three in ten enterprises (30%) isolate their highest-risk agents in sandboxes to bound that radius. What makes the gap notable is how comfortable enterprises are inside it. The security stack is overwhelmingly provider-native -- OpenAI's guardrails (51%), Google's and Microsoft's cloud controls, and Anthropic's managed-agent controls dominate, while the dedicated agent-security specialists barely register -- and satisfaction with that borrowed stack is high, averaging 4.2 out of 5. Yet spending remains a thin slice of the security budget, only a third of enterprises believe their AI defenses are ahead of AI-enabled attackers, and a clear majority plan to change tooling within the year. Enterprises are satisfied with controls they are simultaneously preparing to replace. Methodology VentureBeat fielded this survey as part of its ongoing Pulse Research series, this instrument focused on enterprise agent security -- the tooling, identity, isolation, and enforcement controls organizations use to secure autonomous AI agents. Responses are filtered to organizations with more than 100 employees (n=107; the survey's smallest size band, 1-100 employees, is excluded), drawn from a single June 2026 wave. Because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends. Several questions were multiple-select, so those shares can sum to more than 100%. By role the sample is senior and buyer-credible: 45% are final decision-makers for AI purchases and another 30% recommenders or influencers. Managers (43%), individual contributors (24%), VPs and directors (15%), and the C-suite (11%) make up the seniority mix. By organization size the sample is mid-market-weighted: 251-1,000 (42%) and 101-250 (25%) employees lead, with 1,001-5,000 (19%), 5,001-10,000 (8%), and 10,001+ (7%) above them. Technology/Software is the largest industry at 23%, followed by Manufacturing (15%), Retail/E-commerce (14%), and Healthcare/Life Sciences (13%). At 107 respondents the sample is large enough to read directionally but should be treated as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It skews toward the mid-market, so it is best read as the view from organizations actively standing up agent security rather than from the largest operators. Satisfaction ratings are computed on the respondents who answered each rating question; the overall satisfaction score reflects 82 of the 107 qualified respondents. Finding 1: The incidents are already here More than half have had an agent security incident or near-miss We asked whether organizations had experienced an agent security incident -- a confirmed breach, or a near-miss caught before harm. Most that run agents in production had. This is the report's defining number. More than half of organizations (54%) have already had an agent security event -- 18% a confirmed incident and 36% a near-miss caught before it caused harm. Only 42% report nothing, and a small remainder either run no agents in production or don't track such events. That so many report near-misses rather than only confirmed incidents is telling: enterprises are catching problems, but they are catching them close to the edge. The controls examined in the rest of this report -- identity, isolation, enforcement -- are what determine whether the next near-miss stays a near-miss. Exposure scales with company size, but containment does not. The incident-or-near-miss rate rises from 49% in the mid-market (companies with 101-1,000 employees) to 63% at larger enterprises (above 1,000 employees), while sandbox isolation of high-risk agents falls from 35% to 20%, and satisfaction with security tooling drops from 4.36 to 3.97. The organizations running the most agents across the most systems carry the most incidents and the least of the one control that bounds an incident's blast radius. Finding 2: The identity gap Only a third give every agent its own scoped identity We asked how enterprises manage the identity of their AI agents -- whether each agent has its own credentials, or agents share them. Full per-agent identity is the exception. Rolled together, the overlapping answers show 69% of enterprises (74 of 107) with credential sharing somewhere in the agent fleet. Identity is the structural weakness beneath the incidents. Only about a third of enterprises (32%) give every agent its own scoped, managed identity -- the precondition for least-privilege access and clean attribution. Nearly half (48%) say some agents have scoped identities but many still share credentials, and another 32% say agents mostly run on shared API keys or borrowed human and service-account credentials. (Respondents could describe more than one pattern across their agent fleet, so these overlap.) The consequence is direct: when agents share credentials, an over-permissioned or compromised agent can act with far more reach than intended, and forensics after an incident cannot cleanly tell which agent did what. The non-human identity problem -- giving every agent its own governed identity -- is the single largest unfinished piece of enterprise agent security. Moreover, a company's agent credential posture is correlated with incidents. Organizations with credential sharing anywhere in the fleet were hit -- with an incident or a near-miss in the past twelve months -- at 63.5% (47 of 74). Organizations where every agent carries its own scoped identity were hit at 40.9% (9 of 22). The fully-scoped group is small, so for now the relationship is an association rather than proven causation, and the gap is concentrated in the mid-market -- but within a single survey, a twenty-three point difference in incident rate suggests significance. Finding 3: Observe and enforce, but rarely isolate Only three in 10 sandbox their highest-risk agents We asked what an organization's agent security posture looks like in practice -- whether they observe, enforce, isolate, or some combination. The control that bounds damage is the least common. Monitoring and enforcement are reasonably common; containment is not. Roughly half of enterprises observe agent activity (47%) or enforce scoped permissions at runtime (49%), but only 30% isolate their highest-risk agents in sandboxes that bound the blast radius when the other controls fail. That ordering is backwards from a defense-in-depth standpoint: observation tells you what happened, enforcement tries to prevent it, but isolation is what limits the damage when prevention fails -- and it is the control enterprises have adopted least. Combined with the identity gap in Finding 2, the picture is of agents that are watched and permissioned but rarely boxed in, which is precisely the configuration in which a single failure propagates. Finding 4: Security runs on borrowed, provider-native controls Guardrails from OpenAI, Google and Microsoft dominate; specialists barely register We asked which agent security tooling enterprises use, and which is their primary layer. The answer favors the model providers and hyperscalers over the dedicated security vendors. Enterprises are securing agents with tools that came bundled with their models and clouds. OpenAI's guardrails lead at 51%, followed by Google's and Microsoft's cloud-native controls and Anthropic's managed-agent controls -- and when asked to name their single primary security layer, 82% name one of these provider-native offerings. The purpose-built agent-security category -- Palo Alto's Prisma AIRS, CrowdStrike, Cisco AI Defense, Zenity, HiddenLayer, Check Point's Lakera, Okta for AI Agents, non-human identity platforms -- barely registers, each in the low single digits, and only 5% run no dedicated tooling at all. As with retrieval and evaluation elsewhere in this series, the provider bundle is winning the default: enterprises reach first for the guardrails their platform ships, and the independent security layer that would address the identity and isolation gaps has not yet been adopted at scale. The provider-default pattern is consistent across both Q2 survey waves. In April-May (n=110), usage was led by the same names -- OpenAI's controls at 26%, Azure at 15%, AWS at 14%, Google at 12% -- with every dedicated agent-security specialist at 3% or below and one in ten using no dedicated tooling at all. The common finding from the two surveys: Enterprises are defaulting to the solutions provided by the platform they're using, and the specialist category vendors have yet to become big players here. (A note on reading these shares. As described in the methodology section, the respondent sample is self-selected and skews mid-market, and the usage question counted every vendor or approach a respondent has in place -- so the figures measure presence in the security stack rather than spending or exclusivity. Individual vendor percentages therefore carry all the usual sample caveats. The structural pattern, however, held across both Q2 waves on two differently worded questions: provider-native and hyperscaler controls lead, and dedicated agent-security specialists remain in low single digits. Read the individual shares loosely and the pattern with confidence.) Finding 5: And enterprises are comfortable with it Satisfaction is high, even as incidents mount and identity lags We asked how satisfied enterprises are with their current agent security tooling. The comfort is notably out of step with the exposure documented above. Satisfaction with agent security tooling is high -- 4.2 out of 5 overall, and 4.1 for value for money -- among the most positive readings in this series. That is the striking part: enterprises are highly satisfied with a stack that is mostly borrowed provider guardrails, even though more than half have already had an incident or near-miss and only a third give their agents scoped identities. The comfort appears to rest on the convenience and low friction of provider-native controls rather than on demonstrated containment. It is a false comfort in the making -- the same enterprises expressing satisfaction are, as Finding 8 shows, a clear majority planning to change tooling within the year, which suggests the confidence is thinner than the score implies. Finding 6: Budgets haven't caught up Most spend under a tenth of the security budget on agents We asked what share of the security budget enterprises allocate to securing AI agents. For a fast-emerging risk, the allocation is modest. Spending on agent security is still a thin slice. The most common allocation is 6-10% of the security budget (46%), and a third of enterprises (34%) spend 5% or less; only a quarter (24%) devote more than a tenth. Given the incident rate in Finding 1 and the identity and isolation gaps in Findings 2 and 3, the budget looks like a lagging indicator -- the risk has arrived faster than the funding to address it. The enterprises spending more than a tenth of their security budget on agents are a distinct minority, and they are likely the ones building the scoped-identity and isolation controls the rest have not. Only a third think their AI defenses are ahead of AI-enabled attackers We asked how enterprises assess the balance between their AI-enabled defenses and AI-enabled attackers. Confidence is far from settled. Enterprises are split on whether they are winning. Only about a third (35%) believe their AI-enabled defenses are ahead of AI-enabled attackers; the rest are less sure -- 32% call it roughly even, 21% think attackers are ahead, and another 21% say it is too early to tell. Taken together, a clear majority (53%) rate the balance as even or tilted toward the attacker. That uncertainty sits uneasily beside the high satisfaction of Finding 5: enterprises are content with their tooling yet unconvinced it is winning the contest it exists to win. In a domain where the offense is also compounding with AI, an even race is not a comfortable place to be. Finding 8: A security reshuffle is coming Nearly six in 10 plan to adopt or switch tooling within a year We asked whether enterprises plan to adopt a new, additional, or replacement agent security solution, and which they are considering. Few intend to stand pat. The security stack is not settled. While 41% have no plans to change, a clear majority (59%) intend to adopt a new, additional, or replacement agent security solution within twelve months, and 29% within the next quarter -- a strong signal that, high satisfaction notwithstanding, enterprises know the current stack is provisional. Incidents are what start the buying cycle. Among organizations that have been hit, 42.1% plan to adopt, add, or replace agent security tooling within the next ninety days, against 14.0% of organizations with no incident -- and after a confirmed incident it becomes majority behavior, at 52.6%. Getting hit also changes the threat assessment: 33.3% of hit organizations say AI-armed attackers are ahead of their defenses, against 8.0% of the unhit. Experience, in this data, is the strongest predictor of both urgency and pessimism. The consideration set still leans provider-native (OpenAI 34%, Google 30%, Anthropic 29%, Azure 25%), but the dedicated security vendors -- Cloudflare, Cisco, Palo Alto, Okta, Check Point's Lakera -- draw early interest in the mid-to-high single digits, more than their current footprint. What the shopping does not yet include is the identity layer specifically. Twelve percent of the respondents include an agent-identity product -- Okta for AI Agents, Microsoft Entra Agent ID, or a non-human identity platform -- anywhere in their consideration set, and among the credential-sharing organizations that have already had an incident, identity consideration is essentially unchanged, at roughly one in ten. The control most directly implicated by the incident data is the one largely missing from the purchase plans. Whether this wave hardens the provider-native default or finally opens the door to purpose-built agent security -- the identity and isolation controls the incidents call for -- is the question this series will keep tracking. The bottom line: A security gap that autonomy will test first Organizations with more than 100 employees are giving AI agents real reach into systems and data while securing them with controls built for something else. More than half have already had an incident or near-miss; only a third give every agent its own scoped identity, and most still share credentials; only three in ten isolate their highest-risk agents; and the stack doing this work is overwhelmingly borrowed from the model providers and hyperscalers rather than purpose-built for agents. The uncomfortable pairing is confidence with exposure: satisfaction with the current tooling is among the highest in this series, yet spending is a thin slice of the security budget, only a third believe their defenses are ahead of AI-enabled attackers, and a clear majority are already planning to replace what they have. At 107 respondents in a single wave this is a directional read, skewed toward the mid-market -- but the direction is clear: agent adoption is running ahead of agent security, and the controls that matter most when something fails -- scoped identity and isolation -- are the ones enterprises have built least. The agent security gap is not a coverage problem that a provider guardrail will close on its own; it is a problem of identity, isolation, and enforcement built for autonomous software. The open question for later waves is whether enterprises close it deliberately -- or whether a confirmed incident closes it for them.

Zero trust must now move at agent speed

Enterprises need to treat zero trust security architecture as an immediate requirement for AI agents rather than a long-term goal, says Andre Durand, CEO and founder of Ping Identity. Zero trust, the security model built on the assumption that no user, device, or system should be automatically trusted, requires continuous verification before every action rather than a single check at login. Agentic AI has profoundly compressed the risk timeline enterprises must manage, demanding that permission decisions be evaluated in real time. That compression shows up in how permissions accumulate. Every time an employee approves an AI agent's request for access to a company drive, a database, or a code repository, the enterprise hands over a sliver of control that looks routine in isolation. Across thousands of agents making thousands of requests, those approvals accumulate into an exposure that most existing security architectures were never built to measure. "The rise in desire to use agents right now, and the speed of agentic, is highlighting the need to move faster on the principles of zero trust," Durand says. "Agents just move faster, full stop. A human compromise might be measured in minutes or hours, sometimes days. At agentic speed, a thousand actions could happen in five minutes." Why zero trust is now urgent for agentic AI That difference in velocity changes how enterprises need to think about permissions. Two variables matter: the surface area of access an agent is granted and the duration that access remains valid. Traditional identity and access management tends to grant broad permissions and leave sessions open for extended periods because the human using them moves at human speed. Zero trust, in contrast, collapses both variables at once by narrowing access down to what is strictly necessary and revalidating it continuously, rather than once at login. "Zero trust really just says, just enough, just in time," Durand says. "It's your next action that we care about. We're moving identity from an era where access was our runtime control point -- meaning were you logged in, did you have a session -- toward the decision that sits behind that login." Why agents must be treated as first-class identities That shift to decision-based control has direct implications for how agents should be provisioned in the first place. The common practice of letting an agent operate under a cloned human login or a shared service account doesn't work, Durand says. "Each agent should have its own identity," he explains. "It should not be impersonating the human. It can act on behalf of the human, we could explicitly delegate authority to an agent, but we don't want to blur the lines between the human taking action and the agent taking action." And beyond that is another concern: the shared secrets, API keys in particular, that many service accounts still rely on. For example, the habit of embedding keys directly in source code, where they can be committed accidentally and exposed, is a convenient but weak security pattern that agentic workflows make considerably riskier. Building service account architectures that let agents authenticate without relying on those shared credentials or other long-lived standing access is now an urgent priority rather than a long-term cleanup project. Where enterprises can enforce zero trust policies Enforcing any of this in practice requires identifying where policy can actually be applied. Several existing choke points, including API gateways and the agent gateway sitting in front of MCP servers, offer practical locations where enterprises can inspect what an agent is requesting and apply policy rules before granting it. "Those policies could leverage real-time risk and fraud signals, and then enforce, deterministically, what the agent can do when it interacts with these systems," Durand explains. The goal is to move authorization from something decided once at login to something evaluated at the moment of every consequential action, such as an agent attempting to commit code to a repository. Instead of carrying a standing permission to write to GitHub, the agent's request would be checked against context and policy at that specific moment, closing the window of trust down to the scope of a single action. Stopping AI agents from rewriting their own permissions That model becomes especially important given how agents can behave once they are already inside a system -- for example, coding agents that have acknowledged, when questioned, either ignoring a specific guardrail entirely, or attempting to rewrite the permissions they were given. "Who's watching the watcher? Zero trust needs to apply here," Durand says. "If generative AI systems follow your instruction 97% of the time, and you're simply asking it for advice, that might be fine. If it's responsible for making a decision about who gets let in, 97% is not good enough." How to trust AI-generated output at agent speed The answer to that gap is not to eliminate AI from the review process, but to structure reviews so no single agent's judgment is taken at face value. Because human review cannot scale to the volume and speed of agentic output without erasing the advantage of using agents at all, a new framework is necessary, so that when one agent produces work, such as code, separate agents evaluate it, provided those reviewing agents are kept from communicating with one another or with the one they are checking. It's a new human-AI paradigm, Durand says. "We probably will have to develop frameworks that we trust without seeing or verifying the output directly," he explains. "It's not that that construct is 100% foolproof. However, it's the best we can do to move at agent speed. We can't trust the exact output, but we can trust the framework." In practice, that means combining automated review with clear human accountability for higher-risk decisions, rather than treating agent output as self-validating. For traditional auditors, reviewing every transaction individually is never feasible, and statistically valid sampling stands in for full verification. The same applies to risk accumulation: a single agent action might carry little risk on its own, while a sequence of actions moving in a consistent direction could cross a threshold that triggers an intervention, including a kill switch capable of halting the agent before further harm occurs. What to ask when evaluating agentic identity platforms For security leaders evaluating identity platforms for agentic AI, there's no narrow checklist. Enterprises should evaluate what their full lifecycle of agent management looks like. Most enterprises are managing agents on two fronts simultaneously: customer-facing agents acting on behalf of external users, and internal agents deployed to automate enterprise processes. "Pause long enough to see the totality of what it would mean to secure multiple agents, both interacting with you from the outside as well as being deployed on the inside," Durand says. "We need discovery and visibility of all the agents operating within our estate, a place to register them, a standard way to assign custodians, and a way to construct and centralize policy so security can enforce it across the organization." And while basic security principles were already fully understood before agentic AI arrived, what has changed, Durand says, is that the cost of moving slowly has finally caught up with the cost of moving carelessly, giving enterprises a narrowing window to build the right architecture before widespread agentic adoption makes retrofitting far more expensive. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they're always clearly marked. For more information, contact [email protected].

Why Agents Must Be Treated as First-Class Identities

The interview transcript below has been edited for length and clarity. Louis Columbus: Every enterprise identity architecture was built for humans. That assumption is breaking today, Agentic AI systems now request credentials, make privileged decisions, and operate without anyone in the loop. The identity layer these systems need doesn't exist yet. Someone has to build it. Andre Durand founded Ping Identity and has spent more than two decades defining how organizations authenticate and authorize at scale. He's not watching this shift from the sidelines. In this conversation, we dig into what headless identity operations actually look like in production and how agent governance works when machines hold the credentials and where this is all heading. Welcome, Andre, and it's a pleasure and honor to speak with you. Every time someone clicks yes on an agent's prompt permission, the agent gets a little bit more access to confidential data, as we're all seeing with, for example, with Claude or any other model will ask to access your Google Drive or anything else, and the enterprise is giving up a little bit more control. But this trade-off looks harmless until the moment it isn't. So why is zero trust the answer for the agentic enterprise, and why does it have to start on day one? Andre Durand: One of the main reasons is that agents just move faster, full stop. And so human speed, a compromise you might measure in minutes or hours, in some ki-- in sometimes days. In agentic speed, a thousand actions could happen in five minutes. It is a different order of magnitude of risk. What companies are now trying to navigate is we don't wanna give up speed, we don't wanna give up innovation, but we also don't wanna give up security and control, and we don't want to embed a future liability that could come back and haunt us as we grant too much permission, and we grant that permission for too long. So one is a measurement of surface area, and the other is a measurement of time. And zero trust really collapses both of those. Zero trust really just says, "Just enough, just in time." And really, it's your next action that we care about. And so really, we're moving in identity from an era where access was our runtime control point, meaning were you logged in? Did you have a session? And now we're moving towards the decision that sits behind that login or that that event. That is now becoming the unit of control that is appropriate for agents. Louis Columbus: Building on the permissions concept, today a lot of agents act on cloned human login and shared service accounts. Neither really fit. Under zero trust, what should an agent's identity be, and how does that change what it's allowed to do? Andre Durand: So there are appropriate security models that we need to adhere to here, and they are autonomous actors in the system. O-one of the things that this has now exposed is that agents acting on behalf of a human to achieve an outcome does need explicit authority to access systems, and some of those systems are workloads and service accounts and the security model that we've had there for some time, which was convenient but not the best security paradigm, is that many times to access those service accounts, we had these shared secrets, and the sh-shared secrets would get propagated around, think an API key. And at times it could be accidentally divulged. We would put an API key in something that we might commit in source code and unknowingly expose essentially a key to a door that could later on be exploited. And so building a better security model around those workloads and service accounts so that the agents could access those services, but do it in a in a much more secure manner is also something now that has been accelerated. Louis Columbus: You've mentioned before in our previous conversations about zero trust moves the gate beyond past login to the authorization decision itself, so the agent gets checked before every action it takes, not just at the door. How do you ensure that happens at scale in practice, and even taking on the challenges of fine-coded apps that are proliferating this today? Andre Durand: We start to look at where the doors are between the agents and the things that we ultimately want to gate, keep, or protect. And it turns out there are a number of choke points. For example, the API gateway is a choke point to APIs. Now the MCP gateway, or what we call the agent gateway, that sits in front of the MCP servers also can see agents requesting interaction with services and data. So we do have locations that we can begin to enforce policy. So if agents are going to do something, interact with our systems or our data, we now can begin to develop policies, appropriate policies. So we are finding all of the locations where agents exist, where we want them to either act autonomously or act on behalf of us, and and we are taking a good look at the resources that they want to access, and we are now just in the process of defining what policies and what gates sit between the agents and what they're doing so that we can begin to centralize that policy and enforce that policy. Louis Columbus: You began the conversation also talking about the speed of these agents and they could get thousands of directions at once, inflicting harm before any system or any other deterrent can actually find and stop it. How much of that can zero trust contain, and what must happen at runtime to catch the rest of these potential aberrations and, efforts of rogue agents to compromise API keys and secrets? Andre Durand: You can authenticate and you can have an account, meaning the agent can be known, the agent can be registered, the agent might have a custodian, for example. All of those things could be present. The agent could also have authenticated, but whether or not the agent can take the next action depends. And so we are evolving now, this whole security model now needs to evolve to decisions being the runtime control plane. And at a moment at which the agent attempts to, say, commit to GitHub some new source code, it's not like it has long-lived permissions to submit to GitHub. When it wants to submit to GitHub, all of the signals will be evaluated at runtime, and the policy will essentially be enforced as to what it could commit, how much it can commit, whether or not all the security checks and other checks have been done to the code prior to the commitment. Those are all contextual decisions that get evaluated at the moment at which the agent attempts to commit the code to GitHub. And that's a very much a zero trust principle, just enough just-in-time access where the decision or our policy sits between the agent and its next significant action. So we're gonna close the window of time that an agent can act down to literally its next action. Louis Columbus: The proliferation of identities across a single agent is an area that I'm specifically very interested in tracking. That leads us to the next question, which is the behavior of of rogue agents with valid credentials, authorized access, that rewrite policies to be able to fulfill their own goals. There have been case studies of that at Fortune 50 accounts, these agents actually rewriting policy documents. So how does zero trust shut this kind of activity down or this breach down where the agent's actually acting with intelligence to redefine its role and the parameters or the perimeter of its identity? Andre Durand: It's so fascinating, right? And by the way, I've personally experienced this. I've seen with some of my coding agents where upon inspection, it will acknowledge that it either ignored a specific guardrail, a specific permission that was granted, like it literally just ignored it. Or it will acknowledge that at one point in time it rewrote the permission And who's watching the watcher, so to speak, on that front? Again, zero trust needs to apply here. So if agentic, think the generative AI systems will follow your instruction 97% of the time, if you're simply asking it for some advice, that might be just fine. If it's actually responsible for making a decision as to who gets let in 97% is not good enough. And so zero trust here and verified trust, this is probably where they collide a little bit. We need to design our systems such that the blind trust of the agent that we think for the most part is doing the right thing all the time isn't taken for granted. And the gates that we build or the harnesses or the guardrails that we build around agents operating in our system need to be deterministic, and they need to be controlled very succinctly by the security systems. Louis Columbus: The way that frontier models are evolving, the root of trust actually runs back to the models and the trainers building these models and the assumptions they make, and even down to how they red team their specific models as well. And how does a security leader and their team verify a model before they move into production with so many unknowns? That 3% is massive. Andre Durand: You're on the frontier. Here's one of the challenges. We all wanna move at agent speed. At agent speed, you can't have humans review everything. You would negate all the advantage. So if an agent can write, make it up, a thousand lines of code in a minute, yet you can't release it until a human reviews the thousand lines of code and all the implications, you basically have reduced the advantage of speed to the human gate. So that doesn't work. So then what is the answer? At some point, we probably will have to develop frameworks that we trust without seeing or verifying the output directly, and this is actually happening with coding today. So you will have a judge or an approver or a QA agent. So one agent will write and several others will review. And as long as they can't collude, they don't know about one another, they can't communicate to bypass a system or permission or control, it's not that construct is 100% foolproof. However, it's the best we can do to move at agent speed. So we have to build systems now where we trust the framework, and if we can trust the framework, then we can trust the output. So everyone is gonna wanna move fast, and the pressure is to go fast The hidden cost that we are pressing into our environments will invariably come back to haunt companies if we're not careful and we don't get the security model correct. Louis Columbus: You get that sense of, is this all making sense? Is this all within the context of what can happen from the veritable physics of how this is working? Andre Durand: The security models and the investment to get to those security models have roughly mapped to the risk of humans going rogue. Agents now, the speed with which they can move is forcing us to rethink what the fundamental security paradigm is. We now need a fine-grained authorization decision gate, and that decision gate needs to be informed, and it needs to see the accumulation of risk. One action by an agent might not be risky. Five in a row in a certain direction might cross a threshold of risk. And if you see moves moving in a risky direction, you can begin to infer intent. And so this is all moving into kind of another form of predictive markets, which is what's it going to do? And if it moves in a bad direction too far, we need to be able to hit the kill switch. Everyone wants the kill switch. We all want the speed, but where exactly is the kill switch? So now for the first time, the reason to go through the effort to do what I'm describing, it's all there now and companies can see it. And the great thing is they're all listening. They're all paying a lot of attention. They know they're moving fast, and they and they don't wanna block the innovation and the speed. But in parallel, they also recognize, and they're taking a very serious look at what do we do to get ahead of this so that the architecture can stive the future risk. We don't want to embed future risk and come, and have it all come back to haunt us a year from today. Louis Columbus: Speaking of helping those out there looking at identity platforms and getting ready for this agentic AI challenge of zero trust, what's someone question that you would advise them to ask different providers of agentic AI identity systems to ensure that they're going to get what they need from a zero trust perspective and be able to manage that at scale? Andre Durand: Point solutions strewn together here at the speed with which things are working is suboptimal. We need to be able to discover what agents are operating within our estate. We need to see the agents that are operating on endpoints. We need to know what agents are hitting our APIs and MCP servers. We need to know what agents are coming and going in the managed platforms like Bedrock and Vertex and Databricks and Glean and others. It starts with having the discovery and visibility of all the agents operating within my estate, having a place to actually register them Having a standardized method to assign custodians to those agents, having a standard way to say if these agents-- if I wanna control what those agents can do, where do I put my policy? How do I construct my policy? How do the engineers create policy 'cause they're close to the apps? So it's just pause long enough to realize that a holistic agentic security program needs to look at the whole life cycle all the way to the end of governance, where we are going to wanna review who is the human. So it's everything from discovery to registration to authentication to authorization to then governance, and we need to see this holistically. Louis Columbus: Well said. Thank you very much. Really fascinating speaking with you and your vision of agentic security. Andre Durand: Louis, it's a pleasure. It's exciting times right now, thank you.