This post extends the discussion from visibility to observability while also sitting inside a larger AI security framework. Jonathan Care’s Advisory Note, “Navigating the Agentic AI Security Landscape,” introduces a six-category framework for agentic AI security and governance. What follows is not a competing model. It is a continued discussion of the visibility and observability slice of that landscape, expanded into the seven controls that an organization or a vendor must have in place to deliver effective observability after agent discovery.

The seven controls of AI agent observability

1. Inventory, Ownership, and Identity Context

A list of agents is not an inventory. A useful agent inventory requires context: an owner, a purpose, a lifecycle state, and a mechanism for flagging an agent as orphaned the moment its owner leaves the organization. Without these and other contexts, agents will accumulate the way stale service accounts have, except faster

2. Runtime Telemetry and Trace Capture

Knowing an agent exists and its key context is not the same as knowing what it did. Prompts, tool calls, and Model Context Protocol (MCP) activities all need to be captured, not merely the fact that the agent ran and produced some result.

3. Interaction and Delegation Mapping

Agents call other agents, and agents can also receive delegated rights directly from people. A system that maps only the first hop of that chain will miss the multi-hop delegation paths where accountability gets lost.

4. Permission, Credential, and Tool Access Analysis

Most agents do not hold their own permissions today. In practice, they inherit access transitively through a service account or an OAuth grant. A security system blind to that inheritance is blind to the actual attack surface, regardless of how complete the agent inventory appears.

5. Behavioral Analytics and Threat Detection

Baselining normal behavior, then using that to detect prompt injection, agent hijacking, and other anomalous patterns, is where observability starts feeding threat detection. This is also where this area touches Care's Agent Threat Detection and Response (ATDR) category. But the relationship is sequential, not overlapping: observability produces the telemetry ATDR detects on, and ATDR adds the response half (automated or human-in-the-loop remediation) that observability doesn't cover.

6. Policy Enforcement and Guardrails

Detection without enforcement is an expensive dashboard. The real test is whether an agent security system can block, suspend, or require step-up, human-in-the-loop approval in real time, rather than only alerting after the action has already been completed.

7. Explainability, Audit, and Governance Reporting

Can the organization reconstruct why and how an agent did something, in a form that satisfies an EU Artificial Intelligence Act (AI Act), Digital Operational Resilience Act (DORA), or an internal governance, risk, and compliance (GRC) auditor, and not only an engineer reviewing a log file?

Each of these seven control areas fails if treated as an independent feature rather than a connected set of capabilities. Telemetry that does not feed detection is wasted collection. Detection that does not feed enforcement or audit is a lost alert. Whether the full solution comes from a single AI Agent Visibility and Observability Platform (AI-VOP) (the ideal) or from a combination of integrated point solutions, complete observability is the goal.

Before evaluating a single vendor, an internal AI security and governance program should ask some questions of itself to understand its existing gaps and investment priorities. Does every agent in production have a named owner and a lifecycle state, and does that agent get flagged the moment its owner leaves? Can the team reconstruct a complete, ordered sequence of an agent’s actions (prompts, tool calls, and MCP activity) for a single session? Can they show which agents call other agents, and which rights a person delegated directly to an agent? Can they trace an agent’s access back through inherited service account or OAuth credentials? Do they have a baseline of normal agent behavior good enough to make prompt injections or agent hijacking detections? Can their existing controls block or suspend an agent mid-action, or require human approval, rather than only alerting after the fact? Can the team hand an AI Act, DORA, or internal GRC auditor a report and not just a log file? If the honest answer to these sorts of questions is “no,” observability is a gap.

KuppingerCole Analysts is developing a Leadership Compass evaluating the market and vendors against this AI-VOP framework. Consider this post as a starting map for reading any AI-VOP vendor pitch, and for judging an organization’s own program against the framework.

That fluency is the real story. A network-layer exploit gave these attackers a technical foothold inside the application. From there, the path to a manipulated business process (a fraudulent payment run, altered master data) sits only one step further. Three layers, one attack chain: network, application, business process. Each layer already produces signals. None of those signals reach the same team, let alone the same decision.

That gap is the problem worth solving.

Three Domains, One Blind Spot

The SAP case is one instance of a pattern that shows up in at least three places.

1. Network to application to business process. A network-layer exploit becomes a technical foothold first. The business-process manipulation that follows, sometimes weeks later, is only catchable if the two earlier stages were already correlated.
2. Identity to real-time communication to transaction. A convincing deepfake on a video call, a legitimate-looking corporate login, and a large, time-pressured wire transfer together form a fraud pattern spanning three platforms at once. Each system in isolation sees nothing wrong.
3. Access to intellectual property and source code. A contractor persuaded or compromised into handing over proprietary code triggers no financial signal at all. The only trace is an unusual constellation of otherwise ordinary actions.

None of these can be caught by identity signals, network signals, or transaction monitoring alone. The second pattern, identity fused with a real-time channel and a transaction, is territory my colleague Jonathan Care mapped from the finance side in his whitepaper on preventing million-dollar ERP fraud. What's new here is pulling the network and business-application layers into the same picture.

The Second Step Nobody Has Built

Step one is identity signal standardization, and it is largely solved. Google first proposed continuous, real-time session evaluation in 2019, and the OpenID Foundation's Risk Incident Sharing and Coordination (RISC) work runs on a similar timeline. For most of the years since, both lived as implementer's drafts: promising, but not yet fixed standards. That changed in September 2025, when the Shared Signals Framework (SSF), the Continuous Access Evaluation Profile (CAEP), and RISC were approved as OpenID Final Specifications, closed to further revision. CAEP tells relying systems when a session or device changes state; RISC tells them when an account itself is compromised or disabled. Identity can now be treated as continuously evaluated, not asserted once at login and trusted for the rest of the day.

Step two is missing: correlating those identity signals with the network, communication, and business-application signals that sit alongside them. This is what Continuous Controls Monitoring (CCM) does. CCM watches business applications like SAP for control violations and process anomalies in near real time, which makes it the natural third leg alongside identity signals (CAEP, RISC) and network and endpoint signals (extended detection and response, or XDR). Without CCM, correlation stops at the application's front door and never reaches the business process behind it.

What Actually Makes Correlation Hard

Identity mapping across domains looks like the missing piece, but mostly it is not. When an organization already maps accounts, devices, and roles to a single identity graph, a mature Identity Fabric, that mapping is solved. At that point it is an engineering problem. What remains genuinely difficult is narrower:

• Ephemeral, session-level binding. The Identity Fabric tells you which person owns which account. It does not tell you that a specific call, a specific network flow, and a specific transaction reference all belong to the same live event thirty seconds ago. That binding has to be built fresh, on top of the static graph.
• Confidence, not just events. CAEP and RISC deliver discrete, binary events. Deepfake detection and CCM-style anomaly scoring deliver probabilities that shift as models and attackers both adapt. No standard yet defines how to fuse the two.
• External counterparties. The CFO on the call is a known identity. The counterparty triggering the fraud attempt often is not, and no internal governance extends automatically to accounts you never provisioned.

Response has to change, too. Correlation across domains is not a block-or-allow decision. A flagged transfer should trigger step-up verification or a delay for human review, not an automatic hold a CFO will simply route around next time. Differentiated response, matched to severity and reversibility, is what makes correlation usable in practice.

Three Gaps, and How to Close Them

The first gap is inventory. Signal availability is rarely the problem; what almost nobody has done is map which systems produce what, or where those signals currently dead-end, so start there before buying anything new. The second is identity resolution. A correlation program built on a weak Identity Fabric inherits every gap in that fabric, which makes identity resolution a precondition for everything downstream. Coverage is the third gap, and business-application signals are the layer most often left out, which is why CCM has to be a deliberate part of the correlation stack.

Once those gaps are closed, two decisions turn the capability into a program: design response tiers (step-up, containment, escalation) before a signal ever fires, not after; and start with one high-value scenario, such as executive-impersonation fraud on large transactions, rather than attempting to correlate everything at once.

A Governance Problem Wearing a Technology Costume

The main obstacle is not technical. SOC, IAM, DLP, fraud teams, and CCM each sit in different reporting lines with different budgets and KPIs, and in most enterprises that is also a Target Operating Model problem: the org chart was never drawn with cross-domain fraud correlation in mind. Building the correlation layer is the easier half of this change; getting those silos to agree on a shared signal bus and response playbook is the harder one.

That is why this cannot be delegated downward and left there. Business fraud is no longer confined to the systems and units that historically owned it, and the mandate to fix that has to come from the top: from the CEO to the CFO, and jointly to the CIO and CISO. A heterogeneous application environment that no single signal vendor covers end to end doesn't rule out a solution; it just means the solution must be a joint effort across the stages, disciplines, and teams described above, not a platform purchase.

Without that mandate, the correlation layer becomes another dashboard nobody owns, checked after an incident rather than acted on before one.

The Bottom Line

The standards that deliver real-time identity signals matured recently. The vendors that correlate signals within a single domain are mature too. XDR, identity threat detection and response (ITDR), CCM, and transaction monitoring all work well inside their own lane. What does not yet exist is a vendor, or a program, that correlates across all of them for business fraud specifically. I do not think that gap survives much longer. Organizations that start building the correlation capability, and the governance mandate behind it, now will be the ones that catch the next SAP-fluent attacker before the technical compromise becomes a business one.

In the identity world, governance usually means managing identities, entitlements, approvals, certifications, and access. Mention governance to someone working in AI, and the discussion quickly turns to transparency, accountability, model behavior, bias, and regulatory oversight.

Neither definition is wrong. They simply grew up in different communities.

What has struck me over the past year is how quickly those communities are beginning to overlap.

Governance Is Following the Architecture

Consider a fairly ordinary enterprise workflow. An employee approves a transaction. An AI assistant gathers information from several systems before making a recommendation. The recommendation triggers an automated workflow running under workload identities in the cloud. The final decision is recorded for audit, along with the policies that influenced it.

Where does identity governance end? Where does AI governance begin? I'm not convinced those boundaries are especially useful anymore.

For a long time, identity professionals have tended to treat governance as something that happens around identities: who should have access, who approved it, when should it be reviewed, and when should it be removed.

Those questions remain important. They also turn out to be only part of a much larger governance problem.

Organizations increasingly need to understand not only who or what participated in a transaction, but also under whose authority the action was taken, which policies governed it, and what evidence supported the action. Those questions apply whether the participant is a person, an application, an AI system, or another organization.

Identity is still part of the answer. It simply isn't the whole answer.

The Questions Haven't Changed, but the Systems Have

This is one reason I find some of the discussions around AI governance a little unsatisfying. They often imply that governance has suddenly become important because AI arrived.

Identity professionals know better.

We've been wrestling with accountability, delegated authority, least privilege, lifecycle management, and auditability for decades. Those concepts did not disappear when AI entered the conversation. They became relevant to a wider range of systems.

The opposite is true as well.

Identity governance can no longer assume that every meaningful action begins and ends with a human user authenticating to an application. Increasingly, important decisions involve software components, cloud workloads, organizational identities, automated services, and AI systems acting within defined boundaries.

AI agents add a further complication because they do not merely authenticate and execute predefined instructions. They may select tools, delegate tasks, adapt their behavior, and act across several systems under authority derived from a person or organization.

The governance challenge has expanded because the systems themselves have expanded.

Identity Becomes Part of a Trust Architecture

I don't think this means identity governance is becoming obsolete. If anything, it has become more foundational.

Strong identity remains one of the building blocks for trustworthy systems. But trustworthy systems also require policy, authorization, provenance, transparency, organizational accountability, and, increasingly, some way to understand how automated decisions were made and under what authority they were allowed to occur.

Those concerns don't belong exclusively to identity teams or AI teams. They also belong to architects, risk owners, and business leaders.

That may be the biggest change underway.

We're moving away from governance as a collection of specialized disciplines toward governance as an architectural property of the system itself. Identity remains an essential part of that architecture, but it no longer defines its boundaries.

Perhaps that's the wrong way to think about identity governance altogether. Rather than asking how governance is expanding beyond identity, we might instead ask whether identity has finally become integrated into the broader trust architecture it was always meant to support.

I suspect that's a healthier direction for both disciplines.

That gap is widest at sites with no dedicated database administrator, let alone a database security specialist. The same pattern repeats across branch and satellite offices running local databases for latency, connectivity, or regulatory reasons. Add sites and the number of databases needing supervision grows; the number of people supervising them does not.

These are the buyers Oracle is targeting with the new Base Database Cloud@Customer, announced as a mid-scale hybrid cloud tier below Exadata Cloud@Customer, which is designed for large-scale, mission-critical workloads.

Mounted on Arrival: What the Cloud Connection Buys

Base Database Cloud@Customer occupies roughly the position Oracle Database Appliance held for years, serving mid-scale Oracle workloads at customer locations. The hardware is conventional, two X11 servers in an 8U footprint, up to 120 usable cores, and 47.2 TB of all-flash storage at the top end. The infrastructure subscription runs four years minimum, with an optional fifth, while compute and storage scale online. You commit on the hardware and adjust the licensing later, the reverse of most on-premises purchases.

A more important difference is that Oracle Database Appliance had no cloud connection, and this platform does. That connection is how Oracle ships the security controls already configured instead of leaving them for you to set up. Oracle owns and operates the servers, storage, network, hypervisor, firmware, and system software. Nobody at the site needs to know how to build a correctly configured database platform.

Cloud automation encrypts data across the databases, enforces password policies, and manages backups, Data Guard configuration, and Real Application Clusters (RAC) failover. All of it runs through a management layer in Oracle Cloud Infrastructure (OCI) that reaches the on-premises system over a secure tunnel.

Bring Your Own License (BYOL) deployments of both Oracle AI Database Enterprise Edition and Standard Edition on Base Database Cloud@Customer include Transparent Data Encryption (TDE) and Oracle Data Safe at no additional license cost. Databases using the license-included consumption model include all Oracle AI Database security options and management packs supported for that edition, also at no additional cost.

With AI agents now querying these databases too, that coverage matters more, and Oracle Key Vault extends it: an on-premises appliance that keeps the master key on your site but outside the database virtual machine holding the data.

Patching Gets Dramatically Easier: Up to the Database Line

Oracle manages this platform, but it does not patch all of it: that would be Autonomous AI Database on Exadata Cloud@Customer. With Base Database Cloud@Customer, Oracle patches the hypervisor, system software, and firmware across the infrastructure it owns, within a maintenance window you can adjust to fit your own operating requirements. The guest operating system and the database remain yours to schedule.

That work runs through cloud automation, which removes the standard reasons for postponing a patch. Rolling updates across a two-server RAC configuration turn zero-downtime patching from a quarterly infrastructure project into a routine operation.

What the automation cannot do is decide when to update the database. The platform will not catch a missed database patch, and the deferrable infrastructure window has no equivalent on the database side. The practical question at these sites is whether anyone owns the schedule.

Private AI On Site: Protection at the Data Layer

Oracle positions the service as “private AI for data, anywhere.” The same infrastructure can run Oracle Private AI Services Container with local open-weight models alongside Oracle AI Database Private Agent Factory, so embedding generation, vector storage, and retrieval-augmented generation all happen behind your firewall.

Data residency requirements, sector-specific regulations, and emerging AI governance obligations all turn on where processing occurs, who can reach it, and whether you can demonstrate both to an auditor. Keeping all of it inside one physical boundary answers those questions more persuasively than a contractual assurance about a public cloud region.

One caveat: your data stays local, but the management layer does not, and some regulators ask about management residency separately from data residency. If the management link drops, your databases keep running, so this is a governance question rather than an availability one.

Local infrastructure gives you guardrails you can inspect and control. The durable protection sits one layer down, next to the data, where a control holds regardless of what is asking and cannot be switched off by whoever runs the model. Stopping an agent from dropping a production table needs no AI security product, only a privilege model under which nothing, human or agent, holds that entitlement.

That is the model Oracle already applies by placing enforcement in the data layer, and Base Database Cloud@Customer brings it within reach of organizations that could not previously operate it. That enforcement lives in Deep Data Security, new in Oracle AI Database 26ai, and in the in-database SQL Firewall, and both are worth enabling at provisioning time: a control you switch on after your first incident did not protect you from it.

Inspection Is Still Yours

You hold root access to the database virtual machines and full DBA privileges on the databases you provision. Controls that arrive running can stop running later, switched off during a troubleshooting session that nobody reverted, or lost when a database is rebuilt without its policies. Encryption status, audit configuration, and agent privileges need checking on a recurring schedule, because none of them announce it when they change.

Oracle has removed the price barrier earlier, and now most of the deployment barrier as well through cloud automation. The controls arrive running, the platform is operated for you, and sites without a database specialist now get a security posture that used to require one. The fire extinguisher arrives mounted and charged. Checking the gauge is still your job, unless, of course, you opt for Autonomous AI Database on Exadata Cloud@Customer.

No Settled Set of Required Capabilities

The AI SOC market is not yet settled on a comprehensive capability set, though it is trending that way. For now, many AI-based sub-categories live under the same AI SOC label. Some vendors bolt an AI copilot or chatbot onto an existing Security Information and Event Management (SIEM) or Security Orchestration, Automation and Response (SOAR) system. Others build agent-driven case management inside existing SOAR workflows. A third pursues autonomous triage-and-close, filtering alerts with minimal human involvement. A fourth offers investigative support without full automation. A fifth leads with a context or knowledge-graph-first architecture rather than an alert-triage one.

A sixth shifts from triaging alerts to continuous threat hunting, turning current attacker tradecraft into environment-specific questions answered with evidence from data already collected. A seventh works upstream on the detections themselves, building, testing, and tuning them against MITRE ATT&CK. Each is a different bet on where the greatest pain lies in a Security Operations Center (SOC). A complete AI SOC solution will ultimately need all these capabilities.

Another part of the explanation is structural. The technical floor for a defensible V1 product is low: leveraging a Large Language Model (LLM) for triage and alert summarization is a genuinely useful feature. The perceived reward, fueled by investor enthusiasm for all things agentic in security, is high. Our own Emerging AI SOC Leadership Compass sets a functional baseline against which that enthusiasm can be measured. Against it, many of these vendors are solving different slices of the same alert-fatigue problem rather than competing head-to-head, yet. That alone inflates the headline vendor count well beyond what one coherent market would produce.

Go-to-market for the vendors is just as varied: some sell Managed Detection and Response (MDR) services, some supply their system to third-party MDR providers, most also sell direct to enterprises, and increasingly, many do all three. When markets are early stage, the number of players can remain high.

Incumbents and New Entrants, Arriving Together

Layer onto that another market dynamic. Established security platform vendors, Microsoft, Palo Alto Networks, ServiceNow, and CrowdStrike among them, are extending AI across their existing SOAR, SIEM, IT Service Management (ITSM), Endpoint Detection and Response (EDR), and Extended Detection and Response (XDR) systems. At the same time, dozens of AI-native startups are building fresh, with no legacy detection-and-response system to extend and defend.

We at KuppingerCole Analysts have a specific example of how quickly this market transition is happening. Our own SOAR Leadership Compass, last published in late 2024, was superseded only 18 months later by the Emerging AI SOC Leadership Compass in April 2026. The SOAR category did not simply add vendors over that period; it structurally transitioned, moving from rule-based playbook automation toward an LLM-based reasoning layer combined with specialized threat detection and response AI agents. That kind of transition, by its nature, produces exactly the overlapping vendor surge we are witnessing today.

Is There Enough Oxygen for Everyone?

The closest legacy proxy market for the budget lines these 123 vendors are selling into, or attempting to displace, is primarily the combined spend across SIEM, SOAR, Threat Intelligence, EDR, and XDR. Combining all these markets, the available AI SOC total addressable market (TAM) plausibly reaches into tens of billions of US dollars in 2026. So maybe there is enough oxygen, on average. But how much goes to the established platform providers versus the new entrants?

Set against that uncertain addressable market, the venture capital chasing AI SOC specifically has been anything but cautious. 7AI closed a $130 million Series A at a $700 million valuation, the largest cybersecurity Series A on record. Exaforce closed a $125 million Series B at a $725 million valuation barely a year after its own Series A. Valuations at that size require a durable, meaningful share of a market that is in its early stages of development and transition. Large valuations demand a large amount of oxygen.

A Bifurcation, Not a Bloodbath

Not every one of the 123 will survive and thrive, and not everyone needs to. Our expectation is that approximately twenty vendors will remain as independent, comprehensive AI SOC vendors by 2030. A likely outcome is bifurcation: these comprehensive independent vendors with real architectural differentiation, AI SOC coverage, and enterprise traction will thrive, with a long tail of others that gets acquired to become part of broader security platforms, pivot to other security needs, or quietly fade away. We will keep track of this market and the shake-out as it happens, in our ongoing AI SOC coverage.

That model breaks the moment Non-Human Identities (NHIs) begin to outnumber human ones by an order of magnitude, and Artificial Intelligence (AI) agents start requesting access on their own initiative.

This post looks at why architecture is the real fix for future-proofing IAM, rather than another tool. It covers the shift from siloed IAM to a modular Identity Fabric, the governance challenge posed by NHIs and agentic AI, and the growing need for orchestration and portable trust across organizational boundaries.

From Silos to a Service-Based Fabric

Traditional IAM was built tool by tool. Each addition solved an immediate problem while adding another integration to maintain, leaving most enterprises today with a patchwork of systems never designed to work together.

The Identity Fabric model, as developed by KuppingerCole Analysts, replaces that patchwork logic with a layered structure of capabilities, services, and tools mapped against every type of identity and every system that identity needs to reach. It does not demand a rip-and-replace project. Organizations can start with a converged platform and extend it piece by piece or they can combine tools from several vendors in a loosely coupled way. Either path works, because a fabric is an architecture rather than a single product.

KuppingerCole Analysts' 2025 Identity Fabric and IAM Reference Architecture sets out that layered model in detail. A follow-on advisory note, Operationalizing the Identity Fabric and Reference Architecture, translates it into roadmaps that architects and program owners can execute. Between them, the two documents answer the question every Chief Information Security Officer (CISO) eventually asks: How do we get from the diagram to a working program?

The fabric also solves a communication problem. A detailed reference architecture means little to a finance director signing off the budget, which is why KuppingerCole Analysts maintains a lean version reduced to four core capabilities:

• User lifecycle management
• Access governance
• Access management
• Authorization

KuppingerCole Analysts uses that simplified view in board briefings, because a two-minute explanation that gets the point across beats a 30-minute walkthrough that does not. Neither version replaces the other: the detailed model guides the build, while the lean model wins the budget for it.

The Machine Takeover Nobody Governed

Ask most IAM teams how many human employees they manage, and they will usually have an answer in seconds. But ask how many service accounts, API keys, and autonomous agents are running, and the answer is rarely definite.

That uncertainty itself is the problem: NHIs, a category that spans service accounts, machines, workloads, APIs, and now AI agents, do not behave like human identities. They scale faster, interact with each other, and rarely go through the onboarding and offboarding rituals built for employees. KuppingerCole Analysts' advisory note From Machine Identity to Agentic AI: Charting the NHI Continuum traces this progression from static credentials to context-aware agents that request, delegate, and act without a human in the loop.

A real tension has emerged among analysts and vendors over how to handle this. Some IAM teams treat agentic AI as another provisioning workflow: grant access at deployment time and move on. KuppingerCole Analysts' position is that autonomous agents need continuous, runtime authorization instead, because a provisioning-time decision cannot account for what an agent chooses to do days later. Organizations that only solve NHI governance at the front door are solving only half the problem.

That gap between granting access and ever revisiting it is not hypothetical. At EIC 2026, GitGuardian presented its State of Secrets Sprawl 2026 findings that 28.65 million new hardcoded secrets turned up in public GitHub commits in 2025 alone, a 34% jump over the year before, and 64% of secrets leaked back in 2022 are still valid because nobody revoked them. Few teams can name who owns a given secret, when it was created, or what it can actually reach.

KuppingerCole Analysts' report on Machine Identities walks through the lifecycle risks behind that blind spot, from orphaned credentials to forgotten repository secrets. For teams building a business case, KuppingerCole Analysts’ Buyer's Compass on Non-Human Identity Management sets out the discovery, classification, and policy controls that a credible NHI program needs.

Trust That Travels Beyond the Perimeter

Identity no longer stops at the firewall the way it used to. Employees work with partners, contractors, and customer-facing platforms that sit outside any single organization's control, and each of those relationships needs a way to establish trust without a phone call to IT.

This is where orchestration and portable credentials take over from simple authentication. An Identity Fabric only delivers value if its services can be composed on demand, routing a request through the right combination of authentication, authorization, and governance checks regardless of where the identity originated. But that composability has always assumed the organization provisioned the identity in the first place. Verifiable credentials and wallet-based models, including the EU Digital Identity Wallet (EUDIW) now moving toward production, remove that assumption, letting an identity carry proof of who it is into a relationship the organization never directly provisioned.

KuppingerCole Analysts' advisory note on Identity at the Speed of Business: From Architecture to Organizational Value makes the business case directly, arguing that shifting IAM from one-off projects to continuous, service-oriented delivery is what lets identity keep pace with the speed at which the rest of the business now moves. Faster onboarding, better policy enforcement, and fewer manual exceptions are the point of this shift, not incidental side effects of it.

None of this works if every partner and platform needs its own integration project. This is why orchestration exists inside the Identity Fabric as a distinct layer rather than a feature bolted onto a single tool.  A fabric that can route a request through the right sequence of checks, whatever the source, scales in a way that direct, tool-to-tool integrations never will. Decentralized identity and wallet-based credentials push that same logic outward, letting proof of identity move with the person or system rather than staying locked inside one organization's directory.

Where the Theory Gets Tested

There is a real difference between reading an advisory note and watching architects and CISOs argue over how it holds up in production, and that is exactly what is on offer at KuppingerCole Analysts' Identity Fabric Impact Day, taking place on September 9 in Cologne, Germany.

The agenda is designed to address every challenge raised above. A dedicated Futureproofing IAM track runs alongside sessions on evolving the Identity Fabric itself. Ping Identity's Matthew Berzinski is to give a presentation on establishing continuous trust across the extended workforce, the exact population this post has argued a fabric built only for full-time employees cannot cover.

Fraunhofer IAO's Isaac Henderson and Fraunhofer FIT's Wolfgang Prinz follow will discuss decentralized identity as organizational infrastructure, and John Erik Setsaas of Setsaas Trust Advisory will close the loop with a look at what the EUDI Wallet actually means for a working Identity Fabric. That pairing is important because portable, wallet-based credentials are the clearest test of whether an organization's fabric can extend trust beyond its own perimeter, or whether it only ever worked inside one.

And Martin Kuppinger, who created the Identity Fabric model, will take questions directly from the floor in an "ask the creator" session.

Build the Architecture Before You Need It

Future-proofing IAM means adopting an architecture, the Identity Fabric, that absorbs new identity types, new trust relationships, and new governance demands without breaking, rather than buying a newer version of the same tool.

Three things worth prioritizing:

• Treat NHIs and agentic identities as a distinct governance problem.
• Build orchestration that extends trust beyond your own perimeter.
• Start from a reference architecture rather than a shopping list.

Identity Fabric Impact Day 2026 puts the analysts and practitioners solving these exact problems in one room. Register now to be part of the discussion.

Recorded live at the European Identity and Cloud Conference in Berlin, Berthold Kerl speaks with Connie McIntosh, Head of Security at Ericsson, about what post-quantum readiness actually demands from security leaders. Connie brings a distinctive perspective: Ericsson operates as both a global enterprise and a critical infrastructure provider, meaning quantum exposure runs in both directions.

The conversation covers the migration complexity most organizations underestimate, the supply chain dependencies that create the weakest links, how to quantify quantum risk for board-level conversations, and the single most important step any organization should take immediately.

Topics covered: Post-quantum cryptography, harvest now decrypt later, cryptographic bill of materials, crypto agility, supply chain risk, NIS2 and European regulation, critical infrastructure, board-level risk communication.

That question deserves more weight in any tool decision, across IT generally and identity and cybersecurity specifically, even though it is one consideration among several rather than the one asked first. Every tool decision creates two kinds of barrier: an entry barrier, the cost and effort of getting a tool in, and an exit barrier, the cost and effort of getting it out again. Organizations routinely price the first. The second stays unexamined, or in some cases is quietly ignored, because looking at it closely would complicate the case for buying in the first place.

The reasons for skipping the question are understandable, even if they are not good reasons. Investments have to be justified, and “this is a tactical choice we may replace in three years” does not help a budget approval move forward. Implementation itself carries cost, switching carries cost again, and every new tool demands training that the second question makes look wasted before it has even started. None of that makes the avoidance defensible. It only makes it explainable.

Two Risks, Not One

Lock-in gets discussed as a single problem. It is at least two, and they respond to different remedies.

The first is contract leverage. It determines how short a contract term you can negotiate, how favorable an exit clause you can secure, and how much audit and negotiation power you retain once the contract is signed. This matters because your practical ability to leave a tool is not fixed by the tool itself. It is partly set by how much negotiating power you had on the day you signed, and that power scales with the buyer’s own size and market position relative to the vendor. A large enterprise negotiating with a mid-size vendor typically has more room here than a smaller buyer facing a dominant vendor.

The second is data portability, and it does not scale the same way. A vendor’s willingness to grant a favorable exit clause is worth little if the underlying data model, export formats, or API access make actual migration difficult by design. Size and negotiating skill do not fix a closed data model. If portability turns out to be difficult once you look closely, that alone is reason for caution, independent of how good the contract terms otherwise look.

Due diligence that treats these as one question tends to solve the easier one, the contract, and miss the harder one, the data.

The Switching-Cost Myth, With a Real Exception

Switching cost is frequently overestimated in a specific way: organizations assume the second implementation of a tool category costs close to what the first one cost, because the first one required steep training and unfamiliar concepts. It usually does not. A lot of what was learned carries over. Roles, policies, and integration inventories built for the first tool are largely reusable for the second, and the mistakes made the first time round become exactly the lessons that make the second implementation better, not a debt that has to be repaid again.

IGA benefits from this effect as much as any other category. A second implementation reuses role models, access policies, certification workflows, and the integration inventory built for the first, and it avoids the governance mistakes that took years to surface the first time round. None of that has to be redone from a blank sheet.

What it does not avoid is the scale of the exit barrier itself. IGA implementations commonly run as multi-year projects, and replacing one is a multi-year project again, which is exactly why the six-to-ten-times attachment rate matters: learning effects shorten the project, they do not make a deeply embedded identity or infrastructure tool cheap to leave. Understanding where a given tool sits on that spectrum has to happen before the purchase, not at renewal, when the vendor holds most of the useful information about how hard leaving will actually be.

Bigger Is Not the Same as Safer

The instinct to manage this risk by choosing the largest, most established vendor available is itself worth questioning. Dominant vendors change roadmaps. They discontinue products, force customers onto new licensing models, or get acquired and adjust terms unilaterally. A buyer with no exit plan is exposed to those decisions regardless of how strong the vendor’s market position looked at signing.

Exit readiness is not only protection against your own future regret. It is protection against choices the vendor makes that you do not control.

Not Every Tool Deserves the Same Scrutiny

The same logic applies regardless of the deployment model: on premises, cloud, or AI service. What looks like the preferred tool today may not hold that position for long, and the market for AI tools makes the point concretely. A year ago, the default assumption in many organizations pointed to one large language model provider; today it may point to another, and this is unlikely to be the last shift. The faster a category evolves, identity and cybersecurity tooling included, the more costly it becomes to stay locked into yesterday’s choice.

That does not mean applying equal scrutiny everywhere. A public sector body that spends its political capital moving off one office suite and onto another is solving the easy problem. Office tools are comparatively straightforward to replace. The switch that actually determines whether an organization can adapt to what comes next sits in its core business applications, its infrastructure, and its identity and cybersecurity stack, where sophisticated data and access models make replacement genuinely difficult. Scrutiny should track that difficulty, not the visibility of the decision.

Deliberate lock-in, chosen with the question already asked and answered, is a reasonable outcome. It stops being reasonable the moment the question was never raised at all.

Before signing anything, this should be standard practice:

• Separate the contract question from the data question. Negotiate exit terms based on your position relative to the vendor, and test data portability on its own merits regardless of how favorable those terms look.
• Ask for the export path before you need it. A documented, testable data export process at onboarding is worth more than a promise buried in a termination clause.
• Do not treat vendor size as an exit strategy. A dominant vendor’s roadmap changes and acquisitions are risks you carry whether or not you ever plan to leave voluntarily.
• Match scrutiny to switching difficulty, not visibility. An office suite decision and a core identity platform decision do not deserve the same amount of exit analysis.
• Price the second implementation honestly, factoring in what carries over and what does not, rather than assuming it costs what the first one did.
• Treat a knowingly accepted lock-in as acceptable. The problem was never lock-in itself. It was never asking.

None of this makes switching free, and none of it argues against tools that come with some degree of attachment; every solution has some. It argues for knowing the size of that attachment before you accept it, not after a renewal notice arrives with a number attached that nobody planned for.

If your organization cannot answer how it would leave a given tool today, that is not a minor gap in the paperwork. That is the actual risk profile of the decision, and it was there from day one.

This is exactly the kind of due diligence question we work through with clients in KuppingerCole’s advisory practice on identity, cybersecurity, and AI tool selection.

Key Topics:

✅ IVIP revisited: still a set of capabilities, not a platform — and vendors are mostly relabeling
✅ Can AI make IVIP obsolete before it ever becomes a mature category?
✅ How AI is finally tackling IGA's oldest unsolved problem: application integration at scale
✅ Why IVIP falls short on action — spotting anomalies is not the same as acting on them
✅ IVIP, ITDR, and IGA convergence: does the category distinction even matter anymore?
✅ Strategic advice for IVIP vendors: observability, automation, and the path to relevance

🤖 "The MVP can frequently be done well with AI doing it at scale, manageable, as a real solution and not a set of homegrown tools? That is a very different story." Martin Kuppinger on why AI changes everything for IVIP — and nothing at once.

📅 Don't miss the KuppingerCole Analysts Identity Fabric Impact Day on September 9th in Cologne 

In this exclusive webinar, INCYBER and KuppingerCole deliver a comprehensive macro-economic and technical analysis of the European cloud market. Our featured expert, Mike Small (Senior Analyst at KuppingerCole), breaks down the current landscape, geopolitical threats, operational resilience, and the 4 critical control zones you need to know.

Enterprises are rapidly assembling a new digital workforce of autonomous AI agents. Unlike conventional applications, these agents can plan tasks, invoke tools, access data, collaborate with other agents, and write to business systems. They are one part software workload and another part human-like, acting with delegated authority but often without clear ownership and accountability.

OutSystems’ 2026 State of AI Development report found that 96% of surveyed organizations were using AI agents in some capacity, while 94% were concerned that AI sprawl was increasing complexity, technical debt, and security risk. Yet many organizations still cannot answer basic questions: What agents exist? Who owns them? What identities and permissions do they use? Which systems and data can they reach? What actions have they performed? Agent security and governance must therefore begin with continuous discovery.

AI Agents Create a Different Visibility Problem

Most business system inventories were designed to support relatively stable categories such as employees, applications, service accounts, cloud resources, and devices. AI agents do not fit neatly into any of these categories. Classifying an agent as human or non-human does not tell you enough on its own. The question that matters is what the agent can do, under whose authority, and with what potential impact. Three terms get used interchangeably in this discussion, and the difference matters. Discovery establishes that an agent exists and who owns it. Visibility describes the identity, permissions, and connections it holds. Observability tracks what it actually does once running.

Shadow AI Is Being Driven by Shadow Agents

Shadow AI has moved beyond employees using unauthorized chatbots. Developers, business units, automation teams, and individuals build agents through SaaS applications, low-code platforms, agent development environments, and other productivity tools. These agents may be useful, but they can be deployed without review by IT, security, privacy, or governance teams. Prohibiting them outright may simply push their use further underground.

The visibility gaps are significant. Organizations may not know an agent’s owner or purpose, which applications it connects to, whether its OAuth or API access is excessive, what sensitive data it can reach, or whether an orphaned agent retains valid credentials. They may also miss behavioral changes after deployment. This lack of knowledge about agent existence, ownership, access, and activity is becoming the central shadow AI challenge.

Why Traditional Asset and User Inventories Are Not Enough

CMDBs, IAM systems, directories, SaaS applications, and cloud asset inventories provide useful pieces of the agent picture, but rarely the complete view. A meaningful inventory must connect each agent to its creator, owner, purpose, service accounts, OAuth grants, API tokens, secrets, applications, APIs, MCP servers, tools, data sources, parent agents, sub-agents, delegation relationships, and runtime activity.

The Salesloft Drift compromise of August 2025 showed what that gap costs. Attackers stole the OAuth tokens that Drift’s AI chat agent used to reach customers’ Salesforce environments, then queried records as the trusted application without a password or an MFA prompt. Google put the number of affected organizations at more than 700. Drift was a sanctioned integration in every one of them, and the exposure sat in permissions and connections that no conventional asset or user inventory tracked.

The inventory also cannot be a static register. Agents can be created, modified, duplicated, or decommissioned much faster than traditional applications or human users. A quarterly assessment will be outdated before it is completed. Governance therefore requires a continuously updated graph of agents, identities, permissions, connections, and actions.

What Continuous Agent Discovery Must Provide

Effective agent discovery should provide five essential capabilities:

• Broad coverage. Discovery should include sanctioned and unsanctioned agents, developer-built agents, embedded SaaS agents, personal agents, and agents created within automation tools.
• Identity context. Organizations must understand what identity an agent uses, whose authority it inherits, and whether its permissions are appropriate for its purpose.
• Relationship mapping. Discovery should show how agents connect to human users, sub-agents, applications, tools, APIs, credentials, and data.
• Runtime correlation. The inventory must connect each agent to what it does, rather than merely showing where it was registered or how it was configured.
• Lifecycle monitoring. Security teams should identify newly created, modified, inactive, abandoned, and unusually behaving agents. 

From Discovery to Governance

Agent discovery is not the final objective. It is the foundation for observability, behavioral monitoring, policy enforcement, threat detection, audit evidence, and remediation. Once organizations know what agents exist, they can assign owners, validate purpose, review permissions and connections, identify excessive or stale access, apply risk-based policies, monitor behavior, generate evidence, and terminate unsafe agents.

Agent discovery and observability systems should then feed IAM, SaaS security, SIEM, data security, AI governance, and incident-response processes rather than becoming another isolated system. Emerging AI Agent Visibility and Observability Platforms (AI-VOP) extend discovery and observability into runtime telemetry, interaction mapping, behavioral analytics, explainability, policy enforcement, containment, and remediation.

Visibility Precedes Observability

Organizations cannot secure, govern, or audit agents they do not know exist. Continuous discovery should become an immediate AI security and governance priority rather than hoping for AI adoption to become centralized or standardized. The organizations best positioned to benefit from agentic AI will not impose the strictest prohibitions. They will continuously discover agents, understand their authority and behavior, and apply appropriate controls without hindering innovation.

This is why KuppingerCole Analysts is launching new research focused on AI-VOPs and the emerging market and vendors providing them. As agents become more autonomous and more deeply connected to enterprise systems, visibility must precede observability and control. Two related pieces are available to KuppingerCole subscribers: Agent Visibility and Observability Platforms (AVOP), a Leadership Brief, and Navigating the Agentic AI Security Landscape, an Advisory Note.

That comes from The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web, a paper accepted at the 35th USENIX Security Symposium by a team from Ruhr University Bochum, Heilbronn University of Applied Sciences, and the University of Wuppertal. Eighteen of those sites carried a critical-severity vulnerability. Fifty-three carried a high-severity one.

If you have rolled out passkeys in the last two years, that number deserves a pause. It does not mean passkeys are a bad idea. They remain the strongest authentication most organizations can realistically deploy, and I would still tell any buyer to move toward them.

But it does expose something the market has not been asking about. So: what failed, why does it keep failing, and what belongs in your next vendor conversation?

First, a reset: the protocol is not what failed

FIDO2 and WebAuthn are sound. The cryptography works. Nobody has broken passkeys.

What the researchers measured is a different thing entirely: they measured whether the relying party (your website, your enterprise application, your identity provider) correctly performs the verification steps the standard asks of it.

Those steps are numerous, and they belong to the relying party alone. No browser enforces them. No authenticator enforces them. If you skip one, nothing complains.

There is a FIDO server certification program, and it does test conformance against the Alliance's Server Requirements specification. But look closely at what it certifies: an implementation submitted for testing, at a point in time. Not the production deployment you are actually running, and not as a required step on the way to going live. Nothing obliges a relying party to pass it before shipping.

So what did that produce in practice?

What actually broke

Among the 103 sites tested:

• 5 skipped signature verification entirely. The researchers confirmed it by signing into victim accounts. The signature is the step where the cryptographic guarantee actually lives; everything else in the flow is choreography around it.
• 22 did not properly validate the challenge, the randomized value that ties a login attempt to one specific session. Without that binding, a captured or injected response can be replayed.
• 57 ignored the signature counter, the mechanism designed to reveal a cloned authenticator.
• A novel "credential overwrite" attack worked against relying parties that mismanage the relationship between user identifiers and credential identifiers, letting an attacker register a credential that appears to belong to both attacker and victim.
• All but one site requested deprecated cryptographic algorithms. Only 90 of 208 relying parties used the recommended ones.

Not one of these is a protocol weakness. Each one is a server-side implementation choice, invisible to the user, and invisible to the buyer.

Why this keeps happening

Three reasons, and none of them is about careless engineers.

1. The specification puts the heaviest verification burden on the party least equipped to carry it. The relying party has to perform a long sequence of checks, correctly and in order, with no runtime feedback when it does not. A missing check produces no error. Authentication simply succeeds.
2. There is no conformance test in the deployment path. You can integrate passkeys, watch logins succeed, and ship. Success looks identical whether or not the signature was verified. Server certification exists, but it is optional and sits outside the normal delivery pipeline.
3. The library and platform ecosystem is uneven. Some SDKs handle validation end to end. Others expose primitives and leave the sequencing to whoever is integrating. Buyers rarely know which one they bought, because that distinction does not appear in the documentation procurement teams read.

The failure distribution backs this up. The researchers expected weaker validation on less popular sites, given how complex the standard is. They found the opposite: higher-ranked sites were more susceptible than lower-ranked and unranked ones.

That is not a story about sloppy small teams. It is what complexity looks like when it scales with integration surface: bigger sites carry more authentication paths, more legacy flows, and more places for a check to quietly go missing.

For the record, the authors disclosed critical and high-severity findings to 61 affected websites, and vendors had at least six months to remediate before publication.

What this changes for buyers, starting with me

Most passkey procurement today looks at the authenticator, the user experience, the recovery flow, and the IAM integration. All of that matters. But the highest-severity failures in this study sit in a layer nobody is currently asking about. That layer is testable.

I want to be direct here, because this lands on my own work before it lands on anyone else's. Last year I benchmarked passwordless vendors for our Leadership Compass Passwordless Authentication for Enterprises. I weighted enrollment, recovery, device trust, and IAM integration. I did not ask a single vendor to demonstrate that its relying party verifies the signature on every authentication. There was no public test artifact to assess it against.

There is one now. The tooling is public, along with the full catalog of 15 attack types and 28 detection methods. You can run these checks against your own deployment, or make your vendor show you the results.

Questions worth adding to a passkey evaluation

1. Which of the WebAuthn specification's server-side validation steps does this implementation perform, and can you show test evidence rather than a compliance statement?
2. Is signature verification performed on every authentication, and how has that been independently confirmed?
3. How is the challenge generated, bound to the session, and validated on return?
4. How does the system enforce that each credential belongs to exactly one user?
5. Is the signature counter checked, and what happens when it regresses?
6. Which cryptographic algorithms does the relying party request, and are any deprecated?
7. Can a registered passkey be deleted, and can a user hold more than one? Some sites in the study allowed neither, which is a recovery problem and not only a security one.

If a vendor answers "we are FIDO certified," they have answered a different question. The same goes for a policy setting that reads "phishing-resistant MFA enforced". That describes how a credential was enrolled, not whether the resulting authentication is checked properly.

The bottom line

Three things to take away. Passkeys are still the right direction, and if you are still on passwords you have a bigger problem than anything in this paper. The security of a passkey deployment is a property of your implementation, not of the protocol, and it does not appear on any datasheet. And because the researchers published their tooling, that property is now something you can test instead of assume.

To be unambiguous about it: nothing in this paper is a finding against WebAuthn, FIDO2, or the certification programs built on them. The specifications held. What failed is the code that implements them, one relying party at a time. That is a harder problem than a broken protocol in some ways, because there is no patch to apply centrally, but it is also the kind of problem a buyer can actually act on.

For where passkeys work and where they do not, see our Advisory Note Passkeys in Practice. To review your own deployment against these findings, talk to a KuppingerCole advisors.

Sean O’Dell, in his post You Already Have the Pieces, Now Build It, argues that enterprises can secure AI agents by treating them as dynamic workloads and assembling existing standards, including SPIFFE, OAuth, transaction tokens, gateways, and shared security signals, into a coherent identity, authorization, and assurance architecture.

Phil Windley, in his Agentic AI and Dynamic Authorization series, makes two important observations. First is that authorization cannot sit at the edge as a one-time check; instead, it must be embedded in the agent’s decision loop. The other is that delegation in agentic systems must be explicit, structured, and bounded so that authority can narrow safely as agents delegate to subagents or external domains while preserving control, trust, and auditability across the full chain.

Both shaped the practical approach I set out below. That begins with inventory.

Inventory Is the Foundation

The first step in an agentic identity strategy is not selecting a platform. It is building an inventory of agents.

That may sound administrative, but everything else depends on it. An enterprise cannot assign an identity to an agent it does not know exists. It cannot define authority without understanding the agent’s purpose. It cannot write meaningful policy without knowing which tools the agent can invoke. It cannot monitor behavior without knowing which credentials, APIs, data sources, and runtimes belong to it. And it cannot revoke access during an incident if nobody knows where the agent runs or how it authenticates.

No inventory means no ownership. No ownership means no accountability. Without accountability, an agentic identity strategy is mostly an architecture diagram.

Agents are already arriving through SaaS platforms, developer tools, low-code environments, workflow systems, security automation, internal AI projects, and Model Context Protocol integrations. Some look like ordinary features until someone realizes they can select tools, call APIs, delegate work, or act without direct approval.

The first enterprise objective should therefore be simple: know which agents exist, who owns them, where they run, what they can reach, and how to stop them.

Build a Living System of Record

The inventory should connect each agent’s business purpose to its identity, authority, dependencies, and lifecycle.

Each production agent should have a unique identifier, business and technical owners, an accountable sponsor, a documented purpose, a risk tier, and an approved environment. The record should also capture its runtime, data access, tools, APIs, MCP servers, workload identities, service accounts, OAuth grants, tokens, secrets, approved actions, logging location, and revocation method.

This information drives every later control. Identity teams learn what identity must be issued. Authorization teams learn what policies are needed. Data governance learns which restrictions apply. The SOC learns what telemetry to monitor. Audit learns who is accountable. Incident responders learn what must be disabled.

The inventory is not an administrative byproduct. It is the seed of the agentic control plane.

Enterprises should not wait for a product that can discover every agent. Cloud inventories, CMDBs, application portfolios, gateways, CI/CD pipelines, endpoint telemetry, identity systems, PAM platforms, SIEM data, and procurement records can all contribute.

Start with known production agents, especially those that access sensitive data, change production, modify entitlements, use privileged credentials, communicate externally, or update systems of record. Manual registration will be necessary at first. Make it part of production onboarding and automate discovery progressively.

Start With Workload Identity

Once an agent has been inventoried, the next question is how it should be identified.

A useful starting point is to treat agents as workloads. Agents can pursue broad goals, select actions dynamically, cross trust boundaries, and invoke subagents, so their risk profile stretches traditional non-human identity assumptions. Even so, workload identity is much stronger than hiding an agent behind a generic service account. The claim is not that an agent is merely a workload; it is that workload identity is the most mature primitive available today, and a far better foundation than a shared service account while agent-specific models mature.

An agent should have its own attributable identity tied to its inventory record, owner, purpose, runtime, environment, permitted tools, risk tier, delegation boundaries, and lifecycle state. The identity should represent the agent as an enterprise actor, not merely the server on which it executes.

Use SPIFFE IDs and SVIDs

SPIFFE offers a compelling model for workload identity.

A SPIFFE ID is the identifier assigned to the workload. It is represented as a URI within a defined trust domain. An SVID, or SPIFFE Verifiable Identity Document, is the cryptographic credential the workload uses to prove that it is entitled to that SPIFFE ID.

In simple terms, the SPIFFE ID says who the agent is. The SVID proves that identity. The inventory explains what the identity represents. Authorization policy decides what the agent may do.

An enterprise might use an identifier such as:

spiffe://enterprise.example/agents/security/alert-triage

The identifier should not attempt to encode every authorization decision. Policy still needs to consider delegated purpose, requested action, target resource, data classification, workflow state, risk signals, and approvals.

Every SPIFFE ID should map back to an authoritative inventory record. A cryptographically valid identity is not automatically an authorized identity. The enterprise still needs to know whether the agent is active, who owns it, where it may run, and what it may do.

SPIFFE establishes workload identity. The inventory supplies governance context. Authorization connects the two.

Preserve Dual Attribution

Treating an agent as a workload does not eliminate the need to identify the person or process behind its actions.

Enterprises should preserve dual attribution: the human, application, workflow, or business process that initiated the work, and the agent that performed it.

An audit trail should show who initiated the task, which agent accepted it, what authority was delegated, which tool was invoked, which policy governed the action, and which resource was affected. Workload identity tells us which agent acted. Delegation tells us on whose behalf it acted and why.

This is an important distinction because a generic service account rarely tells the whole story. It may authenticate the software, but it does not necessarily explain why the action occurred, who requested it, or what limits were placed on the agent.

Assemble What You Already Have

One of the most useful observations in Sean O’Dell’s work is that agentic identity is not only a standards gap. It is also an assembly gap.

Enterprises already operate many of the necessary components. The challenge is connecting them into a coherent model.

CMDB and application portfolio systems can provide the initial inventory. Workload identity and PKI can issue and validate agent identities. OAuth can provide short-lived, narrowly scoped access tokens. API and MCP gateways, service meshes, and tool brokers can become enforcement points. Existing policy engines can evaluate identity, delegation, resource, risk, and workflow context.

Identity governance platforms can assign owners and support reviews. PAM and secrets management can protect credentials. SIEM and ITDR capabilities can correlate the initiator, agent identity, delegation record, tool invocation, authorization decision, target resource, and result. CI/CD pipelines can prevent promotion into production unless ownership, identity, logging, and revocation requirements have been satisfied.

Not every existing system is agent-ready, but most enterprises already have many of the building blocks and can extend them instead of waiting for a completely new stack.

Put Authorization Inside the Agent Loop

Inventory and identity are only the beginning. Agents are given goals rather than single transactions. They may gather information, revise plans, call several tools, and delegate work. A one-time authorization decision at login or onboarding is insufficient.

Authorization should be evaluated before each meaningful action, especially when an agent accesses sensitive data, invokes a privileged tool, changes production, modifies entitlements, exports information, sends an external communication, accesses credentials, or performs an irreversible action.

A practical control loop begins when a person, application, or workflow initiates a goal. The agent and its workload identity are resolved through the inventory. A bounded delegation record is created. The agent plans within known constraints. Sensitive tool calls are intercepted by an enforcement point, which asks a policy engine to evaluate identity, delegation, tool, resource, context, risk, and workflow state.

The result may be permit, deny, constrain, rate-limit, escalate, or require approval. The decision and action are recorded, and delegated authority expires when the task ends or is revoked.

The model may be told what boundaries apply, but it should not enforce them.

Planning can be probabilistic. Enforcement must be deterministic.

Make Delegation Explicit

An agent should not automatically inherit every permission held by the user who invoked it.

Delegation should define who granted authority, which agent received it, what task is being performed, which actions and tools are allowed, which resources may be affected, how long the authority lasts, whether human approval is required, whether subdelegation is permitted, and how the authority can be revoked.

These facts should be structured, policy-evaluable data rather than information hidden inside a prompt.

Impersonation says the agent is effectively the user. Delegation says the agent has limited authority for a defined purpose and period.

Agentic identity should be built around delegation.

This becomes even more important when agents invoke subagents. A subagent should normally receive narrower authority than the parent agent, not inherit everything available to it. When delegation crosses into a vendor platform or another external trust domain, the enterprise will also need stronger assurance, logging, contractual commitments, and restrictions on onward delegation.

Begin With a Minimum Viable Architecture

A first implementation does not need to solve every future agentic pattern.

A practical minimum viable architecture can begin with:

1. An inventory containing the agent’s owner, purpose, tools, data access, and risk tier.
2. A SPIFFE ID identifying the agent workload.
3. An SVID providing cryptographic proof of that identity.
4. A bounded delegation record describing the authority granted for the task.
5. An API or MCP gateway intercepting sensitive tool calls.
6. An existing policy engine evaluating the action.
7. Short-lived OAuth tokens or brokered credentials.
8. SIEM logging that records the identity, decision, action, and result.
9. A tested method for revoking the agent’s authority.

Choose useful but constrained pilots: a read-only knowledge agent, a security triage agent that cannot contain systems, a coding agent that cannot merge or deploy, or a data agent that cannot export regulated information. Use them to test discovery, ownership, workload identity, bounded delegation, policy enforcement, logging, and revocation.

The objective of these pilots is not merely to prove that the agent works. It is to prove that the enterprise can govern it.

Start by Assembling

Agentic identity creates genuinely new challenges, but enterprises are not starting from nothing. They already have inventories, identity platforms, gateways, policy engines, privileged access and secrets management, CI/CD, and incident response.

The first task is to find the agents and connect them to those controls.

From there, treat agents as attributable workloads. Give them SPIFFE IDs and use SVIDs to provide cryptographic proof. Preserve the connection to the human or process that initiated the work. Make delegation explicit. Enforce policy at the tool boundary. Record the full decision chain. Design revocation from the beginning.

The standards and products will continue to evolve. Enterprises should follow that work, but they should not wait before starting.

You probably already have many of the pieces. First, build the inventory. Then start assembling.

KuppingerCole Analysts perspective: This post starts from workload identity. Martin Kuppinger cautions against that framing. Agents aren't just another non-human identity, he argues, given their varying autonomy, the distinct differences between invocation, delegation, and impersonation, and the entity-vs-instance nature of "ephemeral" agents.

 Watch this Analyst Chat for the full argument.

Key Topics:

✅ Why the "digital sovereignty" conversation has gone wrong — and what Alcatraz has to do with it
✅ The only correct definition of sovereignty: can you keep operating when a dependency disappears?
✅ Why sovereignty is just business continuity engineering — not a procurement decision
✅ How sovereign Europe really is today: the numbers are worse than you think
✅ Why "buy European" is a political preference, not a security strategy
✅ Decentralization, crypto agility, and distributed storage as practical sovereignty tools

🏛️ "Sovereignty is not about who you're buying from, it's about what happens when you can no longer buy from them." Alexei Balaganski on why the European sovereignty debate is asking the wrong question entirely.
🔐 "Nobody, not even the EU, should prescribe how to solve your sovereignty issues." A rare episode with almost no AI but possibly the most important conversation KuppingerCole Analysts has published this year.

What Happened

On 28 July 2026, Cyera announced that it had signed a letter of intent to acquire Oasis Security. Cyera frames the deal as uniting data security and identity security into a single control point that determines what every human, machine, and AI agent is permitted to see and do.

A caveat first. This is only a letter of intent so terms have not been formally disclosed. Cyera also states in its announcement that Non-Human Identities (NHIs) inside Fortune 500 organizations grew by nearly 500% in the last six months. That is the acquirer’s own figure, offered without published methodology, and we would not build a business case on it. The trend itself is well documented in our own research: machine and agent identities are outpacing human ones. The specific growth rate is not.

Our Take

The architectural argument for this deal is valid even if the price is too high.

Authorizing an AI agent requires two things that have historically lived in different products and been bought by different teams. You need to know how sensitive a given data asset is, which is what data security posture management does. And you need to know which identity holds the credential reaching for it, who owns that identity, and whether it should still exist, which is what non-human identity management does. Neither discipline can answer the question that actually matters when an agent acts autonomously at machine speed: should this non-human identity be able to read this record right now? Cyera is making a credible claim that the answer requires both halves in one system.

The gap is real, and Cyera is not the only one who has spotted it. Microsoft, Palo Alto Networks and CyberArk are converging on the same control point from different directions, so moving early is defensible.

Where we are more skeptical is the price and the direction of the integration. Asking identity teams to govern machine identity from a data security tool is the hardest thing this deal has to prove.

The Price Is the Story

Six weeks before this announcement, SailPoint agreed to acquire Entro Security, another Israeli NHI specialist, for a reported $200 million. The comparison is instructive.

We want to be careful here, because the two companies were not the same size. Oasis had raised roughly $195 million against Entro’s $24 million and was almost certainly the larger commercial business, so some of the gap reflects genuine scale. But not five times. The rest is being paid for the agentic AI narrative and for strategic fit with a platform story, using the currency of a company valued at $12 billion on more than $150 million of annual recurring revenue: roughly an 80x multiple, on a business that TechCrunch reports is not profitable.

Two further facts bear on the number. Accel and Cyberstarts are investors in both Cyera and Oasis, so this is not a clean arm’s-length price discovery event. And Cyera raised $600 million weeks ago and is now committing a reported $700 million in cash; in effect, the round is funding most of the cash consideration. Neither point makes the deal unwise. Both mean the $1 billion figure should not be treated as an independent market valuation of NHI technology.

Where This Deal Will Be Won or Lost

• Buyer mismatch. Oasis sells to identity and IAM teams. Cyera sells to data security, privacy and compliance functions. The budget holders, procurement cycles and internal champions are all different. It is the most common reason otherwise sensible security acquisitions underperform, and a shared platform diagram does not fix it.
• The independent-unit hedge. Oasis is expected to run as a separate unit after close. That protects near-term revenue and customer continuity, but it also defers the unified control plane the deal is premised on. The value thesis and the integration plan are pulling in opposite directions in year one.
• Overlap with what Cyera already shipped. Cyera already offers an identity module covering human and non-human access to data. The company is therefore replacing or deepening something it built rather than filling an empty space, which raises the bar for demonstrating what customers actually get that they did not have before this deal.
• A missing substrate. Our Non-Human Identity Management Leadership Compass named nine Overall Leaders, and every one of them is an established identity, PAM, or secrets vendor: AppViewX, BeyondTrust, CyberArk, Delinea, HashiCorp, Keeper Security, Kron, Microsoft and One Identity. Depth in this market currently correlates strongly with owning the underlying substrate: a credential vault, certificate lifecycle management, or both. Neither Cyera nor Oasis is a secrets management vendor, and prospective buyers should establish exactly which vaulting and PKI dependencies the combined platform carries before treating it as a like-for-like alternative to those nine.
• Integration bandwidth. This is the third acquisition Cyera has announced in 2026. Absorbing three companies in a year while scaling a platform is an execution load that deserves scrutiny from prospective customers, not just from investors.

What It Means for the Market

NHI management is closing as a separate purchase, not as a discipline. The capability still has to be evaluated, but as it moves inside platforms the category needs a wider definition and probably a different name. Entro has gone to SailPoint, Oasis is going to Cyera, and 1Password acquired Apono for a reported $250–300 million. Enterprises evaluating non-human identity in the second half of 2026 should be choosing the platform they want to govern identity from, not a point tool, because that is the decision that will actually persist.

That choice is now contested, which is the more interesting consequence of this deal. The conventional path runs through the identity platform: SailPoint with Entro, CyberArk, Delinea, Microsoft Entra. Cyera is arguing for something less conventional: govern agent access from the data layer outward. For organizations whose principal exposure is sensitive data reachable by agents, that is a coherent proposition. For organizations that already run mature IGA and PAM programs, governing machine identity from a DSPM tool will be a harder sell internally, and we expect most large enterprises to keep identity governance anchored in their identity platform.

What Comes Next

New security categories are usually swallowed by platforms about eighteen months after they become visible. It happened to CASB in 2017, to SOAR in 2018 and 2019, and agent threat detection followed last year, when seven vendors in agentic security were acquired between September 2024 and the end of 2025, five of them in threat detection alone.

NHI management is at the same point now. Companies in these waves acquire rather than build, so the identity platforms that have not moved yet are the ones to watch, along with SentinelOne and CrowdStrike, neither of which has bought fully integrated agent security. Independent innovation moves on with it, most likely to agent governance and audit, where the EU AI Act rules that take effect in August have created budget that no acquirer has taken yet.

For buyers, the risk is dilution. Products bought this quickly tend to lose features as they are folded into a platform, so a shortlist drawn up before the deal will not match what ships. Prospective buyers should test any acquired platform against their own agent workloads and ask which parts of the roadmap survive alongside what the acquirer already sells.

Recommendations

• Oasis customers: take no action yet. This is a letter of intent. At your next renewal, get written roadmap and support commitments, confirm which secrets management dependencies persist, and establish whether your account moves to a Cyera commercial motion.
• Organizations evaluating NHI management solutions: do not price “agentic” branding as capability. Test candidates on discovery coverage across your actual estate, ownership attribution for orphaned identities, credential rotation, and clean decommissioning. These unglamorous capabilities are what separated leaders from entrants in our assessment.
• Existing Cyera customers: ask what the acquisition delivers beyond the identity module you already have, and on what timeline. “Independent unit” and “unified platform” cannot both be true in the first year.
• Vendors and investors in this segment: the window for independent non-human identity exits is narrowing, and this transaction sets an expectation that will be difficult for the next seller to meet. Assume valuation discipline returns.

Everyone: watch whether this closes on the announced terms. A letter of intent at this valuation, between companies sharing investors, in a market repricing AI assets, is not a certainty.

Privilege in the enterprise is no longer defined by a handful of administrator accounts. It is defined by the ability of an identity to perform actions that affect systems, infrastructure, security controls, or other identities. That shift changes how organizations should think about Privileged Access Management (PAM). The objective is no longer simply to protect privileged accounts but to govern privileged actions wherever they occur.

Historically, PAM focused on administrators managing servers, networks, and enterprise applications. Credential vaulting, password rotation, and session monitoring became the foundation of privileged access security. These capabilities remain important, but they no longer reflect the full scope of privilege within modern enterprises. For more information on this, check out our latest analyst chat.

Today, privileged activity is performed by a growing mix of human and non-human identities (NHIs). Artificial Intelligence (AI) agents, service accounts, Application Programming Interface (APIs), automation pipelines, workloads, and cloud services execute operational tasks continuously, often without human intervention. In many organizations, these machine identities significantly outnumber employees. Because they frequently operate with broad permissions, they have become one of the largest sources of privileged activity across enterprise environments.

Privilege Becomes Dynamic

Cloud platforms, SaaS applications, containers, and API-driven services have transformed enterprise infrastructure into highly dynamic environments. Permissions are granted, modified, and removed continuously as workloads scale and services are deployed. Privilege is no longer tied to a static administrator account. It has become a fluid set of capabilities distributed across identities, policies, roles, and services.

As a result, PAM has expanded. Modern solutions increasingly provide privileged identity discovery, secrets management, policy-driven authorization, Just-in-Time (JIT) access, cloud entitlement management, and continuous monitoring across hybrid and cloud-native environments. Together, these capabilities support least privilege by reducing persistent permissions and ensuring elevated access exists only when required.

This evolution is also reshaping the market. Established PAM vendors now compete alongside identity providers, cloud-native specialists, and broader cybersecurity platforms. At the same time, the boundaries between PAM, Identity Governance and Administration (IGA), Cloud Infrastructure Entitlement Management (CIEM), and Identity Threat Detection and Response (ITDR) continue to blur as organizations seek integrated identity security rather than isolated point solutions. For more information on this, check out our latest Leadership Compass PAM.

Rethinking Standing Privilege

Despite these advances, many organizations still operate under an assumption inherited from traditional IT: privileged access should exist continuously because it may be needed later. Even mature PAM deployments often maintain administrator accounts or service identities with standing permissions that remain available long after their last use.

Zero Standing Privilege (ZSP) challenges that assumption. Rather than asking how privileged access should be protected, ZSP asks whether it should exist before it is actually required. Under this operating model, no human, machine, workload, or AI agent permanently retains privileged permissions. Access is granted only for a specific task, under defined conditions, and only for the time needed to complete that task. Once the work finishes, the privilege disappears automatically.

However, ZSP is not another product category. Organizations cannot purchase ZSP as a standalone solution. Instead, it represents an operating model supported by technologies such as PAM, IGA, CIEM, ITDR, secrets management, and identity fabrics that coordinate these capabilities into a unified architecture. ZSP should therefore be understood as an architectural approach rather than a separate technology.

JIT access plays an important role, but it should not be confused with ZSP. Many JIT implementations grant temporary access to pre-existing privileged accounts or entitlements that remain permanently available. ZSP goes a step further by eliminating persistent privileges wherever possible. The objective is to remove dormant entitlements, reduce the attack surface, and ensure that elevated permissions exist only for the duration of a legitimate operational need.

As enterprise environments become increasingly automated and identity becomes the primary security boundary, the management of privilege shifts from protecting privileged accounts to minimizing privileged access itself. That transition represents one of the most significant changes currently shaping the future of identity security. In the coming weeks, we will publish an Advisory Note on how to achieve ZSP and assess your organization's maturity model.

In this episode of The CISO Perspective, Berthold Kerl speaks with Max Killinger, CIO at BayWa AG and former CTO/CIO of the Hoffmann Group, about the real security challenges of M&A integration. Drawing on nine years navigating the Hoffmann Group's acquisition by Switzerland's SFS Group, Max speaks from direct experience, not theory.

The conversation covers what to look for in security due diligence, how to assess the risks you are buying, the identity decisions that unlock everything else, and how to manage attack surface exposure during the transition itself. Max also addresses one of the most underestimated obstacles in any integration: conflicting security cultures, and what it actually takes to move two expert teams from defending their own environments to building one together.

From Zero Trust maturity gaps to regulatory complexity in multinational environments, this is a frank and practical conversation about what it takes to keep the lights on — and the adversaries out — while two organizations are being stitched into one.

The question should have been easy to answer. It was not.

A few years ago, I took part in a discussion between an application team and the central IAM team. The application owners could explain the individual access rights contained in the role, but they could no longer determine what their combination meant from a business perspective. The people involved in the original role design and application onboarding were no longer available, and the underlying design decisions had not been retained.

At the time, the organization was implementing a new IGA solution. The platform would provide better workflows, a central catalog, and improved governance capabilities. However, it could neither reconstruct the original business intent of the role nor determine whether its combination of access rights was still appropriate. Nor could it assign the missing lifecycle ownership.

The discussion highlighted an IAM challenge we still encounter frequently: the technology was available, but the work required to make it effective had not been clearly assigned.

This article examines seven situations that may initially appear to be technology limitations but are often caused by missing design, execution, or input responsibilities. For each situation, it shows what organizations should diagnose and where they can start.

Across all seven, three questions matter: Who defines how the process should work? Who executes and monitors it? And who provides the data, decisions, and business context required for it to work?

1. Audit Findings Return Despite Process Changes

What is happening?

An audit finding is closed after an additional report, workflow step, or mandatory field has been introduced. Twelve months later, the same weakness appears in another application, business unit, or location.

The individual process may work as designed, but the underlying control is not executed consistently across the organization. This is particularly common when centrally connected applications and locally administered applications follow different procedures.

What should be diagnosed?

• Who owns the control objective beyond the individual workflow?
• Who ensures consistent execution across central and decentralized processes?
• Whose input is required to achieve the desired control objective?

Where should organizations start?

Trace one finding from the control objective through process design and operational execution to the required inputs. This control-to-execution trace helps distinguish a missing report from a missing responsibility.

2. Access Reviews Complete Without Meaningful Decisions

What is happening?

The IGA platform creates the campaign, sends notifications, records decisions, and produces evidence. From a technical perspective, the review is complete. Nevertheless, reviewers approve access rights they do not understand.

The cause is not always unwillingness. Reviewers may lack understandable access descriptions, relevant risk information, or training on what they are expected to assess. A click-through guide can explain which button to press, but not what makes an access decision appropriate.

What should be diagnosed?

• Who defines the review criteria and expected decision?
• Who prepares reviewers and monitors the quality of their decisions?
• Who delivers the input a reviewer needs to make an informed decision?

Where should organizations start?

Perform a review-readiness check before launching the next campaign. Verify that ownership, descriptions, risk context, decision criteria, and reviewer enablement are in place before asking the business to approve anything.

3. Exceptions Lack Clear Decision Authority

What is happening?

Urgent projects, legacy limitations, regulatory variations, and management requests regularly require deviations from standard IAM processes. Several stakeholders may provide input, but no one is certain who can make the final decision.

Adding another workflow does not establish this authority. An exception may also create a permanently different process that must be implemented, operated, monitored, and financed. Many requests become less urgent once these implications are made visible.

What should be diagnosed?

• Who designs the exception process?
• Who may approve the deviation and accept the residual risk?
• Whose input is required to make this decision?

Where should organizations start?

Introduce an exception decision record containing the owner, rationale, implementation effort, operational cost, residual risk, compensating controls, and expiration date. This makes the full cost of the exception visible before it is approved. The decision should then rest with a body of IAM stakeholders who hold the relevant authority for budget, architecture, and operations.

4. Applications Are Connected Without Defined Ownership

What is happening?

Connecting an application to an IGA platform enables provisioning, request routing, and access reviews. It does not establish ownership of the application’s authorization model.

The IAM team can define onboarding standards, offer standard IAM processes and manage technical integration. However, it usually lacks the application knowledge required to define the business meaning of access rights. Application owners, in turn, may understand individual access rights but no longer know why they were combined into a particular role.

Ownership also does not end after onboarding. Access descriptions must be maintained, new access rights introduced, obsolete ones retired, and access roles reviewed when the application or business changes.

What should be diagnosed?

• Who owns the application’s authorization model and its business meaning?
• Who maintains descriptions for access rights?
• Whose input is required to create meaningful and business-oriented descriptions of the access model?

Where should organizations start?

Define an operational application ownership model rather than assigning an owner only for onboarding. Central IAM should support application owners with templates, training, quality criteria, and escalation paths without taking over their business responsibility.

5. Lifecycle Automation Compensates for Poor Source Data

What is happening?

Automated identity lifecycle processes depend on accurate and timely source data. When HR events or attributes are incomplete, delayed, or inconsistent, organizations often add correction logic to the IAM platform.

This may keep the process running, but it shifts responsibility away from the authoritative source. It can also create different versions of the same identity data in HR and IAM.

What should be diagnosed?

• Who defines which events and attributes IAM requires?
• Who is responsible for delivering the required data on time and at the expected quality, and for correcting errors?
• Whose input is required to achieve the desired process goals?

Where should organizations start?

Establish an identity data contract between HR, IAM, and the relevant business stakeholders. It should define required attributes and events, their meaning, delivery timelines, quality expectations, and responsibilities for error resolution.

6. Provider SLAs Are Green While Control Outcomes Are Not

What is happening?

A provider may meet every agreed SLA while the IAM control still fails. The platform is available and tickets are processed on time, but access remains incorrect because application information is incomplete or business decisions arrive too late.

Availability and response times measure provider performance. They do not automatically measure input quality, decision quality, or the effectiveness of the end-to-end control.

What should be diagnosed?

• Who defines the service levels, control objectives, and indicators used to measure them?
• Who monitors SLAs, KPIs, and control effectiveness indicators and who acts on deviations?
• Who provides the customer inputs and business decisions required to achieve the expected control outcome?

Where should organizations start?

Create a responsibility model for each IAM service. Use a RACI matrix to assign provider and retained customer responsibilities for key activities and decisions, and document required business inputs, dependencies, and expected control outcomes alongside it. Together, these elements provide the baseline for the service measurement framework.

Outsourcing execution does not transfer accountability for IAM effectiveness.

7. Manual Processes Break End-to-End Control

What is happening?

Manual IAM processes are not automatically ineffective. They may be appropriate when integration is not feasible or when human judgment is required. The risk arises when handovers are informal, process status is invisible, evidence is inconsistent, and completion depends on individual knowledge.

Differences between centrally connected and locally administered applications are a frequent source of inconsistent control execution. Decentralized processes therefore need to support the same control objectives, even when their execution remains manual.

What should be diagnosed?

• Who designs the end-to-end process, including where automation ends and manual intervention begins?
• Who performs, documents, and confirms each manual step?
• Whose input is required to achieve the desired process goals?

Where should organizations start?

Trace one real transaction through its complete lifecycle. This end-to-end transaction trace often reveals undocumented queues, broken handovers, missing evidence, and unclear escalation paths that are not visible in a high-level process description.

Start with One Capability

A complete IAM organizational assessment can quickly become a large and resource-intensive exercise. A more practical approach is to start with one capability that has a visible challenge, such as Entitlement Management for an application with unclear access rights.

For the selected capability:

1. Define the expected outcome.
2. Identify the tasks required to achieve it.
3. Separate design, execution, and input responsibilities.
4. Assign ownership for each task and outcome.
5. Identify gaps, overlaps, and unclear handovers.
6. Implement the most important improvement.
7. Measure whether the outcome improves.

This exercise may also expose unrealistic IAM job profiles. If strategy, process design, engineering, operations, provider management, and data correction are assigned to one position, the organization may have combined tasks that require fundamentally different skills.

Testing the method on a single application or capability surfaces its practical problems before you apply it across the organization. The objective is not to design the complete IAM organization in the first workshop. It is to understand whether the method produces clearer responsibilities and better decisions.

Technology Still Matters, Within the Right Organization

IAM platforms are essential for scalable automation, integration, risk detection, and compliance reporting. However, IAM platforms can only be effective when the required ownership, processes, inputs, and operational responsibilities are in place.

Before investing in additional technology, organizations should determine whether their current challenges result from missing functionality or from unclear ownership, insufficient input quality, and incomplete process design. Otherwise, the new platform may reproduce the same organizational weaknesses through a more modern interface.

Effective IAM requires suitable technology, clearly assigned responsibilities, and an organization capable of providing the design, execution, and input on which the technology depends.

Continuing the Journey

If you recognize any of these situations in your IAM organization, this article is only the starting point. Over the coming months, we will publish further deep dives into the organizational aspects of IAM and practical ways to address them. Follow the series through our newsletter for the upcoming articles.

If you would like to discuss your current IAM setup or provide feedback on this article, feel free to contact me at pt@kuppingercole.com.

Key Topics:

✅ What actually happened: two separate incidents dressed up as one dramatic story
✅ Why the sandbox failure was a containment and design problem — not an AI apocalypse
✅ Jonathan Care's core argument: the breach was credentials, not packets — you can't firewall your way out
✅ Non-human identity and agent identity as the real unsolved problem at the heart of the incident
✅ Secrets sprawl, overprivileged service accounts, and the absence of least privilege for AI agents
✅ Was it a containment failure, an identity failure, an observability failure, or a governance failure?

🐯 "OpenAI had a pet tiger and the tiger escaped, Hugging Face was just walking down the street." Alexei Balaganski on why the most dramatic AI security story of the year was actually two separate failures.
🔐 Four KuppingerCole Analysts experts, one incident, and the identity governance lessons every organization needs to hear.

Key Topics:

✅ How the Identity Fabric is used in practice: maturity assessments, gap analyses, roadmaps, and tool selection
✅ Why the right order always goes capabilities → services → tools — never the other way around
✅ What happens when tools are used for things they were never meant to do
✅ Why organizing teams around capabilities — not tools — is the future of IT operations
✅ The Identity Fabric built for 2040: long-term thinking in a fast-moving market
✅ How the fabric absorbs buzzwords like IVIP, ISPM, and ITDR — and why that proves the concept

🧵 "Every second day someone comes up with a new buzzword, the Identity Fabric helps you strip it down to capabilities and ask: is there really something new here?" Martin Kuppinger on why structured thinking beats buzzword bingo.

Figure 1: KuppingerCole Reference Architecture highlighting IGA-related capabilities

Modern enterprise environments are dynamic, context-driven and seek almost real-time governance capabilities. Also, organizations now manage identities across complex hybrid environments such as cloud platforms, Software as a Service (SaaS) applications, business systems, and developer environments. Workforce represents only one category of current landscape of identities. Contractors, partners, and Non-Human Identities (NHIs) such as APIs, service accounts, bots, and Artificial Intelligence (AI) agents are increasingly becoming an integral part of business processes.

The scale of this shift is easy to underestimate until it is made concrete. Rubrik Zero Labs' 2025 research puts the ratio of non-human to human identities at 82 to 1 in the modern enterprise, and the same research found that 89% of organizations have already fully or partially incorporated AI agents into their identity infrastructure, with another 10% planning to.

In other words, the NHI-heavy environment is not an edge case reserved for cloud-native shops; it is close to universal. When machine identities outnumber people by that margin, "who has access to what" stops being a JML question and becomes a continuous data-correlation problem.

Identity Data Correlation and Continuous Reconciliation

Most modern organizations understand that access should be governed consistently even when identity information originates from multiple authoritative sources. The difficult part is establishing a reliable picture of “who has access to what” or “who granted that access”, across the entire IT environment.

The challenge has expanded from provisioning users into application to correlating thousands of accounts, resolving ownership, reconciling entitlements, and maintaining an accurate inventory as environments continuously change. Governance decisions can become increasingly complex when handling these different scenarios at the same time. Access reviews require context, lifecycle automation needs to be consistent, and risk assessments need complete information for optimal decision making.

This is why modern IGA platforms increasingly position identity correlation and continuous reconciliation as core capabilities rather than background processes.

Lifecycle management needs to cover wide range of identity types

The concept of identity lifecycle management has expanded well beyond employees. While workforce identities still follow relatively predictable onboarding and offboarding processes, NHIs such as service accounts, APIs, containers, automation scripts, and AI agents are created through development pipelines and infrastructure automation rather than HR systems. The identities are ephemeral and need constant governance.

The cost of getting this wrong compounds over time. GitGuardian's 2026 research on exposed credentials found that 64% of secrets that were valid in 2022 remain exploitable today, nearly four years later. Ungoverned NHIs do not just accumulate; they persist, quietly, long after anyone remembers why they were created.

As a result, traditional workforce-centric lifecycle models are no longer sufficient. Organizations increasingly expect IGA platforms to govern both human and NHIs consistently through flexible lifecycle policies, continuous reconciliation, and clear ownership models. The focus is shifting to applying a unified governance model across all identities.

Governance is shifting to continuous evaluation

Access certifications remain an essential governance control, particularly for regulated industries. However, reviewing thousands of entitlements is difficult to justify when access changes every day. Instead of certifying every entitlement equally, reviews increasingly focus on higher-risk scenarios, unusual access patterns, privileged permissions, or changes triggered by lifecycle events.

Rather than relying exclusively on scheduled certification campaigns, organizations increasingly expect continuous monitoring, event-driven reviews, and policy enforcement that reacts to changes as they occur. This continuous, event-driven posture echoes the logic underpinning  Zero Trust architectures: access is not a status to certify periodically, it is a condition to verify constantly.

Access intelligence is becoming the real differentiator

Provisioning, approval workflows, and role management have become mature capabilities across the IGA market. So, the area where vendors increasingly differentiate themselves is access intelligence. The goal is not replacing governance decisions with AI. Instead, analytics provides additional evidence that allows reviewers, administrators, and auditors to make more informed decisions while reducing unnecessary manual effort.

Organizations want governance decisions supported by context rather than static policies alone. Machine learning (ML) models are now being applied to identify dormant accounts, detect anomalous access, recommend entitlements, optimize role models, and highlight unusual permission combinations. These capabilities are particularly valuable because entitlement structures continue to grow more complex. Access intelligence is gradually moving from optional enhancement to expected functionality.

What’s next for IGA

The next generation of IGA is gradually evolving toward continuous reconciliation, event-driven lifecycle management, contextual risk analysis, and governance that extends equally across human identities and NHIs.

This episode of the Analyst Chat dives into a deeper discussion of these dynamics:

Zero Trust Platforms are emerging as a response to this fragmentation. Their promise is not simply another access product, but a unified policy, context, and enforcement fabric spanning users, devices, workloads, APIs, service accounts, and increasingly AI agents. This Leadership Compass examines how this market is converging, which capabilities now define platform maturity, and where architectural substance ends and Zero Trust branding begins.

Join Alexei Balaganski, Lead Analyst & CTO at KuppingerCole Analysts, for a practical walkthrough of the Leadership Compass on Zero Trust Platforms. The session traces how the market has evolved from VPN replacement and point enforcement toward a broader platform category, and what this shift means for buyers trying to rationalize overlapping access, segmentation, and policy tools. Alexei will outline the capabilities that now define leadership in this market and provide a pragmatic test for separating platforms with real architectural depth from products that have simply inherited the Zero Trust vocabulary.

Chris Webber, VP of Product Marketing at Teleport, brings a practitioner’s perspective on identity-centric security and modern infrastructure access. Having worked at companies such as Zscaler, Centrify, and Styra (creators of Open Policy Agent), he will share practical insights on applying Zero Trust principles with a focus on unified policy and modern identity environments.

This is a question worth addressing here because it is no longer optional.

Your Best Defense Was Nobody Bothering

Something uncomfortable often underlies identity environments. What protects your over-privileged service accounts and your long-lived secrets is very often not consistently enforced policy. It is effort. These weaknesses have sat there for years without being exploited, and not because they were well hidden. Many are perfectly visible to anyone who knows where to look. The more mundane reason is that reviewing a large, sprawling estate took skilled human time, and that time was always expensive and finite.

Call it security by effort. Protection that works because breaking it costs more than it returns. Nobody chose it. It accumulated, one deferred review at a time, and it held for exactly as long as the effort stayed expensive.

In June, that assumption came apart. A new AI model arrived from a capability tier its maker had judged too dangerous in cybersecurity to release without additional safeguards. Within three days a US export-control order took it offline worldwide. By the end of the month the controls had been lifted again. The capability at the center of it is almost banal. Point the model at a codebase and have it find the flaws. That is automated vulnerability discovery, and much the same capability now sits inside other AI models. Which one hardly matters. The effort is no longer expensive.

One challenge for us as humans: NIS2 and DORA can force documentation and accountability. Neither creates real urgency. Automated vulnerability discovery does. Assume attackers can now afford to go looking.

The Part Nobody Put On a Slide: Our Current Security Measures Are at Least One Step Behind

The safest place to start is at the resource, the database, the API, the queue itself, not at a gateway somewhere in front of it. Check it there and a request has to prove it is allowed the moment it arrives, no matter which account it claims to come from. That is the check that still fires when a service account nobody wrote down starts pulling data, and in an estate this size something eventually does. Listing every non-human identity with an owner and an expiry date is worth doing too, but the list is always behind, because these accounts appear faster than anyone maintains the record. The list tells you which identities existed the last time someone checked. Enforcement at the resource covers the one making a call right now.

From there, the work moves to the credentials themselves. Long-lived static keys and service-account passwords sit at the root of most machine-identity risk, and every new agent built on an old secret inherits that exposure. The trend is moving away from permanent credentials and towards temporary, purpose-specific ones. If a team wants to make immediate progress, the most useful step is often the least sophisticated. Find the oldest, most forgotten secret in the estate, whether it is a password last rotated years ago or a vault entry that still belongs to someone who left, and retire it.

The harder shift has little to do with tooling and everything to do with habit. When an agent needs to act, the reflex is to hand it the credential. But handing a non-deterministic actor a raw token means handing over all that authority at once. The more defensible arrangement keeps the credential with a system that carries out the action on the agent's behalf, and lets the agent ask only for narrow, specific operations. Once you control what an agent can actually reach, meaning its resources, its tokens and its tools, the question of what a compromised or misbehaving agent might do becomes far easier to contain. Catalogue your agents and secure the vaults and the tools they depend on.

Authorization itself must change shape. The familiar approach, authorize once at the perimeter and then trust the session, does not survive chains of agents calling one another at machine speed. It must become continuous instead, evaluated at every step and carrying the human intent behind a request through the whole chain. At least the last part is still an open problem, and the standards for passing intent cleanly from one agent to the next are only now taking shape. Without it, one question has no answer. Who delegated what to whom, for what purpose, and under whose authority?

You Already Know Most of the Tools, and Now It Is Time to Use Them

Strip away the vocabulary of autonomous agents and the shape of the problem is recognizable. Discovery, least privilege, short-lived credentials, continuous authorization, lifecycle. What is new is the setting. These are no longer occasional hygiene tasks but controls that must hold for a fast-growing population of autonomous actors operating at machine speed and doing that well is genuinely hard. Few organizations have managed it yet but that is not a reason to wait. It is the reason to start.

What changed in June was not the difficulty of the work but the cost of avoiding it. Nobody invented automated vulnerability discovery. It simply stopped being expensive. The effort that used to keep these gaps quietly out of reach is gone, and it is not coming back.

The organizations that handle the next phase well will not be the ones that found the right AI-native platform to buy. They will be the ones that did the ordinary work properly, early, and turned security by effort into security by design. None of it is glamorous. Do it now, or wait until someone, probably an agent, finds out what you missed. Guess what? It won't tell you first. 

Something similar is happening in SaaS security

For the past five years, SaaS Security Posture Management (SSPM) has been steadily moving along the security racetrack. It emerged to solve problems created by rapid and often poorly managed SaaS application adoption: unsanctioned applications, inconsistent configurations, excessive user permissions, local accounts outside centralized identity systems, and weak visibility into who was using what, to list just some of the issues. These are not minor security issues. They reflect a fundamental loss of control as business units adopted cloud-based applications faster than IT and security teams could secure and govern them. 

SSPM helped organizations regain some of that control. It provided security teams with better ways to discover SaaS applications, monitor configuration hygiene, identify risky permissions, and reduce SaaS-related identity and access weaknesses. Those requirements have not gone away. Organizations still need to know whether critical SaaS applications are configured securely, whether administrators are overprivileged, whether local accounts bypass their identity provider, and whether posture drift is creating new exposures. 

But the race has changed. 

The faster class of AI security and governance has now entered the track and is setting the pace for the combined new market category of SaaS Security and AI Governance. AI governance is not replacing SSPM. Rather, it is accelerating the need for a broader control plane that includes traditional SSPM but also extends well beyond it into AI. 

The reason is straightforward: enterprise AI adoption is following many of the same decentralized processes that created shadow SaaS. Employees are using public AI tools directly from browsers. Business teams are enabling SaaS-native copilots. Developers are connecting AI agents into broader business workflows. Users are granting OAuth access to AI-enabled applications. Increasingly, personal agents and automation tools are being deployed without formal IT onboarding or security review.

Shadow AI is now the next phase of shadow IT

The result is that the SaaS risk surface is no longer limited to applications, configurations, and human users. It now includes embedded AI, shadow AI, AI agents, OAuth integrations, non-human identities, SaaS-to-SaaS connections, sensitive data exposure, and active threats. That is why SaaS application configuration hygiene, while still necessary, is no longer sufficient as the organizing idea for this market.

From SSPM to SaaS Security and AI Governance

Buyers now need to ask broader questions:

• Which SaaS and AI applications are in use?
• Who or what has access?
• What user permissions exist?
• What data is reachable?
• Which integrations are trusted?
• Which tokens are persistent?
• Where is risky behavior emerging?
• Where is there evidence of active threats? 

AI agents raise the stakes because they can operate with delegated authority, interact across multiple systems, retrieve data, and act at machine speed. Even when an agent does not have administrative privileges, it may still have enough access to create material risk. It may summarize sensitive content, move data into another system, trigger workflows, or act through permissions granted to a user, service account, or connected application. 

OAuth and SaaS-to-SaaS integrations add even more security exposures. Modern SaaS environments are surrounded by marketplace apps, automation platforms, API-driven workflows, copilots, and third-party integrations. These connections may hold tokens, inherit user permissions, synchronize sensitive data, or create indirect access paths into critical business systems. A connected application does not need to be malicious to be dangerous. It can simply be overprivileged, abandoned, poorly monitored, unsanctioned, or under the control of a threat actor. 

Data exposure adds further overall enterprise risk. As AI becomes embedded into SaaS workflows, the key question is not only which application is being used. It is what data that application, model, agent, integration, or user can reach. Sensitive data can be placed into prompts, retrieved by copilots, summarized by agents, exposed through public links, or moved through automated workflows. This makes data reachability, sharing exposure, permission context, and activity monitoring central to SaaS and AI governance. 

For buyers, the conclusion is not to discard SSPM requirements. It is to expand on them. SaaS discovery, configuration monitoring, and posture management remain foundational. But these now need to be complemented by identity posture, OAuth risk management, AI agent visibility, SaaS-to-SaaS integration risk, data exposure management, threat detection, remediation workflows, audit reporting, and cost governance. 

In multi-class racing, the slower classes still matter, but the faster classes change the rhythm and strategy of the entire race. SSPM is still on the track. It remains a necessary class of controls. But AI governance has become the lead driver accelerating adoption of a broader SaaS Security and AI Governance market. 

Stay tuned for the upcoming release of our brand-new Leadership Compass on SaaS Security and AI Governance.

Key Topics:

✅ Why zero trust is a strategy, not a product — and what that means for procurement
✅ The four non-negotiable requirements for a real Zero Trust Platform
✅ What separates a genuine platform from a collection of tools with a zero trust label
✅ NHIs, AI agents, and data protection as the new frontiers of zero trust architecture
✅ Three critical questions every RFP for a ZTP should include

🔐 "Stop looking for a Zero Trust Platform" - yes, really. Alexei Balaganski explains why that mindset shift is the most important thing a CISO can do before opening a single RFP.

📊 The KuppingerCole Analysts Zero Trust Platform Buyers Compass and Leadership Compass are both published: watch this episode first, then dive into the research.

In this exclusive webinar, INCYBER and KuppingerCole deliver a comprehensive macro-economic and technical analysis of the European cloud market. Our featured expert, Mike Small (Senior Analyst at KuppingerCole), breaks down the current landscape, geopolitical threats, operational resilience, and the 4 critical control zones you need to know.

Key Takeaways from this session:

• Understand how to align with NIS2 requirements without freezing your technological innovation.
• Discover how to manage data isolation and mitigate outage risks.
• Explore the future of European cloud trends over the next 5 years, with a specific focus on ultra-critical sectors like Defense.

In this episode of The CISO Perspective, Berthold Kerl speaks with Roberto De Paolis, Head of Digital Security and Security Operations at Leonardo, the global aerospace, defense, and cyber company. Roberto brings a practitioner's view from one of Europe's most complex security environments, defending a critical infrastructure provider operating across defense, aerospace, and industrial sectors simultaneously.

The conversation covers the four attack trends currently reshaping the threat landscape, how AI is lowering the cost and raising the sophistication of offensive operations, the challenge of applying Zero Trust to OT environments with decades of legacy infrastructure, and why European cyber sovereignty requires more than regulation. It requires coordinated investment and shared technology.

Roberto also addresses a question security leaders rarely discuss openly: the ethics of using offensive AI techniques defensively, and where the boundaries should be.

Topics covered: AI-powered attacks, Zero Trust, OT/ICS security, supply chain threats, European cyber sovereignty, cloud data sovereignty, SOC automation, ethics of defensive AI.

Most security incidents do not begin at the login screen. They begin much later, when an identity has authenticated once and keeps its access long after the reason for it has disappeared. Standing access is the liability almost no one measures. Employees keep permissions from projects that ended years ago. Service accounts reach systems no one remembers connecting. API keys sit in config files, valid until someone notices, which is usually never.

For the longest time, this was still manageable. People log in a few times a day, act at human speed, and usually leave a trail someone can reconstruct later. Software acting on our behalf changes the equation. An Artificial Intelligence (AI) agent can operate continuously, across systems, through credentials scattered across code, pipelines, vaults, and SaaS tools.

Authentication tells you who the agent claims to be but does not tell you what the agent should be allowed to touch, why, or for how long. That is the problem 1Password has now decided to address, with an acquisition reportedly valued well above $200 million.

What 1Password did

When 1Password introduced Unified Access in March 2026, the strategic direction was already clear: access, not authentication, was becoming the control point for humans, machines, and agents. What was less clear was how much runtime enforcement the platform could actually provide.

The more recent announcements answer that question only partially, but they make the missing piece visible. 1Password acquired Apono, a cloud-native just-in-time (JIT) access governance platform, and launched Credential Broker into private beta. These two announcements are closely related, but they are not interchangeable. They address different layers of the same access problem.

Credential Broker covers credential delivery: where secrets live, how they are retrieved, how they are injected into workflows, and how organizations can stop hardcoding them into automation, scripts, repositories, pipelines, and local developer environments. Its first private beta use case, GitHub Actions, is still quite narrow but shows the direction of future development. CI/CD workflows are exactly where long-lived secrets, excessive permissions, and developer convenience tend to reinforce each other.

Apono addresses runtime authorization. Once an identity has received access, what can it actually do, under which conditions, with whose approval, and for how long? This is where JIT access, zero standing privilege (ZSP), approval workflows, session controls, and auditability become central. Apono is less about protecting the credential itself and more about governing the entitlement that credential enables.

Credential Broker helps prevent credentials from being scattered, copied, embedded, and forgotten. Apono helps prevent access from becoming broad, persistent, and detached from business need. One is about delivering secrets safely while the other makes access conditional, temporary, and observable at runtime.

The vault is still the company’s original foundation, but 1Password’s ambition is no longer simply to store credentials securely. It is to decide when credentials should be released, what access they should enable, what the identity may do with that access, and when the permission should disappear again.

Credential security and access governance have been treated as separate disciplines for too long. In an agentic environment, that separation becomes a liability. An AI agent does not care whether the risk came from a leaked token, an overprivileged service account, or an approval workflow that granted too much access for too long. It only needs enough authority to wreak havoc at machine speed.

Credential Broker and Apono are therefore not just two product additions. They are the two sides of the runtime access layer the Unified Access narrative was missing in March.

Why access, not login, is the control point

For most of its history, enterprise identity centered on authentication: create the account, verify the login, provision access, deprovision on exit. The workflow was built around the moment of entry, because for human users that was where the interesting decisions usually happened.

Agents work differently: they act after entry, continuously and at machine speed. They chain actions together, cross system boundaries, and use delegated authority in ways no one fully anticipated when the session opened. A permission that looked reasonable at login can become excessive a minute later, when the agent reaches into a system it was never meant to touch. Point-in-time authorization cannot see that happen, let alone stop it.

“Who is allowed in” is no longer the right question to ask. We need to know what identity is allowed to do once inside, whether the permission still makes sense, and whether it should still exist a second later.

This is the shift from Zero Trust as a slogan to Zero Trust as an operating model, where enforcement follows the identity into every action. The agentic version is even sharper because agents act through APIs, with delegated authority, at a volume conventional controls were never built to police. This is the broader argument I make in Leadership Compass Zero Trust Platforms and No API Security, No AI Security. 1Password is making the right call: runtime access, not the login event, is becoming the control point for agentic work.

From vault to access platform

As a company that already holds credentials, secrets, and developer workflows, 1Password has a strong starting point for broader identity security. The vault is not enough to make it an enterprise access platform, but it is a powerful foundation from which to try. Its strength has always been usability, and that matters more than enterprise identity vendors sometimes like to admit. A security control no one wants to use is usually something people quietly work around.

The challenge is that enterprise identity security is not just a usability problem. It is also an architecture problem, an integration problem, but most of all an organizational problem. Identity, security, DevOps, and engineering teams all look at access from different angles. A vault gives 1Password a strong point of entry, but the enterprise narrative must extend beyond secure storage into policy, enforcement, audit, governance, and operational fit.

That was the open question in March. Unified Access pointed in the right direction, but the runtime layer was still more implied than delivered. Apono gives 1Password a credible answer to what happens after a credential is released and after an identity enters a system. Whether that answer becomes an integrated enterprise platform is still a separate question.

Unified is still a claim about the future

The word doing the heavy lifting in “Unified Access” is unified. It is also the part still coming together, since customers cannot yet buy the pieces as one integrated platform.

The pieces sit at very different stages. Enterprise Password Manager is established. SaaS Manager is real and growing. Device Trust has been in the portfolio since 2024. Credential Broker is in private beta and starts with GitHub Actions. Apono has only just arrived inside the company, with deeper integration still ahead. The two building blocks carrying most of the agentic runtime story are also the least mature pieces inside the 1Password platform.

The harder part is that credential delivery and runtime authorization have to converge in practice. Credential Broker cannot remain only a safer way to retrieve secrets, and Apono cannot remain only a JIT access layer beside the vault. The value of Unified Access depends on making both layers part of the same policy decision: who is asking for access, which credential is being requested, what task it supports, what the identity can do once inside, when access expires, and what evidence is produced afterward. A portfolio can contain a vault, a broker, a SaaS visibility tool, device trust, and JIT access. A platform has to make those components behave like one control plane.

Read generously, 1Password saw a gap in its own roadmap and moved decisively. Read skeptically, a core capability is now being positioned as central to the strategy just weeks after arriving through acquisition. Both readings can be true. That is what makes the move interesting.

The most crowded corner in identity

1Password is entering one of the most crowded market segments of identity security, and it has arrived at the same conclusion at almost the same moment as its competitors.

CrowdStrike is talking about Continuous Identity for AI Agents, real-time authorization, removal of standing privileges, and delegation chains. SailPoint is positioning Agentic Fabric around agent ownership and ZSP models. Delinea bought StrongDM for a similar reason.

Even the vocabulary is converging: zero standing privilege, just-in-time access, unified control plane, humans, machines, agents. When every vendor uses the same labels in the same quarter, the labels stop carrying information. The only useful question is what sits underneath them.

1Password’s advantage is the vault, the developer footprint, and the everyday usability that many enterprise incumbents still struggle to match. It starts close to where credentials are created, stored, shared, and quietly misused. That gives it a credible path from human access to delegated agent access, especially in developer workflows where agents, automation, and secrets already collide.

What it does not have is uniqueness. Several competitors now have defensible foundations of their own, whether they start from privileged access management, identity governance and administration, endpoint security, identity threat detection and response, or continuous authorization. 1Password is not the only vendor building this, but it may have one of the strongest starting points where developers and agents already work.

Where the pitch gets ahead of the product

Apono’s intent-based access model asks an agent to state, in natural language, why it needs access, then compares that declared intent against what the agent actually does. If the behavior diverges, access can be narrowed or revoked.

Conceptually, this is where agent governance has to go. In practice, it depends on reliably characterizing the intent of a non-deterministic system and detecting drift without a lot of false positives. That is an exceptionally hard problem, and no vendor has cracked it reliably at scale yet.

Tying an agent’s access to the human who authorized it, scoped to a task, is the delegated identity model the industry is rapidly converging on. It is also easier to describe than to implement. It raises uncomfortable operational questions. What happens when the delegating human’s own access changes mid-task? What happens when an agent calls another agent? Where is the chain anchored, how is it verified, and who can revoke it?

Both claims run into the credential and protocol layer where agents connect to tools, the surface examined in Model Context Protocol, and both sit on top of the non-human identity problem charted in From Machine Identity to Agentic AI. These are not objections to the model. They are the conditions under which the model becomes real.

The work that starts after the deal

Access, not authentication, is becoming the control point for agentic work. 1Password has identified that shift correctly, and with Apono it has bought the runtime access layer it was missing.

However, the market will not wait while 1Password turns multiple products into one platform. Larger and better-resourced competitors are assembling versions of the same model, often with deeper roots in privileged access, identity governance, endpoint security, or continuous authorization. 1Password’s advantage is real but narrow enough to erode if integration stalls.

The move from storing credentials to governing access is the right one. Whether 1Password can turn it into a defensible enterprise position depends on making the vault, Credential Broker, Apono, SaaS Manager, and Device Trust behave like one system before the market decides that someone else already solved the problem.

Recent geopolitical developments, accelerating investment in artificial intelligence, and increasing concerns over digital sovereignty are driving strong demand for European sovereign cloud infrastructure. At the same time, Europe faces significant structural challenges that could limit its ability to capitalize on this opportunity. The IMF's recent working paper Europe's Productivity Weakness identifies many of the underlying economic factors that continue to constrain Europe's innovation and productivity, several of which apply equally to the sovereign cloud market.

The future success of European sovereign cloud providers will therefore depend not only on growing demand but also on Europe's ability to overcome these structural barriers.

Growth Drivers and Opportunities for EU Sovereign Clouds

The market opportunity for European sovereign cloud has never been greater. Artificial intelligence, geopolitical change and growing strategic investment are converging to create a once-in-a-generation opportunity for European cloud providers to compete on more than trust alone.

1. Generative AI (GenAI) is creating a new cloud market: GenAI is fundamentally changing cloud infrastructure requirements. Unlike previous generations of enterprise software, GenAI requires vast amounts of computing capacity, specialized GPU infrastructure, high-performance networking, and scalable storage. As organizations move from experimentation to production deployment, AI infrastructure is rapidly becoming the next major growth engine for cloud services.
   Forecasts suggest the European AI market will continue to grow at over 40% annually, with the GenAI segment growing even faster. Every new AI application increases demand for cloud-native AI platforms, inference services, vector databases, model hosting, and sovereign AI infrastructure. For European cloud providers, this represents an opportunity to compete in a rapidly expanding market rather than attempting to displace established hyperscale cloud service providers (CSPs) in traditional infrastructure services.
2. Rising European defense spending: The rapid increase in European defense investment is creating a second major growth opportunity. Defense organizations require sovereign digital infrastructure capable of supporting secure communications, intelligence analysis, autonomous systems, AI-enabled decision support, and classified workloads.
   European initiatives such as ReArm Europe and increasing national defense budgets are accelerating investment in secure digital infrastructure. Sovereign cloud providers can support these requirements through trusted cloud platforms operated under European jurisdiction and aligned with national security requirements.
3. Geopolitical uncertainty: Geopolitical risk has become one of the strongest drivers of sovereign cloud adoption. Growing concerns around the US CLOUD Act, international sanctions, export controls, supply chain disruption, and increasing geopolitical tensions have elevated digital sovereignty from a compliance issue to a board-level strategic consideration.
   Many organizations are now evaluating where their critical applications are hosted, who operates their infrastructure, which legal jurisdictions apply to their data, and how resilient their digital operations would remain during periods of international instability. This shift is expanding demand for cloud services that provide stronger guarantees around legal, operational, and technological sovereignty.
4. Digital supply chain resilience: Modern supply chains depend upon digital infrastructure. Manufacturing, healthcare, utilities, financial services and government all rely upon cloud-based platforms to operate critical business processes.
   As recent geopolitical events have demonstrated, resilience is no longer limited to physical supply chains. Organizations are seeking resilient digital supply chains that minimize dependencies on single providers, foreign jurisdictions, or concentrated technology ecosystems. European sovereign cloud providers can play an important role by providing trusted alternatives that improve operational resilience while reducing strategic dependence on external infrastructure.

Challenges and Structural Restraints

Despite strong market demand, European sovereign cloud providers must overcome structural challenges that have constrained Europe's technology sector for decades.

1. Energy availability: Cloud infrastructure is becoming one of Europe's largest consumers of electricity. Data centers are already estimated to account for approximately 2.5% of EU electricity demand, while countries such as Ireland have seen data centers consume around one-fifth of national electricity production.
   The rapid growth of AI significantly increases these pressures. GPU clusters require substantially more power than traditional cloud infrastructure, creating challenges around electricity availability, grid capacity, sustainability objectives, and planning approval. Access to affordable renewable energy may become one of the limiting factors for Europe's sovereign cloud providers.
2. Lower investment in innovation: Perhaps the most striking observation from the IMF report is the widening innovation gap between Europe and the United States. European technology firms continue to invest significantly less in research and development than their US counterparts. The report notes that R&D expenditure among European listed technology firms has remained around 3–4% of sales, while comparable US firms have increased investment to approximately 12% of sales.
   This innovation gap directly affects the cloud market. Continuous investment is required to develop AI services, automation capabilities, cloud platforms, cybersecurity technologies, and advanced management tools. Without sustained investment, European providers risk falling further behind the innovation cycles established by the US hyperscale CSPs.
3. Market fragmentation: Despite decades of economic integration, Europe remains a fragmented digital market. The IMF argues that European firms continue to operate within a much smaller effective market than their US competitors because regulatory, commercial and operational barriers continue to limit scale.
   This fragmentation affects sovereign cloud providers directly. Different procurement frameworks, regulatory interpretations, national certification schemes, and customer preferences increase operational complexity and reduce economies of scale. Completing Europe's Digital Single Market for cloud services remains one of the most important long-term growth opportunities.
4. Limited market scale: European cloud providers also face a significant scale challenge. While Europe has many capable national and regional cloud providers, none individually approaches the market presence of AWS, Microsoft Azure or Google Cloud. The largest European provider still represents only a small percentage of the overall European cloud infrastructure market.
   Scale matters because cloud economics increasingly depend upon global infrastructure, AI investment, procurement leverage, software ecosystems and continuous platform innovation. Without greater scale, many European providers may struggle to match the pace of investment required by the AI era.
5. Access to growth capital: The IMF identifies lower levels of equity financing and venture capital investment as another structural weakness within the European economy. Young innovative firms frequently struggle to obtain the funding required to scale rapidly, particularly those investing heavily in intangible assets and advanced technologies.
   These same challenges apply to sovereign cloud providers. Building AI-ready cloud infrastructure requires billions of euros of investment in data centers, GPU clusters, networking, software platforms, and operational capability. Ensuring sufficient access to long-term investment capital will therefore be essential if Europe wishes to build globally competitive sovereign cloud providers.

From Compliance to Competitiveness

The conditions for European sovereign clouds have never been stronger. But demand does not automatically translate into competitive infrastructure.

The opportunity extends well beyond compliance or data residency. Sovereign clouds have the potential to become one of the foundations of Europe's future digital economy, enabling trusted AI adoption, supporting strategic industries, strengthening resilience, and improving long-term productivity. If Europe can combine its regulatory leadership with deeper market integration and increased investment in innovation, sovereign cloud could evolve from a defensive response to geopolitical uncertainty into a powerful engine of European competitiveness and economic growth.

How can European organizations reconcile security imperatives (NIS2) with the adoption of AI while remaining dependent on US hyperscalers? Forum INCYBER and KuppingerCole Analysts invite you to decode the realities of digital autonomy on July 15, 2026 at 5:00 pm (CEST).

Key Topics:

✅ Why the Identity Fabric concept emerged in 2019 — tool sprawl, siloed IAM, and the collapse of the perimeter
✅ What "fabric" actually means: a capability-driven layer connecting all identities to all services
✅ Why capabilities should define tools — not the other way around
✅ How the fabric concept scales to cybersecurity and AI security architectures
✅ The fabric in practice: maturity assessments, requirements analysis, and target operating models
✅ A look ahead to 2040: why the core principles are built to last

"The job of identity management is to provide seamless access for everyone and everything to every service" — seven years on, that definition still holds. Find out why in this episode.

📅 This is the first episode of a new series on the fabric paradigm, covering Identity Fabric, Cybersecurity Fabric, and AI Security Fabric.

I kept returning to that idea throughout the European Identity and Cloud Conference (EIC) in Berlin this May. Identity, in every conversation I had, behaved exactly like Kurzweil's neurons and transistors.

Get the foundational layer right and everything you build on top of it becomes simpler, more durable and more inclusive. Get it wrong, and every subsequent layer inherits the flaw.

Starting With the Basics

Before we can talk sensibly about digital identity, we need to talk about human identity. Not the technical kind, the human kind. It begins with a birth certificate and follows a person through school, work, healthcare, banking, pensions and, eventually, death. It should make no distinction based on where someone was born, what they look like or what they are able to do physically or cognitively. That is the layer everything else sits on.

Once that foundation is solid, the digital layer becomes a natural extension rather than a separate problem to solve. We already have most of the technical tools required. What we lack is agreement on how to assemble them into something people can actually use without thinking too hard about it. Events like EIC exist precisely for that reason: to bring the people who build standards, write policy and design products into the same room so that identity can move from an abstract concept to something consumable.

Making Identity Consumable

Consumers do not wake up wanting a digital identity wallet. They want easier travel, safer banking, faster onboarding and protection from fraud. As John Erik Setsaas, Principal Advisor and Founder at Setsaas Trust Advisory, put it during his session, people do not really care about digital identity. They simply expect to be recognised.

That single observation captures a shift taking place across the whole industry. The conversation is moving away from technical vocabulary such as credentials, wallets and protocols, and towards outcomes: less friction, more trust, portability across borders and resilience in a crisis. Whether it is a European wallet that lets citizens book a hotel or prove a qualification without oversharing personal data, or a system that helps a refugee prove who they are after losing every physical document, the goal is the same. Identity has to disappear into the background of everyday life for it to succeed.

Identity as a Business Capability, Not Just a Security Problem

One of the most striking conversations I had at EIC was with Eve Maler, founder of Venn Factory and author of Mastering Digital Identity: From Risk to Revenue. Her central argument is that most CEOs barely think about digital identity until something goes catastrophically wrong, and by then it is far too late to treat it as a footnote.

Eve believes identity should be understood as a business enabler rather than a purely technical function. When identity sits solely within a security team, the metrics tend to focus on risk reduction while overlooking customer experience, revenue growth, and broader business value. She described four jobs that identity actually does: protecting people and transactions, personalising customer experience, enabling payments and commercial interactions, and giving people convenience and control over their own digital lives. Most organisations, in her experience, invest heavily in the first and neglect the other three.

Treating identity as a product rather than a project changes the conversation entirely. It creates accountability for delivering value to customers and to the business, not just for closing security gaps.

Nishant Kaushik, CTO of the FIDO Alliance, made a related point from a different angle. Trust, he told me, is built when technology simply works the way people expect it to. It needs to be easy, reliable, fair and available exactly when someone needs it. When it fails, the damage goes well beyond a security incident. It erodes customer confidence and brand reputation. Standards, interoperability and genuine user choice are what allow that reliability to scale beyond a single company or a single market.

Trust Must Work for Everyone

Dr Angelika Steinacker, who works as an enterprise IAM consultant and serves as DACH ambassador for Women in Identity, offered one of the most important reminders of the conference: a digital identity solution that does not work for everyone does not work.

Inclusion means a system remains usable regardless of age, skin colour, disability or cognitive impairment. Women in Identity has spent roughly five years researching this, moving from identifying where exclusion happens, to listening to people who have experienced it, to quantifying its economic cost in collaboration with the London School of Economics. That research produced a striking finding. When people cannot access services because an identity system fails them, participation in the digital economy falls, and that ultimately affects productivity and GDP. Inclusion, in other words, is not only a social responsibility. It is a measurable economic one.

Angelika was equally direct about why progress remains slow. Identity systems are often designed and tested by fairly homogeneous teams, who naturally build for people whose backgrounds resemble their own. Retrofitting inclusion after launch is far more expensive and far less effective than building it in from day one. As she puts it, diversity is not an end product. It is an entire development process.

Preparing for a World After Classical Cryptography

Not every threat to identity is about who gets left out. Some of it is about what happens to the data we generate today, years from now. Dr Michael B Jones walked me through the quantum question in stark terms. Within a decade or so, quantum computers are likely to be capable of breaking the classical public key cryptography that underpins most of today's digital identity infrastructure. Nobody can say precisely when, and that uncertainty is exactly why organisations struggle to justify acting now.

The risk is already live in a practical sense, through what is known as store now, decrypt later. Well resourced attackers can capture encrypted traffic today with no ability to read it, and simply wait for the computing power to catch up. For sectors such as finance, healthcare and government, information that is sensitive today will often still be sensitive in fifteen or twenty years.

Mike's message to executives was refreshingly simple. You do not need to understand Shor's algorithm to understand the business risk. Migration takes years, uncertainty is not a reason to delay, and organisations handling long lived sensitive data should be planning now rather than waiting for a definitive deadline. He was equally clear that quantum computing is not only a threat. The same power that endangers today's encryption could unlock breakthroughs in drug discovery, materials science, and personalised medicine. It is worth remembering, as he pointed out, that standards like OpenID Connect, now used every time someone signs in with Google or Apple, were born from informal conversations in a hotel lobby at an early EIC event. Progress in this field has always depended on practitioners choosing to collaborate rather than work in isolation.

What Happens to Our Identity After We Die

A theme that surprised me by how little attention it usually receives was raised by Dean H Saxe, co-author of the OpenID Foundation whitepaper The Unfinished Digital Estate: Culture, Law and Technology After Death. Managing a person's digital estate, from email accounts to cloud storage to banking logins, remains extremely difficult for individuals, families, businesses and governments alike.

Dean pointed out that death creates a significant window for fraud. In the UK, for example, pension payments can continue to be collected by family members if the authorities are not informed of a death promptly. The challenge is designing mechanisms that release access only after a genuine trigger event, whether that is death, incapacity or a legal guardianship order, without creating a gap that a fraudster can exploit in the meantime. An executor might need access to specific accounts, but that does not mean they should be able to log into a password manager and move money out of an investment account.

These questions are shaped as much by culture, religion and inheritance law as by technology. In some countries families manage almost everything after a death. In others, only a formally appointed executor has any authority at all. That is precisely why Dean argues for open, extensible standards, so that different legal and cultural models can coexist rather than being forced into a single global template.

The New Layer: Identity for AI Agents

Every single conversation I had eventually arrived at the same unresolved question. What happens to identity once AI agents start acting on our behalf?

Eve Maler described AI agents as a fundamentally different identity challenge from the non human identities organisations have managed for years, such as service accounts or IoT devices. Agents introduce delegation, autonomy and accountability across chains of people, agents and sub agents that existing identity approaches were never designed to handle. Her phrase for the underlying problem was memorable: AI is the balloon payment on technical debt. Organisations have spent years compensating for weak identity foundations with manual human processes. AI will expose those weaknesses at scale, all at once.

Angelika Steinacker is approaching the same problem from a governance angle, working on a paper that asks what purpose and intent actually mean for an autonomous agent, how an organisation defines an agent's identity, and how it verifies at runtime that an agent has not drifted from the mandate it was given. She compares the shift to the relationship between quantum mechanics and classical physics. It is not simply a harder version of the same problem. It is a different space that may need entirely new foundations, arriving faster than the industry has had time to properly define the problem it is solving.

Dean Saxe extended the question into the digital estate itself. If an agent has standing authority to make payments or manage investments on someone's behalf, what happens when that person dies? An agent's mandate might depend on a condition as simple as the account holder being alive, yet reliably detecting that a condition has stopped being true, and revoking authority accordingly, is still an open problem.

Even the future of Europe's own digital identity wallet is entangled with this question. John Erik Setsaas told me the EUDI Wallet is expected to go live by the end of 2026, although some member states will miss that deadline, and getting ordinary citizens to actually use it may prove to be the harder task. Consumers already carry Apple Wallet or Google Wallet, and many are more comfortable sharing data with large technology companies than with their own governments, which makes the value of a new wallet a communication challenge as much as a technical one. John also raised a question I had not previously considered: will AI agents eventually need their own wallets, distinct from the humans who authorise them? Nobody at EIC had a settled answer.

Building Foundations That Last

If there was a single thread running through every interview, it was this. Whatever we build for identity now, whether for humans or for the agents acting on their behalf, needs to be built on a foundation solid enough to support everything that comes after it, in the same way Kurzweil's simple equations only work because the physics beneath them was understood first.

That means inclusion designed in from the start rather than patched on afterwards. It means treating identity as a business capability with real accountability, not a security checkbox. It means preparing for cryptographic threats years before they arrive, and thinking through what happens to a person's digital life, and their agents' authority, long after they are gone. Above all, it means recognising that AI agents are not simply another category of user to slot into existing systems. They may require us to rethink identity from first principles, in much the same way that understanding the brain required scientists to move beyond the chemistry of a single synapse.

The technology to do most of this already exists. What EIC 2026 made clear is that the harder work now lies in agreeing on the standards, the governance and the incentives needed to put it all together, before the pace of AI adoption outruns our ability to do so responsibly.

About the author

Mirela Ciobanu is Lead Editor Banking and Fintech at The Paypers, focusing on following the latest trends and developments in fraud, cybersecurity, and technology (generative AI, blockchain analytics, data, etc.). Topics related to compliance, risk management, and balancing those with a great user experience play an important role in her expertise.

Mirela is particularly passionate about the importance of having interoperable digital identity solutions that help not only to secure payments but also transactions in other areas of life (travel, health, education). She is a strong advocate for online data privacy and protection. As a skilled writer, she strives to deliver accurate and informative insights to her readers, always in pursuit of the most compelling version of the truth. To share more ideas and get inspired, connect with Mirela on LinkedIn or reach out via email at mirelac@thepaypers.com. 

The conversation explores how cyber resilience has become essential for organizations that provide services society depends on every day. Topics include the convergence of IT and OT security, the evolving risks posed by ransomware and nation-state actors, the role of identity and Zero Trust, and the opportunities and challenges created by AI.

René also shares E.ON’s approach to resilience, business continuity, crisis preparedness, and leadership, highlighting why cybersecurity is no longer just a technology challenge, but a business and societal responsibility.

Key Topics:

✅ Why "we can build it cheaper" is almost always a biased and incomplete argument
✅ How the originating perspective (business unit, IT, security) shapes — and distorts — the decision
✅ The most common and costly mistakes organizations make when going the build route
✅ When buying is clearly the better path: expertise gaps, speed, scalability, and vendor roadmaps
✅ Why security and risk must be part of the decision from day one — not an afterthought
✅ A structured, holistic framework for making the right make-or-buy call

"This cheap solution can quickly turn into a security risk, an open attack, a breach — and much more cost than thinking about risk by design." Sound familiar? This episode is for you.

Key Topics:

✅ Why rule-based SOAR has hit a wall — and how AI agents address what it can't
✅ The autonomy dial: why full automation isn't the goal and how to build trust incrementally
✅ Integrations, RAG, and MCP: the new data infrastructure powering AI agents in the SOC
✅ DIY SOC vs. managed providers: how agentic AI is reshuffling the build-vs-buy decision
✅ Where to start: alert triage, phishing, and typosquatting as low-risk entry points
✅ Guardrails, transparency, and the non-deterministic challenge of AI-driven security

"AI agents hate people because they're slow" — but full autonomy isn't the answer either. Find out how leading SOC teams are finding the right balance between speed and control.

This videocast is sponsored by Torq — featured in KuppingerCole's Emerging AI SOC Leadership Compass. Read the report, then watch this session to hear the findings brought to life.

Nitish Deshpande, Senior Analyst at KuppingerCole Analysts, will present key findings from the 2026 Leadership Compass on IGA, offering an independent perspective on the current market landscape. He will explore how IGA solutions are evolving to address modern challenges, discuss evaluation criteria and leadership positioning, and provide guidance on how organizations can align their identity governance strategies with business and security priorities.

Nick Nikols, VP, IAM Products, OpenText Cybersecurity, brings a hands-on, practitioner perspective to Zero Trust, focusing on how modern identity and access management solutions can be implemented in real-world environments. Drawing on decades of experience across leading cybersecurity vendors and analyst firms, he will demonstrate how organizations can translate Zero Trust principles into actionable controls—improving access governance, securing cloud environments, and enabling consistent policy enforcement across platforms.

The real test is no longer whether an organization can prevent every attack. That is unrealistic. The real test is whether it can keep operating, restore trusted services, protect critical data, and preserve confidence when an attack succeeds.

That is why cyber resilience is the outcome every modern business should seek. Digital business now depends on data, identity, applications, infrastructure, software supply chains, and third-party services. When these are disrupted, the impact is not limited to IT. It becomes operational, financial, regulatory, and reputational.

In the UK, the cyber incidents at retailer Marks & Spencer (M&S) and motor manufacturer Jaguar Land Rover (JLR) in 2025 underline this point. In both cases, business operations were severely disrupted.  M&S had to pause online orders, while JLR had to manage a halt to manufacturing operations and the impact across a broader supply chain. These events show why resilience is a business requirement.

Against that background, progress by Cohesity since its merger with Veritas should be judged on whether the combined company moved closer to being able to help organizations restore trust in business operations, not just restore data.

The answer appears to be yes, with the important qualification that execution at customer scale remains the real proof.

From backup to operational cyber resilience

A key message from Cohesity is the move away from backup as an infrastructure category toward cyber resilience as an operational capability.

Backup has traditionally been seen as a recovery mechanism. It answers the question whether data can be restored. Cyber resilience asks a broader question. Can the business restart safely, securely, and quickly enough to limit damage?

Cohesity is talking about its platform in terms of this broader idea. Its five-step cyber resilience framework covers data protection and identity resilience, cyber vaulting, threat protection, cyber recovery orchestration, and data and Artificial Intelligence (AI) security posture management. This approach brings protection, recovery, security, and risk posture into one operating model.

This is also where the Veritas merger becomes more meaningful because of the opportunity to combine Cohesity’s modern data platform and AI-led approach with Veritas’s enterprise-grade data protection heritage, workload coverage, and customer base. Eighteen months on, Cohesity Data Cloud is becoming the common platform for that combination.

The platform vision is built around four layers. The data platform provides the foundation. Data protection ensures data can be protected and recovered. Data security helps reduce risk and recover from attacks. Data insights aim to unlock value from unstructured data, including for Generative AI (GenAI) use cases.

In practical terms, that means bringing together Cohesity NetBackup and Cohesity DataProtect for broad workload protection, Helios for centralized management and operational visibility, FortKnox for isolated cyber vaulting, RecoveryAgent for cyber recovery orchestration, threat protection for detection and investigation, identity resilience for protecting one of the most critical recovery dependencies, Gaia for AI-enabled insight into enterprise data, and Data Security Posture Management (DSPM) for understanding and reducing data risk.

This approach is correct. Cyber resilience depends on knowing what data exists, where it sits, how critical it is, how it is protected, whether it is clean, and how it can be recovered in the right sequence.

Platform integration matters

Cohesity says the Veritas integration was completed in less than nine months and points to six major releases in the past year, including DSPM, identity capabilities, Gaia, RecoveryAgent, Helios for NetBackup, and Gaia on premises.

It is worth noting that Cohesity is not presenting the combined portfolio as two product families under one corporate owner but as a route toward one control plane, broad workload coverage, flexible deployment, and common cyber resilience outcomes.

The distinction between the control plane and the data plane is also important. Cohesity’s claim that these can be independent and can be delivered as Software as a Service (SaaS) or on premises is relevant for regulated and complex organizations. Many large enterprises need centralized management, but they cannot always allow data to move freely into public cloud services. The ability to separate management from where data is processed and stored is therefore a practical resilience and sovereignty feature.

The simplification of consumption also matters. Cohesity is moving toward service tiers and specialized bundles. Complexity is the enemy of operational readiness. A solution that is too difficult to understand, deploy, license, or rehearse will not deliver resilience in a crisis.

Restoring trust, not just data

One of the strongest messages from Cohesity is that recovery is about restoring data, while cyber resilience is about restoring trust.

After a destructive cyberattack, organizations need more than a backup copy. They need confidence that the copy is clean. They need to know which systems to recover first, and which identities can be trusted. Not only that, but they need clean rooms, staging rooms, runbooks, communication paths, and tested recovery workflows.

Cohesity’s cyber resilience services appear to recognize this. Its approach is built around education, preparation, and support. Workshops help customers understand destructive attacks. Assessments benchmark current resilience. Digital Jump Bag and Clean Room workshops help define practical response and recovery workflows.

Using the Minimum Viable Company (MVC) approach, Cohesity aims to help organizations to identify the smallest trusted set of services needed to keep the organization legally, operationally, and commercially alive. This is at the heart of cyber resilience.

PwC partnership adds business resilience context

The strategic collaboration between PwC UK and Cohesity is significant. Announced at the Cohesity Catalyst on Tour event in London by Karen Penman, Digital & Cyber Resilience Partner at PwC UK, the partnership combines PwC’s cyber, risk, and resilience capabilities with Cohesity’s data security and recovery capabilities.

This is important because cyber resilience cannot be delivered by technology alone. Boards and executives need to answer business questions. Which services are most critical? How confident are we in recovery? What data and systems are essential?

Professional services firms can help translate technical resilience into business resilience. Technology providers can supply the platform, telemetry, protection, recovery, and automation. The strongest approaches will combine both.

The PwC partnership therefore fits the broader market direction. Resilience is becoming an operating model, not a product category. It requires governance, secure recovery technology and processes, crisis management, and regular testing and exercising.

Sovereignty as part of resilience

Cohesity is also addressing sovereignty in a pragmatic way. Its position is that data should remain under customer control wherever it needs to live. That includes on-premises, sovereign cloud, and hybrid deployment options.

The on-premises model is particularly relevant. Cohesity says customers can run the platform in their own datacenter so data never leaves infrastructure they control. In the strongest version of this model, processing and storage remain on premises, encryption keys remain with the customer, Cohesity has no access, and offline maintenance can be available where required.

This is not just a compliance point. It is a resilience point. Organizations in critical sectors may need recoverability under attack, but they may also need jurisdictional control, operational independence, supply chain transparency, and confidence that sensitive data is not exposed through a public cloud dependency.

Cohesity’s sovereignty message is therefore aligned with European regulatory and geopolitical realities. The key is that sovereignty must not be reduced to data residency. True sovereignty also includes control, transparency, recoverability, encryption, operational continuity, and exit options.

AI, agents, and the next phase of resilience

Cohesity’s AI strategy is also evolving. The company is not positioning itself as the control tower for all enterprise AI or agentic activity. Instead, it is focusing on protecting agentic infrastructure and the data that agents manage.

AI agents will increasingly act on enterprise data, call services, trigger workflows, and influence operational decisions. They will also create new risks. Resilience therefore requires trusted data, protected workflows, governed access, and the ability to recover the systems and data that agents depend on.

Cohesity’s approach is to partner with AI and agent platforms rather than force customers into a separate AI experience. Cohesity Maestro extends this direction by making Cohesity Data Cloud capabilities accessible through the Model Context Protocol (MCP). The idea is to let external AI tools and agents query telemetry, trigger recovery actions, access protected data insights, and orchestrate workflows under existing controls.

This headless approach is pragmatic. Enterprises are already standardizing on AI platforms. Security and infrastructure tools need to work where users and agents already operate. However, agentic resilience must be governed carefully. Role-based access control, authentication, auditability, policy enforcement, and human oversight remain essential.

Conclusion

The Cohesity and Veritas merger was always going to be judged on execution. Eighteen months on, there are credible signs of progress.

The combined company has moved beyond the language of portfolio consolidation and is now presenting a clearer platform strategy around Cohesity Data Cloud. The integration of NetBackup, DataProtect, Helios, FortKnox, RecoveryAgent, Gaia, identity resilience, threat protection, and DSPM gives the company a broader foundation for cyber resilience.

The strategic direction is also well aligned with market demand. Organizations need to protect data across hybrid and multi-cloud environments. They need to recover from destructive attacks. They have to know what data is sensitive, which services are critical, and what recovery sequence will keep the business alive. They need sovereignty options. They need AI support, but they need it with governance and control. They need preparation and rehearsal, not just recovery after the event.

The incidents at M&S and JLR show why cyber resilience is now a board-level concern. Cyberattacks now stop orders, affect factories, disrupt supply chains, and test public confidence. The question is not whether organizations have backups but whether they can restore trusted business operations fast enough to limit harm.

Cohesity is working to address that question. Its progress is visible in platform integration, service simplification, recovery orchestration, sovereignty support, AI-enabled data insight, partner alignment, and customer examples of resilience at scale.

The remaining challenge is evidence at scale. Cohesity must continue to show customer success in terms business leaders understand. The proof will be whether customers can prepare better, recover faster, restore trust more confidently, and keep critical services running when cyber disruption becomes real. That is the true measure of cyber resilience.

Cohesity is not the only vendor in this market; you can find a detailed evaluation of this and other vendors in our Leadership Compass Cloud Backup for AI-Enabled Cyber Resilience. 

To explore best practices in securing and governing human and non-human identities at scale, join us at AIdentity & Non-Human Identity Impact Day 2026 in Munich, Germany, on October 6.

Nitish Deshpande, Senior Analyst at KuppingerCole Analysts, provides an independent perspective on evolving identity security challenges. He discusses why native directory tools are no longer sufficient to protect against modern attack techniques, explores how unrestricted administrative access amplifies risk, and outlines strategic approaches to minimizing lateral movement. He also explains how modern identity architectures and access mediation align with Zero Trust principles.

Robert Kraczek, Global Strategist at One Identity, dives into practical implementations of air‑gapped directory access using an architectural approach that restricts direct interaction with the directory itself. He shows how solutions such as Active Roles enable fine‑grained delegation to tightly control administrative access, apply automation to enforce joiner/mover/leaver workflows consistently, and ensure identity changes are executed immediately and securely. Through real‑world use cases, he demonstrates how organizations can reduce lateral movement risk while maintaining operational efficiency.

Attackers have always studied patches to locate the flaw that a patch repairs. What has changed is the economics of that work. Identifying what changed and turning that into a working exploit used to require rare skill, specialized tooling, and patience. The latest generation of frontier AI models, exemplified by Mythos, eliminates much of that effort, making techniques that once belonged primarily to well-funded, highly skilled groups available to a much broader population of attackers.

This is what destabilizes the long-standing equilibrium between attackers and defenders. The patch is no longer just a remedy. It can quickly become a blueprint for the exploit, and the time window defenders once counted on is shrinking fast.

This does not shift the defender’s problem from prevention to speed alone but makes speed a condition of prevention. Organizations have less time to assess exposure, validate changes, deploy fixes, and recover when something does slip through. And because AI agents and AI-generated applications increasingly reach directly into enterprise data, the database becomes one of the control points that matter most.

Oracle’s response to this challenge, framed around the principles of Secure at Source, Secure at Speed, and Secure through Resilience, places controls, patching, and recovery directly in the data layer rather than relying only on the systems around it.

Security should not be a budget line that attackers exploit

The centerpiece of Oracle’s announcement is economic. Several of its widely deployed security, patching, testing, and lifecycle management tools are now available at no cost for a limited period, or at a steep discount on one-year term licenses, across cloud, multicloud, hybrid, and on-premises environments.

Anything that gives organizations more security per dollar is useful. In the AI era, it is close to essential. When security carries a separate price tag, many organizations resort to rationing it. They scan less often, cover fewer systems, and defer upgrades that the budget cannot absorb this quarter. We have seen this dynamic before in other parts of the security market, especially with tools priced by data volume, where customers end up dropping important signals simply to stay under quota. Pricing that forces defenders to limit their own protection is an antipattern in any situation. Against attackers operating at the speed and scale of AI, it becomes a liability.

Vendors that make baseline security easier to consume, and that create customer value through infrastructure, services, automation, and guidance rather than through friction around essential controls, are getting the economics of security right. Removing the procurement conversation from the critical path of patching is the right call. A database owner who can deploy protection today, without waiting on a purchase cycle, is well-placed to prevent the next security incident.

Access is necessary, but it is not sufficient

Removing the price barrier solves one problem. It does not solve the one that has defeated security programs for decades: tools are worthless if no one turns them on.

The history of cloud and database security is littered with incidents that had little to do with missing controls and much to do with controls that were unused, poorly understood, or misconfigured. The best security capabilities do nothing if no one enables them, and they help no one if no one knows they exist. Free licenses lower the cost of entry. They do not automatically supply the operational knowledge, deployment patterns, or institutional discipline that turn a capability into a control.

This is where Oracle’s longer track record matters, and where it should now press harder. Capabilities such as Oracle Deep Data Security, Oracle SQL Firewall, and Oracle Database Vault enforce policy inside the database, where applications, users, or AI agents have fewer opportunities to quietly route around it. Controls applied close to the data, and enabled by default where appropriate, are not only good governance. They are a lifeline for the many organizations that lack the in-house expertise to make every security decision correctly. Secure by default protects the majority who will never read the documentation, and that is precisely the point.

Making the tools free is the easier part. The harder and more valuable work is driving adoption: education, deployment guidance, reference practices, and the steady drumbeat of reminders that move a customer from owning a license to running a process. Oracle should treat that as the real deliverable.

A welcome offer, with a question about its shelf life

The offer is structured as a promotion. The no-cost tier runs for a defined window, the discounted licenses for a slightly longer one, and both assume the customer already carries current support. On a careful reading, several of the tools are available at no cost for patching and upgrading specifically, not as a permanent change to how they are licensed.

As a way to remove friction at a moment of acute risk, this approach is reasonable. It creates urgency and gets customers moving now, which is exactly what the threat timeline demands.

If protection that organizations come to depend on reverts to a paid feature once the window closes, the budget-rationing this announcement was meant to disrupt will quietly return. Security that lapses back behind a paywall trains customers to treat it as optional again. Oracle should make the security-critical pieces permanently accessible, as a statement that keeping databases patched against AI-speed exploits is not a premium feature. Keep the cost of doing the right thing low, and security stops being the corner that gets cut first.

The autonomous endgame, and why it will take time

There is a cleaner solution embedded in Oracle’s own recommendations, and the company names it explicitly. Moving workloads to Oracle Autonomous AI Database shifts patching, encryption, and much of the security burden from the customer to Oracle itself. Updates apply without the customer negotiating each maintenance window, and security is enabled by default with fewer switches to forget. For the patch-application gap, that is the most complete answer on the table.

In an ideal world, every eligible workload would already be there.

In practice, migration is measured in years, not quarters. It depends on application compatibility, organizational appetite, regulatory constraints, and customer effort at least as much as on anything Oracle does. Most enterprise database estates will run a mix of versions and deployment models for a long time. The free and discounted tools are the bridge for that reality: a way to raise the security floor across the existing fleet while the longer migration plays out.

Recommendations

For existing Oracle customers:

• Inventory your databases before anything else. You cannot patch, or prove you have patched, what you have not cataloged. Use Oracle Database Lifecycle Management Pack and Oracle Exadata Management Pack to discover versions, dependencies, and exposure across your entire infrastructure.
• Claim the tools while the offer is available and use the patching packs together with Oracle Real Application Testing and Oracle GoldenGate to remove the usual excuses for delay.
• Treat patching as a repeatable, governed process rather than a periodic project. Standardize the workflow, automate it across environments, and report compliance to security and executive stakeholders so it survives shifting priorities.
• Do not let the promotional window become your planning horizon. Decide now which capabilities you will keep operating after the offer ends, and budget for them as well.
• For qualifying workloads, evaluate migration to Oracle Autonomous AI Database as the long-term solution that removes much of this burden entirely.

For organizations still evaluating Oracle:

• Read the announcement as a signal about total cost of ownership, not as a discount coupon. A platform that enforces security inside the data layer and bundles lifecycle, testing, and recovery tooling can lower the hidden operational costs that rarely surface in product comparisons.
• Weigh the secure-by-default posture against the alternatives. For teams without deep database security expertise, controls that are harder to misconfigure are worth more than a longer feature list.

The bigger picture

AI is turning economics itself into a security control. When attackers automate their exploits, the speed at which a defender can act is limited by cost, testing, and downtime between knowing and acting.

Oracle’s announcement attacks the cost portion of that friction directly, putting proven, widely deployed tools in customers’ hands now. Its lasting value still depends on whether the company invests as much in driving adoption of these tools, and whether it keeps them permanently in place rather than as a temporary promotion.

But the threat does not wait. Organizations should act now, use what the offer makes available, and get used to patching and upgrading more often in the AI era.

Key Topics:

✅ How IGA has evolved from static, siloed tools to integrated, multi-identity platforms
✅ Non-human identities: IGA vendors are now covering NHI governance — and customers are demanding it
✅ Where IGA still falls short: role mining, anomaly detection, policy simulation, and workflow automation
✅ The deployment model debate: SaaS vs. on-premise vs. hybrid — and the feature parity problem
✅ EU sovereignty as a competitive differentiator for European IGA vendors
✅ What's coming next: real-time governance, access intelligence, and a new IGA report category

44 vendors evaluated, a surge of newcomers, and a market quietly reinventing itself — the KuppingerCole IGA Leadership Compass is out now and covers everything discussed in this episode.

At KuppingerCole Analysts, our motto for more than two decades has been simple: stop looking at labels, look for substance and for the ability to address real challenges. Security Posture Management is a useful test of that principle, because the SPM family has become one of the clearest examples of a label outliving its meaning. A buzzword loses its definition the moment enough vendors decide they sell it, and SPM passed that point some time ago.

One capability, four names

Strip away the prefix and every SPM product follows roughly the same pattern. It connects to an environment, assesses configuration and state against a set of policies, and produces a list of things that are wrong. Continuous assessment of posture against policy is a genuine and valuable capability. It is however not a new market every time someone points it at a different asset class.

That is the part the suffix conveniently hides. CSPM, DSPM, SSPM, and AI-SPM are not four fundamentally different ideas. They are one capability aimed at different targets.

The targets matter, of course. Cloud infrastructure, SaaS applications, sensitive data, and AI systems all have different architectures, risks, owners, and remediation paths. But that is exactly the point. The value is not in the shared suffix. The value is in how well the product understands the asset class, the risk model, and the operational workflow behind it.

CSPM: not dead, just absorbed

The capabilities behind CSPM remain useful. They also stopped being a standalone product. Misconfiguration detection, compliance mapping, and cloud risk assessment were quickly folded into broader cloud-native application protection platforms (CNAPP), where they belong, sitting next to workload protection, entitlement management, runtime controls, and remediation workflows. No one needs a separate posture tool whose main deliverable is glorified vulnerability scanning with cloud credentials and a talent for generating five thousand tickets.

A finding you cannot act on is not a security outcome. It is homework. That does not make CSPM useless. It makes CSPM a capability inside something larger. This is a perfectly respectable fate for a security category. It is also one that tends to annoy vendors who built a marketing strategy around the assumption that the suffix would remain billable forever.

DSPM: the same journey, with a detour

DSPM followed a similar path, except it took a more scenic route through inflated expectations. Its core scope is real and foundational: discover sensitive data, classify it, identify exposure, and surface the misconfigurations and access risks around it. Treated as the first layer of a data security program, that work is essential. For a while, though, DSPM was sold as the answer to data security, full stop.

A DSPM tool that only assesses posture cannot deliver the outcome customers were promised, because finding exposure is not the same as fixing it. Posture visibility tells you the house is on fire. It does not hold a hose. And the moment a vendor adds real remediation, protection, workflow integration, and enforcement, the tool has moved beyond posture management. It has become part of a data security platform.

Keeping the DSPM label on it at that point does not describe the product. It keeps the trendier acronym alive a little longer. DSPM is necessary but not sufficient. And when it finally becomes sufficient, it is no longer just DSPM.

SSPM: real, but already outgrowing its name

SSPM points the same machinery at SaaS applications. It connects to Microsoft 365, Salesforce, GitHub, and the dozens of other tenants a modern company runs, then checks them for misconfiguration, over-privileged accounts, dormant admin rights, and risky third-party access. This is genuinely useful work. SaaS sprawl is real, almost nobody configures these applications securely by default, and the blast radius of a single over-scoped integration token is larger than most people realize.

But notice what actually creates the value, and it is not the suffix. It is coverage and depth: how many applications the tool understands, and how well it understands each one. A product that inspects five SaaS apps shallowly is not a category. And the capability follows the same gravitational pull as CSPM, being absorbed into identity security, SaaS management, and SSE platforms, where posture findings sit next to the access and configuration controls that can actually fix them.

AI-SPM: a label in search of a market

AI-SPM is the newest entry in the family, and the cleanest illustration of the problem, because the term is still fresh enough that almost everyone can claim it and almost no one has to define it. Naturally, this has not slowed anyone down.

The label is currently being applied to several different architectures: cloud platforms extended to inventory AI services, data security tools extended to cover training and inference data, purpose-built AI asset discovery and governance platforms, and AI runtime protection products with a posture dashboard bolted on. These are different products, aimed at different problems, often sold to different buyers. They share a hashtag, not a category.

Category boundaries matter because they shape budgets, shortlists, evaluation criteria, and expectations. If AI-SPM means “cloud posture management, but now we also detect Bedrock,” that is one thing. If it means governing AI models, datasets, prompts, agents, tools, permissions, runtime behavior, and regulatory obligations, that is something very different. Pretending both are the same market helps no one except the people printing booth banners.

None of this means the underlying problems are imaginary. Shadow AI is real. Agent permissions are real. AI data leakage is real. The EU AI Act, with penalties reaching €35 million or 7% of global annual turnover, whichever is higher, is extremely real.

The question is not whether AI introduces new security and governance challenges. It is whether putting “SPM” into product names does anything to address them. Spoiler alert: it does not.

What to do when the next prefix arrives

So how should buyers respond the next time a new letter or two shows up in front of SPM?

First, ignore the suffix and write down the capabilities you really need: discovery, classification, posture assessment, policy evaluation, prioritization, enforcement, remediation, and reporting. Map products to that list, not to the acronym on the data sheet.

Second, ask what the tool fixes, not only what it finds. A posture product that cannot remediate, or at least trigger remediation through something that can, is just another input for real security tools. It is not a control.

Third, check whether the capability already exists in a platform you own. CSPM is the cautionary tale here. Plenty of organizations bought it once as a point tool and again inside CNAPP, which is a very expensive way of discovering that suffixes can be recycled.

Fourth, for AI, define the scope before shopping for the label. The defensible boundary is the governance and security layer specific to AI systems as a distinct class of asset, drawn deliberately to avoid overlap with the cloud, data, network, application, and identity controls you already have.

A useful label gives buyers a shortcut to a real set of capabilities, problems, and outcomes. But once everyone claims the label, it stops being a shortcut and becomes noise. Look for capabilities, workflows, outcomes. The acronym will have changed by next quarter anyway.

John Tolbert, Director of Research and Principal Analyst at KuppingerCole Analysts will draw on his recent Leadership Compass reports on CIAM and B2B IAM to explore how AI agent interactions are reshaping both domains, highlight unresolved architectural gaps in current IAM platforms, and examine why existing delegation, audit, and licensing models fail under agent-driven workloads.

Ayesha Dissanayaka, Associate Director and Lead Architect for Agent Identity at WSO 2 will focus on the practical side of this transformation, addressing how to secure agentic workflows, implement identity for autonomous systems, and build scalable, governance-driven architectures that enable trusted machine-to-machine interactions across complex enterprise environments.

Don’t miss the opportunity to join Senior Analyst Warwick Ashford for an informative webinar in which he will provide an overview of the KuppingerCole Leadership Compass on MDR 2026. He will explore how the MDR market is changing, the key findings of the report, the capabilities that now define leadership, and the criteria used to evaluate vendors. He will also discuss market drivers, delivery models, outcome-focused service expectations, and the increasing importance of identity protection, automation, integration, and exposure management in modern MDR.

As organizations adopt AI-driven Security Operations (SecOps), Extended Detection and Response (XDR), Security Information and Event Management (SIEM), and Cloud-Native Application Protection Platforms (CNAPP), they are becoming dependent on security control planes that aggregate telemetry, automate response actions, and increasingly make autonomous security decisions. These platforms are the operational nerve center for cybersecurity.

The question is most acute in Europe, where customers face a complex regulatory environment and where the leading SecOps platforms are supplied by vendors headquartered outside the EU.

This raises a new challenge: SecOps Sovereignty.

From Cloud Sovereignty to SecOps Sovereignty

In previous blogs on cloud sovereignty, I identified four categories of sovereignty risk: data, technology, operational, and infrastructure. For SecOps the same lens applies, but data concerns are best framed as a legal-jurisdiction question and technology dependencies as a supply-chain question, giving four somewhat different categories:

In some respects, the risks are amplified because security platforms hold privileged visibility and control across the entire enterprise.

Unlike regular cloud workloads, SecOps platforms collect and analyze:

• Security events
• Network telemetry
• Identity data
• Vulnerability information
• Incident records
• Threat intelligence

In many cases, they can also take direct actions such as isolating endpoints, blocking users, modifying firewall rules, or shutting down workloads.

The sovereignty risks related to these systems can therefore not only affect data confidentiality but also threaten operational resilience.

Legal Risk

Risk: Unauthorized but legal access to SecOps related data.

Most leading SecOps platforms are operated by US-headquartered vendors, placing European customers' security telemetry within the reach of US legal process. This creates familiar concerns regarding extraterritorial legislation and foreign government access requests. Security telemetry often contains sensitive information about organizational structures, network architectures, privileged users, and critical assets.

For regulated sectors such as healthcare, financial services, defense, and critical infrastructure, exposure of this data may present a greater risk than exposure of ordinary business data.

The issue extends beyond data residency. Even if security data remains physically within Europe, questions remain regarding who can access it, under what legal authority, and whether foreign governments can compel disclosure through legislation that applies to the vendor.

Operational Risk

Risk: Loss of access to SecOps capabilities and data during periods of geopolitical tension.

Modern SecOps platforms now typically operate as centralized SaaS control planes.

Security teams rely on them to investigate incidents, orchestrate responses, and manage automated detection capabilities. If access to these platforms is disrupted by sanctions, export controls, geopolitical disputes, or vendor decisions, security operations may be significantly impaired.

As geopolitical tensions increase, organizations are evaluating whether critical digital services remain available during periods of international conflict or regulatory confrontation.

Organizations must therefore ask:

• Can we continue to detect threats if the service becomes unavailable?
• Can we access historical security telemetry?
• Can we export rules, playbooks, and threat intelligence?
• Can we operate independently during a geopolitical crisis?

These questions are familiar from cloud sovereignty debates, but acquire new urgency when the system being disrupted is the one detecting attacks.

Infrastructure Risk

Risk: Loss of access to SecOps capabilities and data.

Security operations platforms depend on cloud infrastructure, data processing facilities, networking services, and AI infrastructure.

Even where a security vendor offers regional hosting, dependencies may still exist on foreign-owned infrastructure, global management planes, or externally controlled AI services.

The sovereignty question therefore extends beyond where logs are stored to encompass the entire operational stack that processes, correlates, and analyzes security data.

Supply Chain Risk

Risk: Loss of Trust in the SecOps data and capabilities.

SecOps platforms incorporate multiple layers of third-party dependencies:

• Threat intelligence providers
• AI and machine learning services
• Cloud infrastructure providers
• Open-source components
• Managed detection services

This creates complex supply chain dependencies that may not be visible to customers.

A sovereign SecOps strategy therefore requires transparency regarding who operates critical services, who controls updates, where AI models are hosted, and how dependencies are governed.

As with cloud sovereignty, supplier diversity and architectural openness become important mitigations.

The CNAPP Challenge

CNAPP are becoming the control plane for the AI-native business but are mostly US-owned. This creates a particularly interesting sovereignty challenge.

By design, CNAPP solutions aggregate data across cloud environments, identities, workloads, Kubernetes clusters, application pipelines, and security controls. They have become the single source of truth for cloud security posture and risk management.

This concentration of visibility creates significant value but also increases sovereignty concerns.

Organizations evaluating CNAPP solutions should therefore consider:

• Where security telemetry is processed
• Who controls the management plane
• Whether customer-controlled encryption is available
• How data portability is supported
• What happens during a geopolitical disruption
• Whether AI-driven analysis can operate within sovereign boundaries

As CNAPP platforms become increasingly AI-enabled, sovereignty considerations will extend to model training, inference locations, and control over security-related AI systems.

Palo Alto Networks and Deutsche Telekom: A New Direction

In June 2026, Palo Alto Networks and Deutsche Telekom announced Sovereign Cortex with T Security, a service that brings Palo Alto Networks' AI-driven Cortex SecOps platform to European regulated industries with sovereignty controls independently governed by Deutsche Telekom.

The significance of this announcement is not simply that data remains within Europe. Rather, it reflects a broader recognition that security operations platforms have themselves become sovereignty-sensitive infrastructure.

The announced offering combines Palo Alto Networks' security analytics and AI capabilities with Deutsche Telekom acting as a European trust anchor, providing governance and operational controls aligned with European sovereignty requirements. The initial target for this includes organizations in healthcare, financial services, the public sector, and critical national infrastructure.

Whether such approaches fully mitigate sovereignty concerns remains open to debate. Sovereign Cortex is itself hosted on Deutsche Telekom's Sovereign Google Cloud Platform, with Telekom Security holding the encryption keys in its own data centers: this layered architecture illustrates how difficult it is to separate European SecOps fully from US-controlled infrastructure. However, the announcement signals that the market is beginning to recognize SecOps sovereignty as an important distinct requirement.

Final Thoughts

The next phase of digital sovereignty will not be defined solely by cloud infrastructure.

As organizations increasingly rely on AI-driven security operations, sovereignty concerns must extend to platforms that monitor, analyze, and protect their digital environments. Security operations systems are becoming critical national and organizational infrastructure.

The key question is no longer: "Where is my data?"

Instead, organizations must ask:

"Who controls my security operations, who can access them, and will they continue to function when geopolitical conditions deteriorate?"

SecOps sovereignty is about ensuring that organizations retain control of their security posture, incident response capabilities, and cyber resilience regardless of legal, political, or geopolitical disruption.

As sovereignty debates move beyond cloud infrastructure and into cybersecurity operations, SecOps and CNAPP platforms will the EU Cloud Sovereignty Framework be enough.

Join a KuppingerCole Impact Day to get practical insights on identity, security, and digital transformation.

In this case, however, the AI story was connected to a real enterprise problem: complexity. Enterprises are not standardizing on one cloud, one application architecture, or one AI model. They operate across data centers, public clouds, edge locations, SaaS services, APIs, Kubernetes clusters, and AI inference environments. F5’s message at AppWorld was that this complexity is not a temporary phase on the way to something cleaner but, in fact, the new operating model.

The company is repositioning application delivery as a strategic control point for the AI-era enterprise. In the roadmap session, F5 described the infrastructure shift as moving “from packets to tokens,” which may be the most precise framing. Traditional application delivery was about traffic, protocols, and availability. The next-generation application delivery stack must also understand APIs, models, agents, data flows, runtime policy, token costs, and AI-specific risks.

Application Delivery Is Relevant Again

The central story is F5’s Application Delivery and Security Platform, or ADSP. This is the umbrella under which F5 is bringing together BIG-IP, NGINX, and Distributed Cloud Services capabilities like WAF, API security, bot defense, observability, and AI security. The ambition is obvious: make it the platform that delivers, secures, observes, and increasingly governs applications wherever they run.

Of course, every technology vendor wants to be a platform because “platform” has become the default claim of any company assembling more than two products. F5's claim is harder to dismiss than most. Large organizations already rely on F5 in the data path for critical application delivery, resilience, and security. The company is trying to extend an existing infrastructure position into a world where application traffic increasingly includes APIs, AI models, and autonomous agents.

This also fits a broader point I made recently in Why API Security Is Becoming the Core of Enterprise Cyber Defense: APIs are no longer just developer plumbing. They are the channels through which business logic, data access, automation, and increasingly AI agents operate. Application delivery and API security are therefore no longer adjacent topics. They are becoming part of the same control problem.

Hybrid Multicloud Is the New Baseline

F5’s event narrative was built around the idea that hybrid multicloud is no longer a transitional mess. It is the baseline. According to F5's own research, 93% of organizations now operate in hybrid multicloud environments, with F5 customers running applications across an average of more than 19 environments.

That complexity is precisely the problem F5 Insight for ADSP is designed to address. The company acknowledged that customers value the technology, but that understanding what it does, managing it across environments, and transferring knowledge between teams can be difficult. Insight is intended to change that by turning telemetry into natural-language explanations, root-cause analysis, application health views, and prioritized remediation guidance.

APIs, AI, and Runtime Control

F5 is extending API discovery and protection deeper into enterprise environments, including BIG-IP deployments and air-gapped local editions. API security is often discussed as if the main issue were public-facing APIs exposed through modern cloud gateways. In reality, many important APIs are internal, hybrid, undocumented, or connected to legacy systems.

Every time an AI application calls a model, every time an agent calls a tool, and every time a workflow stitches together services, APIs are doing the work. This is why F5’s AI security story is strongest when framed around runtime control and remediation, not just detection. The combination of F5 AI Red Team, F5 AI Guardrails, and AI Remediate is meant to identify weaknesses, translate them into runtime protections, and let the customer decide when these protections go live.

That human-in-the-loop element is important. Agentic AI is not just an authentication problem or a prompt security problem. MCP servers, tool definitions, agents, and downstream integrations create a dependency graph that must be inventoried, reviewed, and monitored at runtime. A valid token does not mean safe behavior. It only means someone or something was allowed to connect.

AI agents are changing the nature of data access because they chain operations, combine data sources, and adapt behavior based on intermediate results. F5 does not own the data layer, but its position in the traffic path gives it a relevant enforcement and observation point for these new flows.

Sovereignty and Resilience

Digital sovereignty was another important theme, especially in the European context. F5 framed it as autonomy over data, technology stack, and operations, including where data lives, how quickly organizations recover from disruption, which infrastructure providers they depend on, and how much they rely on any single provider. That is the right direction, because digital sovereignty is often reduced to data residency, which is far too narrow.

For F5, sovereignty can be a tailwind. In the analyst Q&A session, the company’s leadership argued that many customers are moving away from overreliance on U.S. hyperscalers toward on-premises deployments, local cloud alternatives, and customer-controlled infrastructure. At the same time, F5 remains a US vendor, so the sovereignty message must be handled carefully. The stronger argument is not “buy from us instead of hyperscalers” but one centered on deployment choice, operational autonomy, and customer control over where critical functions run.

This also echoes the argument I made in Platform Dependence and the Growing Fragility of the Internet: resilience cannot be outsourced entirely. Platform consolidation creates efficiency, but it also creates dependency. Sovereignty without resilience is just a different form of fragility.

Cryptographic agility is a case in point. F5 BIG-IP v21, highlighted at the event, adds support for hybrid ciphers combining classical ECC with ML-KEM - incremental and non-disruptive by design, which is precisely how infrastructure adapts before it is forced to.

The Caveats: Convergence, Developers, and Agents

There are still areas where F5 needs to prove execution. The first is platform convergence. ADSP is a compelling umbrella, but F5 must bring together several product families with different histories, deployment models, and operating assumptions. A genuinely converged platform would deliver common policies, shared telemetry, simpler operations, clearer packaging, and a realistic migration path.

The second is developer relevance. F5 was clear that its enterprise engagement model remains centered on NetOps and SecOps, not developers. And yet, agentic AI, MCP usage, and AI-assisted application development often start in development and test environments before reaching production. F5 does not need to become a developer tools company, but it will need a credible way to influence platform engineering and application design earlier in the lifecycle.

The third is agent identity. The industry has not yet established how to authorize agents continuously and in context, and F5 has no answer here either, at least not yet.

Bottom Line

F5 is addressing real enterprise conditions: hybrid multicloud complexity, expanding API surfaces, AI-driven traffic, digital sovereignty demands, and a persistent shortage of specialist expertise.

The opportunity is significant because F5 already sits where many of these problems converge: in the data path, close to applications, APIs, users, bots, models, and agents. The risk is that convergence becomes too complicated before it becomes useful. F5’s job now is not to prove that it has enough products but to demonstrate that ADSP can become a coherent operating model for customers.

If F5 can make delivery, security, observability, and AI governance simpler across hybrid environments, the move from packets to tokens may give application delivery renewed strategic relevance.

Key Topics:

✅ Agentic AI as a new class of insider threat — autonomous, non-deterministic, and without ethics
✅ Data-centric defense vs. agent discovery: protect the vault, not the crowd
✅ Why dynamic authorization and behavior analytics are the IAM industry's urgent next step
✅ Data sovereignty and geopolitics: eroding trust in non-European SaaS vendors
✅ AuthZEN wins the EIC Award — a standard built before anyone knew the problem it would solve
✅ Martin Kuppinger's closing keynote: "Everything we failed to solve in the past decades bites back now"

"An agent behaves like a human insider threat — but without any sense of right or wrong." If your IAM program isn't ready for that, this episode is required listening.

Alejandro Leal, Senior Analyst at KuppingerCole Analysts will explore how PAM vendors are addressing NHIs, cloud entitlements, and real-time authorization challenges. They will analyze the convergence of PAM with IGA and CIEM, while highlighting gaps, vendor strategies, and implications for modern security architectures.

Key Takeaways:

• Understand how privilege access has shifted over the years
• Learn how NHIs and Agentic AI reshape PAM priorities and risk models
• Explore PAM capabilities beyond vaulting and session control
• Examine convergence between PAM, IGA, and CIEM
• Assess vendor approaches across global PAM markets

Attendees will get a preview of the Leader chart along with analyst commentary on methodology, market structure, and the capabilities that define high performers. Whether you are building a B2B IAM strategy, evaluating solutions, or benchmarking your own platform, this session delivers structured insight grounded in primary research.

John Tolbert, Director of Research and Lead Analyst at KuppingerCole, has enterprise practitioner experience and deep analyst expertise to this topic. Before joining KuppingerCole, John worked as a security specialist at Fortune 500 companies and tech startups, giving him firsthand exposure to the operational realities that B2B IAM solutions must address. He will walk through the Leader chart, explain the evaluation methodology, and share candid observations on what the market is getting right and where gaps remain. Participants will leave with a sharper analytical lens for evaluating solutions in this space.

Key Takeaways

• Understand what B2B Identity and Access Management (B2B IAM) is and why it requires a distinct evaluation framework from workforce IAM and CIAM
• Get a first look at the KuppingerCole's Leadership Compass on B2B Identity and Access Management, including a preview of the Leader chart and insights into the evaluation methodology
• Learn which capabilities separate market leaders from the rest, including identity federation, delegated administration, partner lifecycle management, fine-grained authorization, and Know Your Business (KYB)
• Explore emerging trends shaping the B2B IAM market, such as federated background checks, AI-assisted governance, and evolving regulatory requirements
• Gain practical guidance for evaluating B2B IAM platforms, understanding common solution gaps, and defining selection criteria for your organization

Yet beneath the headlines, a different story has been unfolding.

• Recent data suggests that more technology professionals are moving from the US to Europe than in the opposite direction.
• The EU's technology sector has become an increasingly important contributor to the economy. In 2023, it generated more than €816 billion in value added, representing 5.24% of the EU's total gross value added (GVA).
• Between 2015 and 2025, the number of funded tech companies in the EU increased from 13,000 to 40,000.
• Venture investment in European defense tech reached €2.5 billion in 2025, more than 10-fold since 2020. For comparison, venture investments into US-based defense tech startups totaled approximately $38 billion through the first half of 2025.
• Over the past decade, the number of ICT specialists in the EU increased by 59.4%, more than 6 times the increase (9.8%) in total employment.
• In 2025, after three consecutive years of declining investment, the European venture capital market showed signs of recovery with €66.2 billion invested. Approximately 36% of European VC funding went to tech companies that year, up from just 19% in 2021.

These statistics do not put the EU on equal footing with the US. However, they reflect a gradual shift in investor confidence. Although Europe lags behind the US and China in terms of overall size, its technology ecosystem is growing in ways that warrant closer attention.

The Sovereignty Debate

Over the past year, discussions around digital sovereignty have moved from the margins of policy debates to the center of the EU's technology agenda. A series of geopolitical and economic developments have contributed to this shift, including supply chain disruptions, growing tensions between the US and China, the extraterritorial reach of legislation such as the U.S. CLOUD Act, and broader concerns about Europe's dependence on foreign cloud providers, artificial intelligence (AI) infrastructure, semiconductors, and critical digital services.

Together, these developments have prompted policymakers to examine whether the EU can maintain sufficient control over the technologies upon which its economy, public services, and critical infrastructure increasingly depend.

As this KuppingerCole Analysts’ Advisory Note argues, the real question is not whether digital sovereignty supports the EU's technological and economic interests, but rather how digital sovereignty can be structured to support these interests without undermining security or economic competitiveness.

Against this backdrop, the European Commission introduced the European Technological Sovereignty Package on June 3rd, 2026. The initiative aims to strengthen the EU's capabilities in semiconductors, AI, cloud infrastructure, and open-source technologies.

As Commission President Ursula von der Leyen noted, the objective is to ensure that Europe can "make its own choices" when it comes to the technologies on which its economy increasingly depends.

The package includes two legislative proposals. The first, the proposed Chips Act 2.0, seeks to expand semiconductor capacity, support strategic investments, and strengthen links between chipmakers and growing sectors, such as cloud, data centers, and AI. The Cloud and AI Development Act complements this by aiming to significantly increase European data center capacity while supporting sustainable AI innovation and establishing a common framework for assessing cloud and AI sovereignty.

Additionally, the package includes an Open Source Strategy that will support a stronger open-source ecosystem by investing in skills, open-source start-ups, and the long-term maintenance and security of Europe’s open-source digital infrastructure. These efforts may not generate the same attention as billion-dollar funding rounds, but they create the foundations that allow digital businesses to emerge and scale.

Beyond the immediate implications for software development and innovation, these investments also matter for cybersecurity and identity and access management (IAM) professionals. Strong digital ecosystems create demand for secure authentication, digital trust services, identity verification, and privacy-preserving technologies.

They also increase the need for interoperable identity frameworks capable of supporting cross-border digital services, digital wallets, and emerging AI-driven applications. As organizations adopt more cloud-based and distributed architectures, identity increasingly becomes the control plane through which access, trust, and governance are enforced.

From Growth to Strategy

For decades, the US acted as the primary destination for technology professionals from around the world. As noted earlier, however, migration patterns have begun to shift. According to recent analysis, the flow of technology talent toward Europe has increased, supported by growing innovation hubs in cities such as London, Berlin, Paris, Dublin, and Stockholm.

Political developments, immigration policies, and changing perceptions of opportunity have all contributed to this trend. Whether this trend proves temporary or permanent remains uncertain. Nevertheless, access to skilled engineers, researchers, and entrepreneurs remains one of the most important ingredients in building successful technology ecosystems.

Europe’s technology growth is often framed as an economic issue. It is increasingly a strategic and geopolitical one. The debate around digital sovereignty is not simply about reducing dependence on foreign technology providers. It is also about ensuring that the EU can develop, retain, and scale its own capabilities in critical digital sectors.

However, the EU continues to face substantial gaps in scale, investment, and market fragmentation when compared to the US and China. Yet the direction of travel is becoming clearer. Policymakers increasingly view technological capability as a strategic asset, one that affects economic competitiveness, security, resilience, and long-term prosperity.

As outlined in the Draghi report, for tech companies to scale and grow, the EU must expand venture capital and continue to promote an independent digital ecosystem that empowers European startups to grow at home, whether that’s in Dublin or Paris, and not flee to Silicon Valley or Shenzhen.

Europe still faces significant challenges. Yet the recent growth in investment, digitization, talent attraction, and strategic initiatives suggests that the conversation can no longer begin and end with comparisons to the US. Increasingly, the story is about what Europe is building.

Key Topics:
✅ Why B2B IAM sits between workforce IAM and CIAM — and why neither alone is sufficient
✅ Delegated administration: handing identity governance to partner and supplier organizations
✅ Federation, lifecycle management, and the risks of trusting external HR processes
✅ "Know Your Business" — vetting organizations, sanctions screening, and org-level trust
✅ Fine-grained authorization: why RBAC falls short and ABAC/RBAC are taking over
✅ Agentic AI in B2B IAM: agents acting on behalf of external organizations

Supply chains with thousands of partner organizations, freelancers with hour-long access windows, and AI agents acting on behalf of external companies B2B IAM has to handle all of it. KuppingerCole Analysts' first B2B IAM Leadership Compass is out now read it alongside this episode to get the full picture of an emerging market you can't afford to ignore.

Key Topics:

✅ What CDNs are and why they're no longer optional for competitive organizations
✅ How CDN and DDoS mitigation differ — and where they overlap
✅ Cache busting, HTTP floods, Slowloris and other real-world attack vectors
✅ Why "security-first CDN" is fundamentally different from "CDN with security bolted on"
✅ What CISOs and infrastructure leaders should look for when evaluating CDN solutions
✅ How to measure CDN value from day one: round trip time and time to render

A CDN without security is just a bigger target — find out why building security in from the ground up changes everything.

This webinar cuts through the market noise to address what generic replacement messaging ignores: the governance risks that emerge *during* transition, the structural limitations of Entra-only strategies for AD lifecycle, and how behavioral analytics can surface over-provisioning before it follows you into your new environment.

Nitish Deshpande, Senior Analyst at KuppingerCole Analysts, will examine the identity governance transformation that SAP IDM end of life demands, beyond just the platform replacement. He will assess the market landscape, outline what organizations most commonly overlook in migration planning, and discuss how behavioral-driven governance strengthens compliance and reduces entitlement risk across hybrid environments.

Robert Kraczek, Global Strategist at One Identity, will present a practical approach to SAP IDM migration using Identity Manager available on-premises or hosted via Identity Manager On Demand, alongside Active Roles for AD and Entra ID lifecycle management. He will explain why Entra alone does not close the AD governance gap, how Identity Manager's consistent governance model spans SAP and non-SAP systems regardless of deployment model, and what organizations should prioritize to reach the 2027 deadline without sacrificing governance continuity.

Key Topics:

✅ How the definition of "privilege" has shifted from admin accounts to dynamic runtime identity capabilities
✅ PAM convergence with IGA, CIEM, ITDR, SIEM, and SOAR — the end of the standalone PAM product
✅ Non-Human Identities (NHIs) and agentic AI: the silent accumulation of machine privilege
✅ Just-in-time access: the gap between concept and operational reality
✅ Deployment sovereignty: who controls the keys to the kingdom — SaaS, on-prem, or hybrid?
✅ AI and ML in PAM: separating genuine innovation from marketing inflation

"Most enterprises can tell you the number of employees they have — very few can tell you the number of machine identities." If that sounds familiar, this episode is for you.

Martin Kuppinger, Founder and Distinguished Analyst at KuppingerCole Analysts will explore the evolution from SAP-centric access control to unified governance across heterogeneous environments. He will highlight key findings from Leadership Compass reports, SAP Access Control & Security and Business Application Risk Management, discuss emerging trends, outline essential solution capabilities, and provide practical guidance on selecting technologies for effective risk management.

This webinar is designed for IT security leaders, IAM professionals, and enterprise architects seeking to modernize governance strategies across SAP and non-SAP environments.

What I notice year over year is simple. The conversations are getting more substantive, more cross-functional, and increasingly focused on the hardest aspects of IAM. And when you run into someone you worked with twelve years ago and spend ten minutes catching up on where those IAM programs stand today, that conversation alone tells you more about the state of the industry than most analyst reports.

Here is my take on EIC 2026 from where I sat. The short version: AI is setting the agenda, but the baseline work is setting the pace.

Agentic AI Was Everywhere. And Rightly so.

Agentic AI dominated the agenda this year, and rightly so. The implications for identity, authorization, and governance are profound. Martin Kuppinger's keynote extended the Fabric concept beyond identity, introducing the Cybersecurity Fabric and the AI Fabric as related but distinct architectures that share capabilities while serving different purposes. The same structured thinking that makes the Identity Fabric a useful tool for IAM architects now applies across a broader security and AI governance landscape.

That framing matters. Because what we see in Advisory conversations is exactly that challenge: organizations trying to make sense of overlapping capabilities, overlapping tools, and overlapping responsibilities across identity, security, and AI. The Fabric model gives them a way to think about that without starting from scratch.

There is a deeper tension here though. IAM has always been a slow-moving discipline by nature. But for roughly the last three to five years, the pace of change has fundamentally shifted. AI, non-human identities, agentic systems: these are not incremental developments. They are structural shifts arriving faster than most IAM teams can absorb. The technology is already in production. The governance frameworks, the best practices, the full lifecycle solutions: they are still catching up. That gap is real, and it was present in almost every serious conversation at the EIC. And it hits hardest where it was already difficult: IAM teams that were understaffed before AI arrived are now at serious risk of falling so far behind that catching up becomes structurally impossible.

But here is the Advisory observation: the organizations we talked to are not yet at the point of governing AI agents. Most of them are still working through foundational IAM challenges. CIAM strategy, IGA tool choices, target operating models, organizational alignment. Which raises the question that nobody has fully answered yet: how do we bring together where organizations actually are in their IAM maturity with what governing AI agents will require? That gap is the defining challenge the industry is now walking into.

The Identity Fabric Is Not Yet Common Knowledge

We opened our Tuesday workshop with a simple question: how many of you are familiar with the Identity Fabric concept?

More than half of the room had not encountered it before.

This is not a failure. It is a signal. The EIC community is growing. New people are entering the field, facing identity challenges for the first time, looking for frameworks that help them make sense of complexity. What landed was not a sales pitch but a structured way of thinking: the Identity Fabric, and our Reference Architecture combined with our Maturity Assessment as a practical starting point that gives organizations a clear path from where they are to where they need to be.

The workshop was full. And when Fressnapf's Lisa Zimmermann took the stage to walk through how we applied the Identity Fabric and the Maturity Assessment in a real project, the room got very quiet. That is what a real reference customer does. It turns a methodology into proof.   

When Practice Meets Theory

One of the highlights of the week was Patrick Teichmann together with Oliver Schluga from Erste Digital on stage. What they presented was not a polished success story. It was an unfiltered account of what a large-scale IAM transformation actually looks like in practice, inside one of the biggest banking groups in Central and Eastern Europe.

The message they brought to the stage was one that resonates with almost every organization we work with: IAM has to fit the organization, accounting for its specific context and constraints, without becoming a collection of isolated solutions. That sounds obvious. In practice, it is one of the hardest things to get right. Erste Digital had started where almost every organization starts, with a clean top-down concept, business roles neatly aligned to processes, everything mapped out on paper. But when that concept met the actual environment, with eighty thousand users spread across different authorization systems ranging from SAP and Office 365 to AWS, GCP, and proprietary layers that had grown organically over years, the gap between theory and reality became impossible to ignore. The only viable path forward was the combined approach: understand what actually exists, identify what works, and build from there rather than trying to impose a structure the environment could not support.

What made this land was seeing a real project, with real complexity, presented without a filter. That kind of practitioner transparency is rare and exactly what a room full of people dealing with the same challenges needs to hear.

This connects to one of the sharpest recurring questions from the week: RBAC is dead, yes, but how does an organization actually move toward dynamic authorization in a way that fits its reality? What does that transformation look like in practice, not in a whitepaper? Erste Digital's journey is one of the most concrete answers to that question available right now.

For Advisory, this is exactly the conversation we have with clients every week. The technology is rarely the bottleneck. The organizational alignment, the business involvement, the ownership model: that is where projects succeed or fail. Seeing it confirmed live by a practitioner, in front of a room full of people dealing with the same challenges, is the kind of moment that makes the EIC worth attending.

What Organizations Are Actually Asking For

The Luncheon this year ran as an open dialogue around questions that turned out to be more loaded than they sound: what does the IAM professional look like in the future, given AI? And how do you actually operationalize all of these topics in practice? Both triggered long conversations. Because the straightforward answer to both is: nobody really knows yet, and most organizations are figuring it out as they go.

Nowhere was this more visible than in the governance debates around AI. The spectrum of positions in the room ran from "humans must have the final word on everything and must understand every decision" all the way to "agents need to run fully autonomously, with independent models validating each other's actions." Both positions have logic behind them. The reality will be somewhere in the middle. But the open question, the one that nobody could answer clearly, is whether that middle ground will satisfy auditors and regulators. That question is not rhetorical. It is one of the most consequential open problems in the field right now. On AIdentity specifically, intent security emerged repeatedly as the topic generating the most uncertainty. Not because people lacked opinions, but because the existing frameworks and best practices only partially apply. The field is still crystallizing what good looks like.

CIAM is a major topic. Multiple organizations, across banking, retail, and manufacturing, are in the middle of tool selections, implementation projects, or strategic realignments. The questions being asked are very concrete and operational. Organizations want to know whether a tool will actually cover their authorization requirements, what the target operating model looks like once it is live, and who owns and runs it three years down the line.

IGA governance is the other recurring thread. Some are carrying self-built solutions that have outgrown their original design and need a strategic path forward. Others are mid-implementation and realizing that the governance model was never properly defined to begin with. And in more cases than one might expect, the tooling is actually working fine, but the organizational alignment around it is not.

A third pattern was AI and Identity. Organizations across industries came in asking about AI and identity, and what quickly became clear was how much uncertainty still exists. Not about whether AI matters for IAM, but about how to actually approach it. How do you manage machine identities in practice? How do you think about access for AI systems? How does any of this integrate into an IAM program that is already in flight? The questions were real. The answers, in most cases, are still being worked out.

The Value of Being Present

What stood out this year was where the best conversations actually happened. Rarely at the booth, more often at the side events, over dinner, or in the corridors between sessions. The informal setting changes the dynamic completely.

The EIC creates a concentration of the right people in the right place that simply does not exist anywhere else in Europe for this domain. CISOs, IAM leads, architects, and decision makers, all in one building for four days, all focused on the same set of challenges.

For Advisory, that density translates directly into meaningful engagement across financial services, retail, manufacturing, energy, and the public sector, with organizations working through the same core questions from very different starting points.

The Bottom Line

EIC 2026 confirmed what we see in project work every week. The identity market is maturing, but unevenly. Agentic AI is the headline topic, and the underlying research and thinking from KuppingerCole is strong. But for most organizations, the path to governing AI agents runs straight through the IAM fundamentals they have not yet fully solved.

That is exactly what Advisory is for. Helping organizations understand where they actually stand, where they need to go, and what a realistic path between the two looks like.

See you at EIC 2027.

As a scuba diver, I quickly learned that admiring the reef can never be my top priority. The unglamorous gear, the regulator and valves and gauges checked before the descent, is what decides whether a dive stays controlled. MCP is becoming that gear for enterprise AI: essential, increasingly invisible, and too often trusted before anyone has inspected it.

The MCP servers now spreading through enterprises are not just connectors. They are an unchecked dependency graph with access to tools, data, credentials, and business workflows. Many organizations adopting them cannot reliably say where a given server came from, who wrote it, what version is running, which permissions it holds, or what it does after the connection succeeds.

Recent MCP incidents have mostly been treated as normal software defects. A flaw appears, an advisory follows, the vendor ships a fix, and everyone applies it. Consider CVE-2026-32173 in which a missing authentication check let an unauthenticated caller access data it should never have seen. A patch fixed it, but it is the reflex behind it that is the real problem. Each patch fixes one defect and leaves untouched the thing that keeps producing them.

The larger pattern is that MCP is turning agentic AI into a supply chain and runtime governance challenge. In our research library, two recent KuppingerCole Analysts Leadership Briefs explain why MCP is the API security problem nobody is ready for, and without API security there is no AI security. Both hold because MCP routes requests, mediates access to enterprise systems, and inherits the API governance failures organizations already had. But API security is necessary here, not sufficient. The supply chain dimension is the part the industry keeps importing without inspecting.

The access-control layer is finally maturing. The MCP authorization specification defines authorization for HTTP-based transports, OWASP has published an MCP Top 10, and secure transport is getting real attention. These steps help answer who is allowed to connect and what scope they hold. They do not answer the harder question: what local commands, file paths, secrets, APIs, and downstream tools an MCP server can actually reach, and whether those capabilities are fixed, reviewed, and monitored.

The Recurrence Is the Signal

Consider the STDIO transport issue documented by OX Security in April 2026. It affects environments that automatically load or invoke MCP tools from configuration files, IDE extensions, marketplaces, or agent workflows. This is not a bug. It is a systemic weakness in implementations where untrusted MCP server configurations can lead to arbitrary command execution through official SDK behavior and common client integrations.

The problem is not only that one implementation got it wrong. It is that the same risky pattern keeps moving through the MCP ecosystem, while every downstream developer is left to catch and fix it locally. Many organizations were exposed to Log4Shell in 2021 through code they did not write and systems they had not fully inventoried. MCP can create the same blind spot, with tool behavior and server code inherited before anyone has reviewed them.

Then came the Claude Code source exposure through a packaging error. Within days, fake “unlocked” Claude Code repositories were distributing the Vidar infostealer. The lesson was painfully familiar: developer trust, package distribution, local configuration, and agentic tooling collapse into one attack surface very quickly. KuppingerCole Analysts has tracked this same run of malicious and compromised MCP servers across 2025 and into 2026.

The remediation advice from experts was obvious. It was also pure software supply chain language, and the industry reached for it by instinct even while continuing to file these incidents under API security. That instinct is correct. After all, there is no patch for a server doing exactly what its definition told it to do. 

What Organizations Need to Do Now

The real question is no longer whether an MCP server is authenticated. Authentication still matters. The question that matters more is whether anyone has audited what each MCP server is, where it came from, and what it is allowed to do. Treat tool definitions as software supply chain assets.

1. Start with inventory. You cannot govern a dependency graph you have never enumerated. Scan for MCP and SSE endpoints, identify the servers nobody registered, and bring the shadow AI surface under control.
2. Treat MCP manifests, server packages, skills, and agent configuration as production software, not convenience. Approved registries, pinned versions, validated provenance, and human review are the minimum bar before any tool definition reaches enterprise use. In practice, that means handling them like raw npm dependencies.
3. Stop treating a valid token as evidence of safety. A token tells you who connected but says nothing about the code behind the connection, which is exactly the gap non-human identity governance has to close as agents multiply.
4. Put CLAUDE.md files, skills, prompts, and agent configurations under the same review as an external pull request. In many environments, that is precisely what they are: instructions arriving from outside the security boundary, consumed by software that can act on them.
5. Monitor what servers do after they connect. Provenance and review govern the code you accept. Runtime monitoring governs the behavior you did not predict. Treating agents as trusted digital workers means watching their tool calls and revoking access when behavior drifts, not just vetting them at onboarding.

None of this is new security work. Inventory, provenance, least privilege, change control, and runtime monitoring have existed for decades. What changed is the speed and the scale. MCP infrastructure is being assembled at vibe-coding velocity, often from unchecked open-source tools and components.

Regulation will make this harder to ignore. EU AI Act obligations around logging, transparency, human oversight, and cybersecurity increasingly reach the layers where agents invoke tools and act on enterprise data. An auditor will not be impressed by “we trusted the registry.”

Organizations that keep treating every MCP vulnerability as a one-off patch will keep patching. Those that build provenance, review, and runtime control into MCP adoption will know what they are running. One group handles incidents. The other manages risk.

Many vendors (both established players and AI-native startups) claim to provide “AI security” or “AI governance”. Most of these vendors are directionally right, but the problem space is too broad and dynamic for any one control category or solution provider to address comprehensively.

Securing AI will thus not become one giant market category. It requires a fabric that combines multiple control categories. Much like the need for holistic identity and access management implementations that combine multiple controls led KuppingerCole Analysts to define the identity fabric. Existing security and governance categories must extend and provide coverage for generative AI and AI agents. At the same time, new AI-native controls will emerge for risks that traditional controls are not designed to handle. Enterprises should plan to use both types as part of the emerging AI security fabric.

This matters because AI is moving faster than current controls, both identity and broader cybersecurity can support. AI is being embedded into productivity suites, business applications, development platforms, analytics tools, security systems, and many other types of SaaS applications. Organizations are also building internal copilots and are rolling out specialized AI agents in support of their businesses. Security teams are being asked to secure systems they are currently not even able to comprehensively discover.

Why AI Is Not Just Another Application

Treating AI as just another application is wrong. Traditional controls still apply, but AI dramatically changes what needs to be protected. With conventional applications security teams can focus on users, access control, the code, data, and logs. AI systems behave differently: they combine foundational model behavior with prompts, enterprise context, data retrieval, tools, and delegated action, and their non-deterministic results may change with each run.

This changes the attack surface. Beyond exploiting vulnerabilities or stealing credentials, attackers can now manipulate prompts, poison retrieval, exploit context, induce unsafe output, or trick an agent into taking malicious actions. The resulting risks span application security, identity, data security, and business process control. This shift is why traditional cybersecurity frameworks struggle to fully model AI systems, especially in agentic and generative AI environments.

Existing Security Controls Will Evolve, Not Disappear

Some AI risks can (or will) be handled by current security and governance controls. IAM systems can understand AI users, services, and agents. IGA and PAM systems can govern delegated authority and privileged actions. Data security controls can know which AI systems can access sensitive information and how that information can appear in outputs.

GRC systems can manage AI assets, ownership, policy, risk decisions, and the associated evidence. SOC tools can detect misuse involving AI systems. SaaS security tools can discover AI services, risky grants, and shadow AI adoption inside enterprises.

Existing security categories will not disappear, but vendors must evolve their control models to treat AI systems and AI agents as first-class actors. 

AI-native Controls are Required for Security Architectures

Extending existing security categories for AI will not be enough.

Some AI risks need controls built close to the AI interaction layer. Prompt injection is not SQL injection, jailbreaking is not access abuse, and agent runtime control is not service-account monitoring.

Enterprises also need controls that inspect prompts, evaluate outputs, detect manipulation, protect data retrieval, and enforce policy during AI interactions. They need runtime monitoring for agents that can use tools, act across systems, and with and through other agents. They will need evidence that shows what the AI system was asked to do and what happened.

AI introduces failure modes that traditional security controls were not originally designed to manage.

AI Governance and AI Security Are Related, Not Identical

AI governance and AI security are often discussed together, but they are not the same.

AI governance refers to defining policies, ownership, accountability, and evidence requirements for AI systems. AI security refers to enforcing and monitoring those policies across runtime systems, data access, and AI agents.

AI GRC should answer questions such as:

• What AI systems exist?
• Who owns them?
• What are they used for?
• What policies apply?
• What evidence is required?

AI security answers a different set of questions:

• Can this AI system access that data?
• Can it call that API?
• Is a prompt attempting to override policy?
• Did the system expose sensitive information?
• Did an AI action cause an incident?

The two domains must work together, but governance systems and enforcement controls should remain operationally distinct.

Agentic AI Changes the Risk Model

The emergence of agentic AI significantly raises the stakes.

A chatbot that drafts text creates some risk. An autonomous agent that can call APIs, modify records, trigger workflows, communicate with other systems, or delegate to other agents creates a fundamentally different risk model.

That puts agentic AI at the intersection of identity, data access, workflow control, and runtime security. Agents may act with delegated authority, using workload or human identities, and they will make decisions faster than human-in-the-loop review processes can keep up.

This is why enterprises need an AI Security Fabric: a need for integrated control architectures that connect identity, policy, runtime protection, telemetry, incident response, and audit evidence across AI systems and agents.

Start with Controls, Not Category Labels 

The best buyer strategy is straightforward: map AI use cases to control requirements before evaluating product categories.

Organizations should begin by identifying:

• Which AI systems are in scope
• What data they can access
• Who or what can act through them
• Which business processes they affect

AI Security requires a Fabric

AI security requires both evolution and invention. Existing security and governance categories will become AI-aware. At the same time, new AI-native controls are also emerging where prompts, models, context, data retrieval, and agents create new risks.

Securing AI will not be one market category. It will be a discipline, an architecture, a fabric, or a mesh, and requires a multi-year shift in how enterprises govern and protect this new class of IT system. The challenge is no longer whether AI introduces new risk. It is whether organizations can design controls fast enough to match adoption.

Organizations should begin now by:

1. Mapping AI systems and agents
2. Identifying control coverage gaps
3. Separating governance from enforcement
4. Evaluating where existing controls apply
5. Identifying where AI-native protections are required

Organizations evaluating AI security and governance strategies will increasingly need cross-domain expertise spanning these domains.

To dive deeper into this topic, check out this analyst chat on the AI Security Fabric.

Key Topics:

✅ What Attack Surface Management is and its four subcategories (CAASM, EASM, TPRM, DRP)
✅ How Digital Risk Protection monitors dark web, social media, and hacker forums
✅ What Brand Protection adds on top of DRP — from takedown services to counterfeit detection
✅ DRP vs. Brand Protection: lightweight vs. full-spectrum — and when you need which
✅ Why brand reach matters more than company size when assessing risk
✅ What KuppingerCole research is available now — and what's coming in August

Someone may be selling counterfeit versions of your product right now — or impersonating your brand online. DRP and Brand Protection tools exist to catch exactly that.

Check out KuppingerCole's Brand Protection Buyer's Compass here.

This webinar examines what is driving the surge of investment, which solution patterns are emerging across the market, and how security leaders should evaluate AI-assisted operations. The session will focus on measurable outcomes, analyst augmentation, governance, explainability, and the tradeoffs between traditional workflow automation and newer agentic approaches so attendees can separate real value from market noise and make more confident strategic security investment decisions.

FIVE KEY TAKEAWAYS

• Understand what is driving the surge of investment in AI-assisted security operations
• Explore why both traditional rule-based automation, along with AI-driven approaches are needed in modern SOCs 
• Examine how AI is influencing the decision between building an internal SOC and leveraging MDR services
• Learn the current state of AI agents within security operations and where they deliver practical value 
• Understand why the future SOC remains AI-assisted rather than fully autonomous

300 episodes already? Time flies when you're having fun! In this 300th Episode of the KuppingerCole Analyst Chat, Matthias sits down with Distinguished Analyst Martin Kuppinger to unpack one of the most urgent, and underestimated, security challenges facing organizations right now: employees building and deploying their own AI agents, with no governance, no oversight, and no accountability.

Key topics:

✅ What "shadow agents" are and why they're fundamentally different from shadow IT or shadow AI
✅ Why vibe coding means anyone, not just developers, can now deploy autonomous agents inside your systems
✅ How AI agents massively expand the attack surface through prompt injection, data exfiltration, and uncontrolled access
✅ Why discovery and resource-side controls must happen in parallel and why neither alone is enough
✅ What organizations can actually do to gain control without just shutting everything down

The bottom line: there's a thin line between agents that help your business and agents that harm it. Right now, most organizations can't tell the difference.