AI Agents Break Enterprise Security as 54% Report Incidents and Confidence Drops 17 Points

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.

AI confidence just dropped 17 points in six months. That's actually great news.

The organizations losing confidence in AI are the ones most likely to get it right. Six months ago, 40% of IT leaders described their organizations as mature in AI deployment. Today that number is 23%. Before you read that as a setback, consider what it actually reflects. We recently surveyed 800 IT leaders across the U.S. and U.K. for our Q3 2026 trends report, and the data tells a consistent story: the organizations revising their self-assessment downward are overwhelmingly the ones that have moved AI agents from pilots into production. They're not losing faith in AI. They're running into the problems that only show up when agents are doing real work in real systems, and they're being honest about what they found. That kind of honesty is harder to come by than it sounds, and it matters more than the confidence number itself. Deployment was the easy part 84% of organizations plan to expand AI use in IT operations over the next 6 to 24 months, so the drop in confidence isn't a retreat. What it reflects is a more accurate picture of what production actually requires. In a pilot, an AI agent does one thing in a controlled setting. In production, it accesses real systems, makes decisions that affect real workflows, and operates continuously, often without a human in the loop. The governance infrastructure that entails is materially different from what it took to get the pilot working. Most organizations built enough to ship. Fewer built enough to scale. The IT leaders revising their self-assessment are confronting questions they didn't have to ask at the pilot stage: Can we see every agent running in our environment? Do we know what each one can access? If an agent behaved unexpectedly last week, how long would it take to find out? For most organizations, at least one of those answers is uncomfortable. The gap between perception and reality is where risk accumulates The graphic above captures the structural problem. Across confidence, governance, and autonomy, the same pattern holds: deployment is moving faster than the controls built around it. The organizations that have closed this gap share specific characteristics. They've consolidated their IT environments rather than adding tools to solve each new problem, because every additional platform creates another place where agent identity, access, and accountability can go unmanaged. They treat AI agents as governed identities rather than tolerated shadow processes. And they measure what AI actually produces, not just what it deploys. The payoff is tangible. Organizations in the top tier of our maturity model are five times more likely to report no barriers to expanding their AI agents than the average organization. They are not more cautious about AI. They are more confident in it, because they built the foundation that makes confidence earned rather than assumed. The governance gap has a specific shape The hardest problem in enterprise AI right now is not capability. It is accountability, and the data makes the specific failure point clear: non-human identity governance is the least adopted AI security practice we measured, in place at just 21% of organizations. Non-human identities now outnumber human users in 83% of organizations, and that population is growing fast. Yet most of those identities exist without the governance structures that every human employee has as a matter of course: no formal record, no named owner, no defined scope of access, no offboarding process when their purpose expires. They keep running. They keep accessing systems. They keep accumulating permissions. We call these Zombie Agents, and they are the service account problem of the AI era, operating at machine speed and in every department. The accountability gap is where real risk lives. When a human employee takes an action, there is an implicit accountability chain. When an autonomous agent takes an action, that chain breaks unless it has been deliberately engineered. Most organizations have not yet engineered it, and the gap between the autonomy agents are being granted and the oversight structures in place to manage them is widening every month. What the confidence drop is actually telling us When AI maturity confidence was uniformly high across the market, that was worth worrying about. It meant most organizations hadn't yet run into the hard parts. A selective drop, concentrated among organizations actively running agents in production, means the market is developing a more accurate picture of what AI operations genuinely require. The organizations recalibrating are doing the work that makes long-term AI adoption possible: building identity infrastructure that covers agents alongside humans and devices, unifying the environments where governance needs to apply, and measuring outcomes rather than just counting deployments. They haven't lowered their ambitions for AI. They have raised their standards for what it means to run it responsibly. 84% of organizations plan to expand AI use over the next two years. The ones that will do it well are honest enough, right now, to admit what they haven't yet built. JumpCloud's Q3 2026 AI Readiness Research report (n=800 IT leaders, U.S. + U.K.) is available here. The report covers AI agent deployment stages, identity governance gaps, IT unification benchmarks, and budget realism across mid-market and enterprise organizations. Rajat Bhargava is CEO and Co-founder at JumpCloud. 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].

Artificial intelligence agents need access, not secrets

As agentic enterprises take shape, the identity equation is shifting For years, identity security has been designed to secure an organization's human users. But as agentic enterprises take shape, the identity equation is shifting. Artificial intelligence (AI) agents and AI-powered builders - software tools used to develop websites and applications without coding - are increasingly participating in how access is configured, governed and used. AI agents are effectively new digital employees, so organizations need a way to know they exist and control what they do throughout their lifecycle. They are becoming operators, helping to administer and secure identity environments through machine-native interfaces. To add another layer of complexity, desktop agents and AI assistants are also beginning to interact with enterprise applications and resources on behalf of users. For an agentic enterprise to succeed, these agents need trusted access to do useful work but should not be given direct exposure to secrets they have no meaningful reason to access. To achieve this, organizations need a unified, AI-first identity model, centered on end-to-end visibility, governance and controls which strike a balance between security and appropriate access. AI agents are reshaping identity AI has created a new category of digital identity. Like human employees, autonomous agents must be discoverable and managed and governed so organizations can understand what systems and data they can access and who is responsible for their actions. Traditional identity and access management (IAM) systems relied on static, one-time verification methods in response to access requests made by humans. But in the agentic enterprise, requests also come from autonomous software acting on behalf of human users. Organizations therefore need to know exactly who or what is accessing a system continuously, and if they have the correct permissions to access given information. At the same time, AI is increasingly managing identities and access. Machine-native interfaces allow agents to help manage human users' access, troubleshoot issues and support security workflows. While these capabilities can help organizations cut costs and improve efficiency, they are only successful when strong access guardrails are put in place. AI has created a new category of digital identity. Like human employees, autonomous agents must be discoverable and managed and governed so organizations can understand what systems and data they can access and who is responsible for their actions. Traditional identity and access management (IAM) systems relied on static, one-time verification methods in response to access requests made by humans. But in the agentic enterprise, requests also come from autonomous software acting on behalf of human users. Organizations therefore need to know exactly who or what is accessing a system continuously, and if they have the correct permissions to access given information. At the same time, AI is increasingly managing identities and access. Machine-native interfaces allow agents to help manage human users' access, troubleshoot issues and support security workflows. While these capabilities can help organizations cut costs and improve efficiency, they are only successful when strong access guardrails are put in place. Building a unified identity model for AI Mechanisms for securing AI cannot simply be bolted onto identity systems designed for humans. It requires a complete rethink of the identity management model, where human and machine identities are governed through a single framework to prevent tool sprawl and unintentional security blind spots. As organizations adopt AI tools throughout multiple operational layers, enterprise identity needs to evolve and become easier to manage and automate. Identity can no longer rely solely on human administration. Tools designed specifically for autonomous agents, such as AI-first headless interfaces, allow builders and AI alike to perform identity-related tasks. Autonomous operators must also be trained to configure access, troubleshoot workflows and apply governance controls within approved policies and guardrails. Visibility and governance across the entire AI agent lifecycle are also critical. As more agents are deployed, businesses must have complete visibility into their agents and actions. Every AI should be treated as a first-class identity, with a designated human owner, as well as clear policies and full auditability throughout its entire lifecycle. As these agents operate across the enterprise, their actions should be traceable to a human user responsible. Finally, AI agents need trusted ways to interact with enterprise resources without being given direct access to the credentials or secrets that enable them. Coding and desktop agents increasingly interact with systems on behalf of users, but exposing them to credentials or long-lived secrets creates unnecessary risk. Instead, access to enterprise resources should be brokered through just-in-time privileged controls. This allows enterprises to maintain oversight of how permissions are granted, governed and audited without exposing the underlying secrets behind that access. Together, these capabilities create a unified identity model which extends governance across human and AI identities without creating a parallel identity stack. The future of the agentic enterprise AI agents cannot operate as intended and deliver meaningful value without access to enterprise systems. But granting unrestricted access or exposing sensitive information creates an entirely new risk to organizations. The future of the agentic enterprise depends on maintaining governance, visibility and control across both human and digital identities. This means identity must become programmable, AI agents should be governed throughout their lifecycle and agent access needs to be given without unnecessary exposure to sensitive data. A unified identity strategy provides the means to operate AI agents more safely and efficiently while maintaining centralized governance, accountability and control. We've featured the best endpoint security software. This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

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.

Why identity is becoming AI's control layer

Mike Reddie, vice president and general manager ANZ at Okta, says the rapid adoption of AI is creating a new challenge for organisations seeking to maintain oversight of increasingly complex technology environments. "AI is moving out of emerging status into production," Reddie says. "The incredibly rapid acceleration of the adoption of these capabilities is creating what's now being tracked as an acknowledged and concerning governance and control problem." Organisations across government, education and enterprise sectors are using AI to improve customer experiences, reduce administrative burden and increase productivity. AI capabilities are appearing across front-office and back-office functions alike. Yet as AI becomes more deeply embedded, organisations are confronting new questions around visibility and control. "Most organisations are telling us they are now running AI agents addressing many different use cases," Reddie says. "What are the agents doing? Which data do they have access to? Which systems do they have access to? Do we have visibility and control?" Non-human players As the number of non-human identities grows, organisations are being forced to rethink how they manage access and oversight. According to Reddie, organisations have traditionally built identity and security strategies around people. Employees are recruited, onboarded, trained and granted access to specific systems and information needed to perform their roles. AI agents operate differently. "An important factor here is just the sheer scale of it," he says. "We're currently at a point where non-human identities are outnumbering human identities at 45 to one." While the exact ratio may vary between organisations, businesses are increasingly managing growing numbers of non-human identities alongside their human workforce. The issue extends beyond the number of identities involved. AI agents can also operate at a speed and scale beyond what is possible for human workers. "Beyond just the sheer number of non-human identities, they can operate at a far greater scale, and they can also operate at a far greater pace than humans," Reddie says. As a result, organisations are being forced to consider what happens when AI agents gain access to sensitive information, enterprise systems and business processes. "If something goes wrong with one of these AI agents, or it's compromised or controlled by a bad actor, then what is the blast radius of that problem?" he says. "Do I have controls to shut it down? Do I have a kill switch?" Oversight and control For many organisations, identity is becoming the control layer that helps govern how AI systems access data, applications and business processes. For many organisations, identity is becoming the control layer that helps govern how AI systems access data, applications and business processes. The goal is not simply determining who can log into a system. It is understanding which AI agents exist, what permissions they have, what information they can access and what actions they are authorised to perform. Reddie says this becomes particularly important as organisations grapple with the rise of unsanctioned AI usage. "We know from our surveys and our interactions with the industry and market that approximately 52 per cent of employees that we've surveyed are also using non-endorsed shadow IT AI tools," he says. "Platforms like Okta help organisations get a proper understanding of which AI agents are in use, what the agents can do, and then bring the necessary governance and controls into place," Reddie says. South Australia's Department for Education has made identity management a cornerstone of its AI strategy, using it to support personalised learning experiences, manage user permissions and maintain oversight of how students and educators interact with its EdChat platform. The department supports more than 179,000 students and almost 33,000 teachers and staff, creating a highly diverse technology environment spanning hundreds of sites, devices and applications. Daniel Hughes, chief information officer at the Department for Education South Australia, says the department recognised early that AI had the potential to reduce administrative workload while also supporting student learning outcomes. "We wanted to explore the benefits in terms of using AI as a tool to help transform how students learn," Hughes says. The department's EdChat is an AI platform designed specifically for educational use. "We wanted EdChat to respond differently to a Year 7 student as compared to a Year 12 student," Hughes says. "Having the ability to manage identity was fundamental to our success." The department's existing Okta environment enabled it to build identity into the platform, allowing different users to receive different experiences based on their role and context. Identity also supported the implementation of governance controls and guardrails. "Having those guardrails in place was fundamental to protecting the data, but also to protecting the student," Hughes says. The department uses data from interactions within the platform to better understand how students and educators use AI and where additional support may be needed. For Hughes, visibility is not only about risk management. It is also about understanding how students engage with AI and how educators can help guide that process. "We wanted to understand the role of an educator," says Hughes. "We wanted to see that interaction to understand what the role of an educator then was." As organisations deploy more AI agents and non-human identities, the ability to understand what those systems can access, what actions they can perform and how they are governed is becoming increasingly important. Reddie says businesses that establish strong identity foundations early are likely to be better positioned as AI becomes more deeply embedded in operations. "The organisations that build their strategy with identity security at the forefront of their strategy and then build out their technology and AI capabilities in line with that are much better equipped to scale AI," Reddie says. Questions around oversight, access and accountability are likely to become increasingly important. For many organisations, securing AI may depend less on the technology itself and more on understanding who, or what, is accessing systems in the first place.

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.

Why AI Infrastructure Demands a Shift from Static Identity to Runtime Data Control

By Roshmik Saha, Co-founder and CTO, Skyflow Recent high-profile AI security incidents have driven home a fundamental, yet often overlooked, engineering principle: intelligence should never imply unrestricted access. As enterprises race to deploy autonomous agents, we are witnessing a fundamental shift in how software interacts with enterprise data. Once an AI agent is granted broad access to sensitive datastores and internal tools, traditional security models fall apart. Perimeter controls, static permissions, and post-processing safeguards are simply insufficient when dealing with systems that act at machine speed -- combining disparate information, executing API calls, and making multi-step decisions in ways human operators cannot predict in real time. For decades, cybersecurity has focused on protecting where data is stored. The urgent challenge of the AI era is protecting data while AI is actively processing it. Treating AI Agents as Dynamic Runtime Identities To secure autonomous workflows, every AI agent must be treated as its own runtime identity. Access can no longer be governed by a one-time check at login or deployment; it requires least-privilege policies that are evaluated continuously based on real-time context. Under this model: * Task-Specific Exposure: Sensitive data is exposed only for the precise task being executed. * Ephemeral Availability: Data remains accessible only for the brief window required to complete the operation. * Contextual Authorization: Access is granted strictly after dynamic policy engines confirm the agent's current action is authorized. The Imperative of Runtime AI Data Control This is where runtime AI data control becomes foundational to enterprise security architecture. Instead of handing models raw Personally Identifiable Information (PII), Protected Health Information (PHI), or Payment Card Industry (PCI) data, security teams need granular control over the data pipeline. By dynamically sanitizing data before it reaches the model and selectively rehydrating only the minimum required fields, organizations can insulate themselves from prompt injection, unexpected model behavior, and accidental data leakage. Crucially, every single access decision must be fully observable and audited. The Next Era of AI Governance As AI agents transition from experimental novelties to core infrastructure, our defense strategies must evolve. Governance can no longer rely on static identity controls -- it must shift to real-time data controls. The organizations that successfully and safely scale AI will not be those that erect the highest perimeter walls, but those that enforce security policies at the exact moment data is accessed. Ensuring every interaction with sensitive information is contextual, authorized, and observable is no longer optional -- it is the prerequisite for the future of enterprise AI.

AI Is Already Inside the Enterprise. Has Security Kept Up in India?

Artificial intelligence is no longer sitting at the edge of enterprise experimentation. Across India, AI assistants and autonomous agents are moving into live business environments, embedded across email, customer support, internal messaging, cloud applications and collaboration workflows. That shift is creating enormous opportunity. AI can help organisations move faster, automate routine work, improve customer experience and support better decision-making. But it is also changing the security equation. As AI becomes part of how work gets done, it is expanding where risk appears, how quickly incidents move, and how difficult it is for security teams to investigate what happened. Proofpoint's 2026 AI and Human Risk Landscape report shows that AI adoption in India has already moved well beyond pilot stage. 94% of organisations in India have deployed AI assistants beyond the pilot stage, while 88% are advancing autonomous agents. Yet security readiness has not kept pace. More than one-third (35%) of organisations describe their AI security posture as catching up, inconsistent or reactive. More than three in five (63%) have already experienced a suspicious or confirmed AI-related incident. This is the gap that should concern security leaders. AI is not waiting for governance frameworks to mature. Security leaders in India are under more pressure to address key areas of concern. AI has Expanded the Attack Surface For many years, cybersecurity strategies were built around familiar control points: email, endpoints, cloud applications, identities and data repositories. Those still matter. But AI is now connecting these environments in new ways, allowing risk to move across workflows at machine speed. In India, email remains the most common AI-related threat vector, affecting 70% of organisations. But exposure now extends much further: SaaS and cloud applications at 59%, SMS or text at 55%, and collaboration tools such as Teams or Slack at 54%. Among organisations that experienced an AI-related incident, exposure rises across every channel, including 73% in email and 65% involving SaaS and cloud applications. This matters because enterprise work no longer happens in a single channel. A sensitive document may move from email into a collaboration platform, be summarised by an AI assistant, stored in a cloud application, and referenced by an autonomous workflow. Each step creates another point where data, identity and intent need to be understood. Many organisations already have some forms of AI security controls, for example, monitoring shadow AI applications. However, the critical visibility is whether those controls can see across the connected environment how AI is actually being used. Data Security and AI Security Are the Same Problem One of the most common structural errors in how organisations approach AI security is treating it as a separate workstream from data security. It is not. They are facets of the same problem, and solving one without addressing the other creates compounding exposure. The earliest AI security challenge was clear: employees were using consumer AI tools to process sensitive business information. In 63% of employees who used AI applications uploaded confidential company data, such as source code and customer records, to personal chatbot accounts. According to IBM's Cost of a Data Breach Report, shadow AI breaches cost an average of US$670,000 more than standard security incidents, driven by delayed detection and difficulty determining the scope of exposure. The second wave is more complex. As organisations moved to enterprise AI platforms -- Microsoft Copilot, Salesforce Einstein, and others -- the question became not whether data was leaving the organisation, but whether AI tools were accessing only the data they were supposed to. That is a data security problem expressed through an AI lens. The third wave is real-time and agentic. Autonomous agents do not just respond to prompts. Similar to humans, they connect to external tools and MCP servers, acquire new capabilities, and act on data across connected systems. Understanding what an AI agent is doing requires capturing not just the prompt and response, but every tool call and downstream action in between. When security teams do not have visibility into what AI is connecting to and acquiring, they cannot tell the board they have it under control. Gartner projects that by the end of 2026, up to 40% of enterprise applications will integrate with AI agents, up from less than 5% in 2025. It also predicts that by 2028, 25% of all enterprise GenAI applications will experience at least five minor security incidents per year, up from 9% in 2025. The risk is scaling faster than governance. Security and data governance teams need a shared view: what data exists, who and what has access to it, and how AI agents are actually using it. Having a clear view of all your data is not fictional, and it should be the foundation of building a robust AI security for any organisation. Only 57% of organisations in India say they are fully prepared to investigate an AI- or agent-related incident, while 47% report difficulty correlating threats across multiple channels. As AI activity increasingly spans email, collaboration platforms and cloud systems, visibility across connected environments becomes critical for understanding what happened and responding effectively. Tool Sprawl is Holding Security Teams Back Fragmented security stacks are compounding the challenge. Almost all organisations in India say managing multiple security tools is at least moderately challenging, and more than half describe it as very or extremely difficult. Respondents cite operational cost pressures, integration challenges and difficulty correlating threats. When controls sit in separate systems, security teams lose time moving between dashboards, reconciling alerts and trying to connect activity across email, cloud, collaboration and AI systems. That delay matters when incidents can spread across workflows quickly. As AI scales, security architecture becomes a strategic priority. Organisations are recognising that AI security cannot be solved with isolated controls. It requires an architecture that can protect people, data and AI systems across the channels. Over the next 12 months, 67% of organisations in India plan to expand AI protections, 71% intend to extend collaboration of collaboration channels, and 58% expect to move toward a unified platform approach. AI adoption in India is not slowing down. The boards and CEOs driving it are right that falling behind carries real competitive cost. The security leaders are now in a position to enable this AI innovation with the visibility to secure it, govern it, and defend it. That is what setting the pace looks like. (The author is Bikramdeep Singh, India Country Manager, Proofpoint, and the views expressed in this article are his own)