Frank walks through the analogy in detail: shadow AI as the ignition source, legacy IT as the buried ammunition that fuels a blaze once exposed, and uncontained agentic activity as the fire that spreads invisibly before it blows up. He explains how DHL approaches precaution and detection. Transparency into where AI is used, risk-based access for agentic identities, security built into the AI development lifecycle, and real-time situational awareness, and how these principles translate into practical AI governance at scale.

Frank also makes the case for why AI governance should be a business enabler rather than a blocker, describing how reusable, pre-approved “Lego principle” building blocks fast-track safe adoption, and why he insisted on having and using the authority to pull the plug on an AI system that crosses the organization’s risk tolerance. He draws out the fire protection analogy further: compartmentalization as a model for network and system segmentation, and why traditional BCM planning cycles, often reworked only annually, are too slow to match the speed of AI-driven change.

Topics covered: AI governance, shadow AI, agentic identity and access, AI development lifecycle security, business enablement, incident authority, network segmentation, business continuity management.

Anyone who has spent enough time around standards has seen this happen. Two vendors support the same protocol. Both implementations pass their own tests. Both can point to the same specification. Then someone tries to connect them and discovers that they made different choices about optional features, profiles, metadata, trust, discovery, identifiers, or the exact point where one specification hands work off to another.

The standard may be doing exactly what it was designed to do. The gap is often somewhere around it. We need to keep that in mind as identity architecture becomes more distributed and more dependent on combinations of standards.

A Specification Only Solves the Problem It Was Written to Solve

Standards documents are deliberately scoped. For example, the World Wide Web Consortium’s (W3C) Verifiable Credentials Data Model 2.0 describes a data model for credentials and presentations and the roles of issuers, holders, and verifiers. OpenID for Verifiable Presentations 1.0 describes a protocol for requesting and presenting credentials. It can carry several credential formats and can be used with the web's Digital Credentials Application Programming Interface (API). The W3C Digital Credentials API gives websites a browser-mediated way to request issuance or presentation of digital credentials while trying to protect the holder from unnecessary disclosure. It explicitly leaves a great deal of functionality outside the API itself.

Each specification can be useful and well-designed while still leaving significant decisions to implementers and ecosystem profiles. Standards bodies scope their work this way by design. A specification that attempted to settle every deployment decision would probably become unusable.

Trouble often starts when organizations mistake the existence of the specification for the resolution of the entire interoperability problem.

Optionality Adds Up

Standards need extensibility and optional features because different environments have different requirements. A specification that is rigid enough to cover only one deployment model will not travel very far. The downside to that flexibility, however, is the cost: Every optional feature becomes another potential point of disagreement.

Format neutrality is a deliberate strength of the OpenID specifications for verifiable credentials. It allows issuers and verifiers to support the different formats in use in Europe and the US. Each ecosystem must still agree on the formats its participants accept.

One implementation supports one credential format; another supports three. One requires a particular client authentication mechanism; another treats it as optional. One ecosystem defines issuer trust through a curated list; another expects trust to be established through federation metadata or bilateral configuration.

None of these implementations necessarily violates the relevant specification. They may still fail to work together.

OAuth provides plenty of examples. Over the years, profiles have developed around OAuth precisely because "supports OAuth" does not tell an implementer enough about how a particular deployment behaves. Standards such as OAuth 2.0 Authorization Server Metadata help clients discover server capabilities and endpoint information. More recent work, such as OAuth 2.0 Protected Resource Metadata, continues to make relationships between authorization servers and protected resources more explicit.

Those standards improve interoperability because they reduce the amount of information that has to be configured or guessed. They do not eliminate the need for deployment agreements.

Profiles Do a Lot of the Real Work

A profile takes a general-purpose standard and narrows it for a particular environment. Some security profiles, such as the Financial-grade API (FAPI) profile, also make mechanisms from other specifications mandatory. A profile might say which algorithms are allowed, which options must be supported, which metadata is required, how identifiers are constructed, which credential formats may be used, or how trust is established. That narrowing can sound unglamorous, but this is where a large amount of practical interoperability comes from.

The European Digital Identity (EUDI) Wallet Architecture and Reference Framework is a useful example. It describes an ecosystem with wallet providers, relying parties, credential providers, trust anchors, trusted lists, certification requirements, and operational rules.

Supporting one of the underlying technical standards does not automatically make a product interoperable with the EUDI Wallet ecosystem. The surrounding profile and trust framework determine what "support" means in practice.

The same pattern appears elsewhere in identity.

Enterprises regularly discover that a standard protocol gets them to the point where systems can exchange messages. That still leaves questions about whether they agree on the meaning of those messages and whether each side is willing to trust the other.

Trust Is Often Outside the Protocol

This is probably the part that receives the least attention when organizations evaluate interoperability claims.

A verifier may be technically capable of validating a credential. That does not tell the verifier whether it should accept the issuer. An OAuth resource server may be capable of validating a token. It still needs to know whether that authorization server is trusted to issue tokens for that resource. A browser may mediate a federated identity interaction, but the organizations involved still have relationships, policies, and expectations that exist beyond the browser API. Many standards are intentionally neutral about these decisions because the answers depend on governance.

Verifiable credentials allow a verifier to accept a credential without any direct relationship with the issuer. The verifier still relies on some form of governance to decide which issuers to accept. The EUDI Wallet architecture makes that particularly visible by describing trusted lists and relationships among ecosystem participants. The European Commission’s own interoperability testing in December 2025 found that onboarding to the EUDI trust framework remained a weak point. Use of the available trusted lists was also limited. Other ecosystems may use contracts, federation metadata, certificate hierarchies, regulatory status, preconfigured trust anchors, or some combination of these. Organizations evaluating a "standards-based" solution should therefore ask a second question: What establishes trust between participants?

If the answer is "manual configuration," that may be perfectly acceptable. It is simply a different interoperability story from one based on dynamic federation or an ecosystem-wide trust framework.

Discovery Deserves More Attention

Before two systems can interoperate, they have to find each other and determine what the other side supports. We call that the discovery problem, and while discovery is sometimes treated as straightforward, it is a critical part of interoperability.

OAuth authorization server metadata lets clients discover endpoints and supported capabilities. OpenID Connect has similar mechanisms. Digital credential ecosystems are developing their own approaches for communicating verifier, issuer, and wallet capabilities.

Without good discovery, implementers fall back to configuration. Configuration works, particularly in smaller environments, but it scales poorly and creates another source of drift.

Discovery also creates its own security questions. Who publishes the metadata? How does the relying party know it is authentic? What happens when capabilities change? Can a client safely follow information obtained from a newly discovered service?

Interoperability depends on more than agreeing on the syntax of the messages exchanged after two systems have connected.

Conformance Testing Helps, But It Cannot Test Everything

Good conformance testing is one activity that is often offered as a way to solve the interoperability problem, and yet it is really more in the “necessary but not sufficient” category.

OpenID four Verifiable Presentations (OpenID4VP), for example, has conformance testing for wallets and verifiers. That gives implementers a common baseline and catches many of the kinds of subtle interpretation differences that otherwise appear only during integration.

Conformance testing, however, is still testing against a defined target. If an ecosystem profile has not defined a behavior, conformance testing cannot magically create agreement about it. If two implementations choose different optional features that are both allowed, both may pass.

Interoperability testing goes a step further by asking whether independently developed implementations actually work together. Mature ecosystems usually need both.

The Seams Between Standards Are Where Things Get Interesting

Modern identity systems increasingly depend on stacks rather than individual protocols. This is a feature, not a bug, despite the challenges it introduces with practical interoperability. Layering keeps each specification focused on a single job, but it also creates practical interoperability challenges.

A deployment might use one specification for credential format, another for presentation, another for transport through the browser, another for cryptographic proof, and yet another mechanism for establishing trust. The difficult engineering decisions often appear at the intersection between different specifications.

Who generates and checks the nonce that binds a presentation to a specific request? Which layer is responsible for replay protection? Where does wallet selection happen? Which component decides that an issuer is trusted? How is a verifier identified to the holder? Which metadata is authoritative when two layers expose similar information?

Standards groups spend a surprising amount of time on such questions because interoperability failures frequently happen at boundaries rather than inside individual specifications. The growing overlap between digital credentials, wallets, APIs, and agentic systems adds more of these boundaries. A single transaction may involve technology standardized by W3C, Internet Engineering Task Force (IETF), OpenID Foundation, International Organization for Standardization (ISO), or other organizations.

The resulting architecture can be completely standards based and still require substantial integration work.

What Enterprises Should Ask

"Does this support the standard?" remains a useful procurement question, but it cannot be the last one. A more useful evaluation looks at the entire interoperability model.

Which version of the specification is supported? Which optional features are implemented? Is there a profile? Are there conformance tests? Has the product been tested against independent implementations? How are capabilities discovered? How is trust established? Who governs the ecosystem? What happens when implementations disagree? Perhaps most importantly: Where does the standard stop? A good vendor should be able to answer that.

Standards are enormously valuable. Much of today's internet works because independently developed systems implement shared specifications. Their value does not come from eliminating every decision that has to be made. Standards create the common ground on which those decisions can be made.

For organizations building identity infrastructure, understanding what remains outside the specification is therefore just as important as knowing which standards appear on the architecture diagram.

What the Fourth Party Changes

The question is no longer only whether the customer is who they claim to be and what they are authorized to do. Merchants must now also answer what the customer delegated to the agent, who can prove it, and how. Customer identity and access management (CIAM) systems, fraud reduction intelligence platforms (FRIP), and the other systems around them were built to authenticate people, manage their consent and entitlements, and block fraud. Most do not yet model delegations that run through agent software acting on someone's behalf.

One Customer, Two Hats

The difficulty is that a single personal agent can act for the same person in two very different capacities: as an end consumer and as an employee. The merchant often cannot tell from the request which scenario is in play, who is paying, what rules apply, or who is ultimately accountable. A travel booking could be a family holiday or a client visit governed by a corporate travel policy. A software subscription could be for personal use or for company business. A restaurant reservation could be for a birthday or a client dinner. A ride to the airport could be the start of a vacation or of a client trip. The list goes on.

When the merchant or the agent guesses wrong, disputes over reimbursements, refunds, and policy violations will tend to surface long after the transaction, when the context that would have resolved them is gone.

Why the Merchant Cannot Sort It Out Alone

Merchants differ in what they can see. Some have direct contractual relationships with employers and can evaluate a transaction against the scope of that contract. Many others see only the individual and have no view of which business, if any, stands behind the purchase.

Either way, the merchant cannot depend on direct access to the agent platform. What it does have, by definition, is direct interaction with the personal agent. That makes the agent the primary channel for the signals the merchant needs. The merchant therefore needs reliable ways to authenticate the agent and verify what it is authorized to do, including the role in which the person is acting.

Emerging initiatives such as the IETF's Web Bot Auth draft and the Personal Agent Protocol (PAP), in development by Meta and Sierra, are an important start. Web Bot Auth verifies which agent is sending a request, though not what it may do, and neither initiative yet conveys that role. Visa's Trusted Agent Protocol (TAP), Mastercard Agent Pay, and American Express's Agentic Commerce Experiences (ACE) kit add payment-network signals about the agent and the purchase it intends to make, but they too stop short of the person's role.

Data Moves in Both Directions

The risk is not confined to financial transactions. Corporate purchasing data and policies can flow into consumer agent platforms through personal agents the business never approved, a form of shadow AI. This can be as simple as a user uploading a travel policy or supplier list to make their personal agent follow company rules. In the other direction, personal data can leak into corporate expense and procurement records.

What Merchants and Employers Should Decide Now

Merchants and e-commerce sites first need to decide whether they will do business with personal agents at all. Either choice carries business risk. Those that do should require agents to declare the role in which they are acting, for now by asking for it during checkout. They should also confirm costly or risky transactions directly with the person rather than relying on the agent's assertion alone. Standards groups and payment networks should add a role field to their agent protocols so this declaration can move out of the checkout page and into the request itself. Employers, for their part, should decide whether personal agents may carry out transactions that affect the business, and if so, under what policy and with what evidence.

Closing Thoughts

Agentic commerce turns a customer login into a four-party question of delegation and role. Identity teams that treat the agent as just another session will be left reconstructing intent after the fact, usually in the middle of a dispute. The CIAM Impact Day in Frankfurt on 18 November will explore these questions in depth.

Key Topics:

🗄️ “Do not ask whether agents can reach your data. Think whether your data can say no.” Alexei Balaganski on why the perimeter is gone and why enforcement has to live as close to the data source as possible.

📊 The KuppingerCole Analysts Data Security Platforms Leadership Compass is out now and a webinar with Alexei is coming soon. Watch this episode first, then read the report at kuppingercole.com.

Jason Gzym, VP of Solutions Engineering & Advisory at Pathlock, follows with how enterprises are putting the See–Assess–Enforce framework into practice: building a complete NHI and agent inventory with named ownership, scoring risk by privilege and activity, and enforcing policy at the moment of action with continuous, audit-ready evidence.

That gap is why we are introducing the AI Security Fabric. The question I hear most is not which tool secures AI agents. It is why we cannot simply extend the Identity Fabric and treat agents as first-class identities. My short answer: identity is necessary, but it is not sufficient. In the latest Analyst Chat, along with Matthias Reinwarth and Phillip Messerschmidt, we explain the reasoning.

Same method, different angle

The Identity Fabric works because it starts from requirements, not products. You define what you need, map it to capabilities, group capabilities into services, and only then choose tools. The AI Security Fabric keeps this logic. Business requirements come first, security requirements are derived from them, and tools come last. The aim is to assemble solutions like Lego bricks from what you actually need, not to buy one product and hope it solves everything.

What changes is the perspective. As Phillip put it, this is closer to an extension than a second version of the same fabric: the same concept viewed from the angle of AI security. The overlap with identity is real, but the AI Security Fabric covers much more, including AI safety and protection.

Why the Identity Fabric alone is not enough

Three differences explain why AI security needs its own fabric.

1. The scope is broader than identity. AIdentity is one of five functional groups, with 14 of the 68 capabilities. The others are AI Governance (14), AI Safety (13), AI Protection (14) and AI Transparency (13). The classic controls built for humans do not fully secure agent actions. That is why the architecture is organized around the pillars that secure what an agent does, not only who it is.

2. The stakeholders are different. AI security, cybersecurity, IAM and development teams each hold different accountabilities and see different parts of the problem. A single identity-centric view does not give them a shared model.

3. The ambition is deliberately wider than the market. Vendor blueprints tend to cover what the vendor sells. Our ambition is to go broad. That includes capabilities organizations will need but for which there is hardly a good solution on the market yet. A capability-first model makes those blind spots visible.

The Advisory Note AI Security Fabric: Introduction and Overview makes the same point: AI security is an architecture and ownership problem before it is a procurement problem. No single product category covers identity, governance, runtime control, security and accountability for agents at once.

“One home per capability” keeps fabrics from colliding

Once you run more than one fabric, such as identity, AI security and the Cybersecurity Fabric to come, you risk duplicated capabilities and conflicting ownership. The new principle we introduce is “one home per capability.” A capability can appear in several fabric perspectives, but exactly one fabric is its primary home. It is borrowed and specialized elsewhere, not copied.

Authentication is the clearest example. If you already operate an identity provider and authentication methods for employees, consumers and service accounts, agents should build on them. That capability belongs to the Identity Fabric. The AI Security Fabric borrows it and specifies how it must work for agents.

There is a catch, and we should not underestimate it. Agents authenticate far more often and at far greater scale than a human who logs in once or twice a day. The consuming side changes the requirements on the service providers. This is why the principle pairs with another: services follow the organization. Each service needs an organizational anchor. That pushes organizations toward real service-delivery thinking, identity and security as a service, at the speed the business now expects.

From concept to a usable architecture

The fabric is the high-level blueprint. The reference architecture, which Phillip just released, makes it actionable. The Advisory Note AI Security Fabric and Reference Architecture sets out the 68 capabilities in a tool-neutral model:

• Layers: 28 core, 25 extended, 8 integration and 7 privileged capabilities.
• Supporting structure: an API layer and a shared foundation, including a registry data model and policy-as-code.
• Intended use: to design, assess and evolve AI security architecture, and to select tools last.

One piece of community feedback stood out. People were surprised by the number of pillars, and some pillars are rarely considered when organizations implement agent capabilities.

What to do with it

The recommendations from the episode and the Advisory Notes translate into concrete steps:

• Start from business requirements. Derive the security requirements from them and keep tools out of the conversation until capabilities are defined.
• Use the reference architecture as a checklist. Walk through the capabilities to find the areas you have not considered, especially the pillars beyond identity.
• Decompose vendor offerings into capabilities. Map what each product delivers, where it fits, and where it leaves blind spots.
• Reuse what you already have. Build agent authentication on your existing identity provider, and specify explicitly what changes for agents, such as frequency and scale.
• Name a home and an owner for each capability. Align AI security, cybersecurity, IAM and development around services, not around tools.
• Prioritize over time. Build a roadmap and set investment priorities by capability. A single “solve everything” purchase will not work, and the capability set will keep evolving with the speed of AI.

This is not the last fabric

The fabric approach started with identity and now extends to AI security. The Cybersecurity Fabric is next, and the one-home principle is designed to scale beyond that. A business application fabric, for example, could draw SAP security from the cybersecurity fabric and AI-specific controls from the AI Security Fabric. The result is a service model that spans the whole IT organization, not just a better way to secure agents.

Not managing it is not an option

AI agents are already in use. Governance and security have to keep pace. If you cannot say today which capabilities protect the actions your agents take, and who owns each one, that is your starting point.

The fabric is a map. Using it on your own agents is the harder part, and that is where we can help.

Become a KuppingerCole member: Most of our research is reserved for members, including both AI Security Fabric Advisory Notes and the analyst inquiries behind them. Explore memberships to read the full reference architecture and get direct access to the analysts who wrote it.

Work with our advisors: If you want to map your agents against the 68 capabilities, find your coverage gaps, and build a roadmap, talk to a KuppingerCole advisor. They help you start with the core, extend by risk, and choose tools last.

Not ready yet? Watch the Analyst Chat first. Then decide which agents to classify this quarter.

Key Topics:

🎭 “A lot of what we do in counter-fraud and verification is a kind of kayfabe security theater. We do these things to tick compliance boxes. Everyone knows it deep down.” Jaye Hackett on why the industry’s verification paradigm is running out of road.

📅 Catch Jaye Hackett’s full session at the KuppingerCole Analysts CIAM Impact Day

This webinar introduces Lean IGA, a distinct market segment built for organizations that need core lifecycle management and access governance, including certifications and compliance reporting, delivered through rapid deployment, low-code configuration, and strong connectivity to Microsoft AD, Entra ID, and everyday business systems, without the overhead of a traditional enterprise IGA program.

Nitish Deshpande, Senior Analyst at KuppingerCole Analysts, examines how Lean IGA differs from traditional enterprise IGA. He will present the core capabilities organizations should expect from Lean IGA solutions, including identity lifecycle management, access certifications, and compliance reporting, alongside preferred delivery models. He will also share the findings and results from the latest Lean IGA Leadership Compass.

Three weeks later, overnight into Monday, November 2, it happened again. More than 50 stores in Belgium, a limited number of smaller stores in Sweden, and over a dozen more across Ireland, Estonia, the Netherlands and Luxembourg. Carrefour said 15 of its roughly 700 Belgian stores were affected. Retailers described the same method and the same result.

The second wave carries a warning for every chief information security officer (CISO) responsible for physical systems, whether or not they work in retail. The weeks after a public attack are when a target is most exposed: like a second strike to a nerve that is already sensitized, the same technique hits hardest wherever the damage from the first has not yet been dealt with. Figures from one Belgian installer suggest that operators who secured their controllers between the two waves largely avoided the second one. The rest of this post covers what to do now, what is known so far, and why I have seen this pattern before.

Five Things to Do Before the Third Attack

1.     Find them. Inventory internet-reachable building and operational controllers. Use external attack surface data and ask facilities and every maintenance contractor directly. Expect the second list to be longer than the first.

2.     Check support status. For each controller, record the vendor's end-of-service date. Anything past it is an accepted risk that a named executive should sign, not a default.

3.     Remove remote write by default. Let telemetry and alarms flow out. Make setpoint and mode changes require on-site action or brokered, time-limited access protected by multi-factor authentication.

4.     Govern contractor access as identity. Named accounts, an owner for each, expiry dates, session logging. Treat installer credentials as privileged non-human access and manage them with the same controls you apply to service accounts.

5.     Plan for the physical consequence. Independent high-temperature alarms that do not depend on the controller being trustworthy, a manual fallback, and a clear answer to who gets called at 2 a.m.

Beyond these five steps, treat the weeks after any public campaign against equipment you run as a period of heightened threat, when attackers and copycats know what to look for, and your teams are still focused on recovery.

Why This Is Your Problem, Not Only Retail's

If you run security for a bank, an insurer, a manufacturer or a hospital, it is tempting to file this under someone else's sector, but the same class of equipment is almost certainly running in your own buildings.

Most enterprises run equipment with the same profile: heating, ventilation and air conditioning (HVAC) and cooling for server rooms, cold storage in labs and pharmacy, building management systems, physical access control. These systems are commonly bought by facilities, installed and maintained remotely by a contractor, missing from the asset inventory, and outside vulnerability scanning. The supermarket incidents show what a compromised controller costs when the consequence is physical: the loss is measured in spoiled stock, closed stores and fire risk rather than in leaked records.

Regulation offers little cover for the equipment already in service. The EU Cyber Resilience Act will require manufacturers to provide a support period reflecting a product's expected lifetime from December 2027. Until then, as The Record notes, there is no legal obligation on manufacturers to fix the products targeted in these attacks, and even after that date the requirements will apply only to devices placed on the market from then on, not to discontinued controllers already installed in stores. And as the Danfoss example below shows, the approach of that regulation can shorten vendor support for legacy equipment rather than extend it.

What Is Known, and What Is Not

Method. In both waves, attackers triggered the controllers' built-in defrost mode and overrode the temperature and duration settings, according to retailer and installer accounts reported by Tom's Hardware and Belga.

Equipment. A French official update relayed by INCIBE-CERT, the incident response team of Spain's National Cybersecurity Institute, named Danfoss, Copeland and Dixell controllers among those compromised in October. In the November wave, an Estonian contractor said an older Danfoss system was accessed, and Dutch broadcaster NOS reported that Copeland equipment was targeted in Belgium.

Support status. After the French attack, both Danfoss and Copeland said the affected devices were mainly discontinued products that no longer received security updates. Danfoss had announced a hard end-of-service policy for legacy products in an October 2025 newsletter, citing recent European cybersecurity legislation and saying that continued support would bring new legal obligations to maintain security updates.

Warning time. Claroty's Team82 published research in August 2026 warning that these units were at risk of remote compromise.

Precedent. The same Danfoss newsletter referenced earlier campaigns against its controllers, including attacks on Russian supermarkets at the start of the invasion of Ukraine and around 40 stores in Israel that Danfoss said lacked adequate firewall or virtual private network (VPN) protection.

Remediation gap. Belgian installer Sabcobel said it knew of around 20 affected units out of the hundreds it manages, that the affected units needed physical modifications rather than a software update alone, and that most of its customers had moved units onto a secure connection after the French attack. Most, however, is not all, and the units that had not been moved are the likeliest explanation for the second wave's Belgian victims.

Unknown. Who is responsible, whether the two waves are linked, and the initial access route in each case.

The Identity Question Underneath

Every controller that can be changed remotely is an access path with an identity behind it: an installer account, a vendor portal login, a shared service credential, an always-on VPN tunnel. These usually sit outside identity and access management (IAM) and privileged access management (PAM) programs, and they rarely appear in quarterly access certifications.

The public reporting so far points toward internet-exposed, unsupported devices rather than stolen credentials, although the initial access route in each wave remains unconfirmed. Whichever it turns out to be, the question every CISO should be able to answer is the same: who and what can change a setpoint on our physical systems from outside the building, and how would we know if they did?

Why the Second Strike Does More Damage

Anyone who has trained in kickboxing knows the low kick to the outside of the thigh. The first one hurts. The second, landing on tissue that is already inflamed and on a nerve that is already sensitized, can take the leg away. The attacker needs no extra power the second time, only the same strike in the same place before the target has recovered.

October was the first kick. It showed which controllers were exposed, which operators and installers were slow to move, and how the sector and its suppliers would respond in public. No group has claimed either wave, and it is not known whether the same people carried out both. For defenders, that distinction matters less than it might seem, because the method was public, the device types were named in the press, and the remaining exposed targets were findable.

Twice in One Weekend

Earlier in my career I was part of the incident response team (not because I was special, but because I was local) when Sun Microsystems' European data center at Bagshot Manor was raided, and then raided again, in the same weekend. In the 1990s, gangs were stealing high-end computing gear, so Sun was a juicy target. The first raid on a Friday evening cleaned out the server farm, resulting in heroic activities by my colleagues in finding machines that could be redeployed, recovering from (offsite!) backups, and bringing core services back online.

The second raid on a Sunday evening was worse, and as one colleague said, "This one was personal." The same gang came back, rammed a vehicle through the damaged wall again, and took the backups that we had painstakingly brought back from offsite storage for the recovery. (And for those of you wondering what happened next, we took a lot of desktop machines and used those until emergency replacements were flown in.)

What stays with me is the second break-in rather than the first: first incidents are expected, and response plans are written for them, but the second landed while we were still in response mode. Whoever came back already knew the layout, knew what was worth taking, and knew our attention was on recovery and reporting rather than on the attack.

Europe's grocers have just lived through the same pattern, and the responsibility now sits with you: find the controllers you own, close the remote paths into them, and assume that anyone who studied the first two waves already knows where to look.

Key Topics:

🧵 “Not managing it is not an option” the AI Security Fabric is KuppingerCole Analysts’ architectural answer to securing AI agents across their full scope of action. This is where the journey starts.

📄 Martin’s foundational document on the AI Security Fabric and Phillip’s reference architecture are both published on our website - watch this episode first, then dive in.

A working tool is not yet a strategy

Most IAM setups grew step by step: one tool for accounts, another for login, others for privileged access. Each may work well, but together they often sit side by side rather than work together, while the list of identities grows to include partners, devices and AI agents. The better question is not which product to buy, but what does our organization actually need from IAM, and how do we deliver it reliably?

From a pile of tools to a set of services

Our lead advisor, Patrick Teichmann presented the Identity Fabric: not a product you buy, but a framework with three levels.

This keeps the business need independent of any single product. The Identity Service Factory turns the idea into daily practice: IAM offers standard, repeatable services with clear owners and measurable quality, such as a defined way to connect a new application. Existing systems stay in the picture, and improvement happens in small steps, not a multi-year big bang. 

Why the business now sets the bar

An observation from the audience added an important twist. IAM used to tell the business what it needed to do. Today, the business is outgrowing that model: many teams embed their own authentication and authorization services directly in their solutions.

For Patrick Teichmann, this strengthens the case for the service view: the central IAM solution needs to address the needs of the different parts of the organization while serving the interests of a central unit in terms of e.g. central governance or similar.

Roles are useful, but a role does not know the situation

Most companies grant access through roles: someone in finance gets the access that comes with that job. Dr. Schläpfer’s point was that a role knows a function, not a situation. It cannot tell whether an employee approving a payment is on a managed device, within her limit or behaving unusually. Covering every case with more roles leads to “role explosion”.

His provocative summary: “Roles will be dead in future, because agents don’t have jobs.” Roles can stay for structure and compliance, but the role should describe the general permission, while the context is checked at the moment of action.

AI agents change the question: who acts on whose behalf?

What changes with AI agents is how they work. An agent can take on a task, bring in other agents and finish in several steps, perhaps existing only for one job and only for seconds. The key idea is delegation. If an assistant organizes a business trip within a budget and hands part of it to a booking agent, each handover should carry narrower limits, and the target system must be able to tell whether a request is still inside the assignment. The principle: delegate a limited assignment with traceable authority, not open-ended access, and make sure that revoking it stops everything handed down from it. The speakers were clear that these are requirements, not a proven solution for any chain of agents.

The hurdles are as much about people as technology

The discussion added a reality check. Rules need owners, applications without suitable interfaces call for IAM to be involved early in procurement, and teams already busy running today’s landscape need capacity to change. The suggestion: start small, in a clearly defined area, and carry the lessons over step by step.

Five practical starting points

No big-bang project is needed. A sensible way in:

1. Map your IAM by capability, not by product.
2. Define three core services with owners and measurable goals.
3. Include AI agents and other non-human identities deliberately.
4. Pilot policies and delegation in one small area, including revocation.
5. Follow business value and risk, not buzzwords.

The takeaway

The two talks point to the same conclusion: IAM must do more than run tools. The Identity Fabric helps organize what is needed and deliver it as dependable services, and AI agents show why it must stay flexible. Existing roles and systems stay valuable, within a picture that also includes context and controlled delegation.

Future-ready IAM does not just recognize who is acting. It makes clear on whose behalf, within which limits and under whose responsibility.

To explore the framework behind the discussion, take a look at KuppingerCole’s public Identity Fabric reference architecture.
Watch Patrick's full session at IAM Circle #18  here.

For identity teams, this raises a question that is easy to defer and expensive to ignore: how much sovereignty risk is already built into your IAM, CIAM, or PAM stack, and what would it cost you if that provider went dark tomorrow?

As Deputy CISO at KuppingerCole Analysts, I have a supplier questionnaire that I know by heart. Sixty questions in seven blocks: physical access, logical access, authorization, data segregation, transfer control, availability, compliance. Every new software vendor and every new partner gets it.

Last quarter we assessed a tool from a supplier without any certification. They filled in all sixty questions, after which came the follow-ups, because a “yes” in a spreadsheet tells me very little on its own, and then the maturity rating for each answer. The whole exercise took several days, and when I look back, most of that time went into chasing answers to questions that an audit would already have covered if the supplier had been certified. With a certified supplier, the same assessment usually takes a fraction of that time.

I have seen this pattern often enough now to trust it: a valid ISO/IEC 27001 certificate changes which questions I still need to ask, even though it does not by itself make a vendor secure.

What I No Longer Ask

Before anything else, I check that the certificate is real and current: issued by an accredited certification body (IAF CertSearch or, in Germany, DAkkS will confirm this), still valid, backed by a recent surveillance audit, and issued against ISO/IEC 27001:2022. Certificates against the 2013 version have not been valid since 31 October 2025.

If the certificate holds up, the scope covers the service we are buying and the Statement of Applicability (SoA) is available, I can leave out most of the questionnaire, provided the SoA does not exclude these controls:

• whether access to offices and server rooms is controlled
• whether everyone logs on with their own account, failed attempts are limited, and patches get applied
• whether admin rights are restricted and laptops are encrypted
• whether backups exist and someone has written an emergency plan
• whether employees are trained and bound by confidentiality

An accredited auditor has already examined these areas on a sample basis, with evidence, and in more depth than a “yes” in my spreadsheet ever could.

What I Still Ask

These I ask with or without a certificate:

• Which of our data goes to the supplier, and where exactly does it live?
• Is our data processed separately from other customers’ data?
• Which subcontractors process our data, and where?
• What does the data processing agreement say, and who signs it?
• When something goes wrong, who calls whom, and how fast?

These questions are about us, not about how mature the supplier is in general, so no audit can answer them for me. The certificate takes the generic part off my desk, while the part that only we can judge stays with me. Regulation points the same way: the NIS2 Directive (Art. 21(2)(d)) requires entities to address security in their relationships with each direct supplier, and the Digital Operational Resilience Act (DORA, Art. 28 to 30) expects financial entities to keep a register of their ICT third-party arrangements and to put specific clauses into those contracts. None of that can be ticked off with a supplier’s certificate.

Where the Certificate Stops

A certificate is a series of sampled snapshots. Each audit happens in a particular week, and what matters is how the controls are run in the week after the auditor has left. This is where awareness comes in, because establishing that a control exists is the easy part, and what I want to know is whether the person running it understands why it is there.

And awareness is not only the supplier’s job. On our side, the biggest gap is the company credit card: a team needs a tool, someone pays for it, and nobody in security knows it exists until it is already in use. When the assessment does happen, it often arrives as the last hurdle before go-live: “We have everything in place, could you just quickly sign this off?” On the supplier’s side, I can usually tell within the first few answers whether awareness is real. The partners who worry me are those who never ask and fill in the spreadsheet as fast as they can, whereas those who ask why we need sixty answers usually reassure me, because a good question back tells me more than a quick “yes”.

Not every label works the way ISO/IEC 27001 does. We went through the Trusted Information Security Assessment Exchange (TISAX) ourselves, at Assessment Level 3 with an on-site audit, and in our experience, it answers a different question. A TISAX label is valid for three years without any surveillance audit in between, which makes it a single photograph rather than a series of snapshots. At Level 2, it is a plausibility check of the supplier’s self-assessment, usually done remotely. It was built for the automotive supply chain and is rarely asked for outside it. The results are shared through the ENX portal rather than published, and anyone who already holds ISO/IEC 27001 will find that much of the ground is covered a second time.

My questionnaire also has no section on AI yet. When it gets one, will I ask for ISO/IEC 42001? The standard is young, few suppliers are certified against it, and the scope questions start all over again, which is a question that deserves a post of its own.

What I Take from This

1. If you are the one assessing: look at the scope and the Statement of Applicability first, then put your time into the questions nobody else can answer for you.
2. If you are the one being assessed: your certificate saves your customers days of work. Make it easy to find and make the scope visible.
3. Either way, the real goal on both sides is a reason to trust each other rather than a completed questionnaire, and a certificate is the quickest starting point I know.

If this sounds familiar, write to me or to Christopher Schütze. I would like to hear how you handle it.

Matthew Gardiner, Fellow Analyst at KuppingerCole Analysts, will present the central argument for treating asset intelligence as a prerequisite investment for AI security and governance. He will cover the distinction between aggregating asset data and reconciling it, the scale problem posed by non-human identities, and how KuppingerCole's six category framework for agentic AI security depends on a reconciled asset model underneath it.

Kamden Schewitz will provide the vendor perspective, describing how the Axonius Asset Cloud extends its reconciled asset model to AI specific assets, including agent inventories, AI application usage, and natural language querying through the Axonius MCP Server and AI Agent. He will also speak to how customers are using asset intelligence to close visibility gaps before layering AI specific governance controls on top.

The dutiful agent builds the URL, clicks it, and downloads a remote access trojan (RAT) that gives the attacker control of the laptop and access to everything reachable from it. The human user never clicked anything. Because the message contained no actual URL, the email security system’s link scanning and URL rewriting had nothing to inspect or rewrite. Any organization that lets an AI agent read mail, whether a copilot in the cloud or a local agent on an employee’s endpoint, has unwittingly opened a new path for attackers.

Email Security Systems Were Built to Defend a Human Reader

Secure email gateways (SEGs) and integrated cloud email security (ICES) tools, which connect to the mail platform through application programming interfaces (APIs), inspect links, attachments, sender reputation, and sender authentication using Domain-based Message Authentication, Reporting and Conformance (DMARC). They also look for social engineering cues in message content designed to trick people. A prompt injection payload aimed at an AI reader can avoid all of these signals. It can come from a legitimate, authenticated sender, carry no link or attachment, and be written as plain instructions addressed to the AI agent rather than to the person.

Researchers have already demonstrated this kind of attack against Google’s Gemini for Workspace. In a July 2025 disclosure through 0DIN, Mozilla’s bug bounty program for generative AI, Marco Figueroa hid instructions in an email using HTML and Cascading Style Sheets (CSS) formatting that set the text color to white. The recipient never saw the hidden text, but Gemini read it. When the recipient asked Gemini to summarize the message, the summary included the attacker’s fake warning that the user’s Gmail password had been compromised, plus a phone number to call. Google patched the flaw and reported no known real-world exploitation.

Early Evidence in the Wild

The most significant case to date is EchoLeak. Microsoft tracked it as CVE-2025-32711 and rated it Critical. In the attack a Microsoft 365 Copilot user received an email with hidden instructions. When the user later asked Copilot a routine question, Copilot pulled that email into its context through Microsoft Graph, followed the instructions, and sent internal data to the attacker. Researchers called it the first known zero-click attack on an AI agent.

Broader data shows attackers are already experimenting with the prompt injection technique. In an April 2026 report, Google researchers who scanned archives of the public web found a 32% increase in malicious prompt injections between November 2025 and February 2026. Google rated the attacks as unsophisticated but expected them to grow in scale and sophistication as attackers adopt agentic AI of their own. A 2026 Cloud Security Alliance research note, citing the Open Worldwide Application Security Project (OWASP) GenAI Security Project, concluded that prompt injection has moved into live exploitation.

Published evidence of email-borne prompt injection exploited at scale is still thin. The Google data does not cover email delivery specifically, but attackers have always been opportunistic. As agentic email readers spread, the inbox becomes an obvious target.

From a Reading Problem to an Action Problem

A fooled AI email summarizer can, at worst, produce a misleading summary. An agent that can reply, forward, schedule meetings, update customer relationship management (CRM) records, approve invoices, browse the web, download and open files, and call tools through the Model Context Protocol (MCP) can turn a single poisoned message into real damage, carried out with the user’s authority.

Agents can also make detection and response harder. As I described in my post Why Securing AI Agents Starts with Visibility and Observability, agents often run with delegated authority, inherited credentials, and no accountable owner, which makes it hard to reconstruct what an agent did after reading a poisoned message. Jonathan Care’s recent post, A Peek into AIID2026: AI Agents Are the New Insider Threat, covers prompt injection as one route by which agents become insider threats. Email is one of the most direct ways to deliver a prompt injection.

What Buyers Should Consider for Their Email Security Solution

• Architecture: Attacks on agentic email readers are likely to reopen the debate between SEGs and API-based ICES products. SEGs generally block messages before they reach the inbox, while API-based products generally remove malicious messages after delivery, a time gap that was tolerable when a person was the target. Because an agent can act on a message within milliseconds of arrival, it may act before a post-delivery tool removes the message, which makes that model harder to defend.
• Detection: Does the product treat hidden or instruction-like content, such as zero-size fonts, white-on-white text, and off-screen elements, as a risk signal even when no malicious link is present? Can it flag instructions that spell out a URL or describe an action in words, as in the opening scenario, as possible prompt injections?
• Boundary between mail and AI: Can the solution, or controls downstream of it, stop copilots from processing messages from external senders or messages carrying sensitivity labels and govern what an agent does next, such as resolving a link or running a downloaded file? Microsoft’s guidance after EchoLeak took this approach, recommending data loss prevention (DLP) policies that block agent-based processing of external emails.
• Telemetry correlation: Can email telemetry be correlated with agent activity so a security operations center (SOC) analyst can trace an agent’s action back to the triggering message?

Who or What Is Reading Your Email?

Think back to the employee whose agent downloaded a RAT. The user did nothing wrong, yet the controls designed to protect them never fired. Security leaders should ask whether AI assistants and local agents in their environment read email today, what each can do after reading it, and whether anyone has asked their email security vendor what happens when the email reader is an agent. Agentic email readers deliver real productivity gains, but defenders need to close the new exposures those readers open.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, covering CVE-2026-109618 and CVE-2026-109619. CISA, the NSA and the UK NCSC told organizations that could not patch quickly to consider taking affected systems offline, and several Canadian federal and provincial sites did exactly that.

Patch, Restart, Rotate: What to Do This Week

If you run PHP anywhere, there are three measures you should complete this week, before you turn to the structural weaknesses discussed below.

• Patch and restart. Move to PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a patched vendor build. Restart every PHP service and rebuild images built on PHP bases.
• Inventory runtimes, not apps. Include PHP bundled in appliances, hosting panels and vendor products. Ask critical suppliers directly whether they run PHP, whether they have patched and restarted, and when they will finish.
• Assume secrets have leaked since at least October 17. Amazon recorded an exploitation attempt on that date, so treat secrets held by exposed PHP workloads as potentially disclosed and rotate first those that reach other systems.

One of Your Most Critical Suppliers Has No Contract

The supplier that mattered most on October 21 answers no questionnaires, offers no service-level agreement and appears in few supplier registers. Yet PHP sits beneath government services, retailers and banks, and the project's security work still rests on a small group of Foundation-funded developers plus volunteers.

The PHP Foundation's own account of the incident is candid about its shortcomings. A Foundation-contracted core developer found the first signs of the out-of-memory flaw behind CVE-2026-109618 in 2024, while fixing an issue from an external audit funded by Germany's Sovereign Tech Agency. The security team produced several candidate fixes, each with a cost, and could not reach consensus. The Foundation calls the delay “a structural failure.”

The fix became the top priority only after Calif and OpenAI independently reported a working attack path on August 11, 2026. Since July 1, the team has published 15 CVEs and worked through more than 100 invalid, duplicate or unreproducible reports, a volume the Foundation links to AI-assisted research.

An SBOM can tell you that you depend on PHP, but it cannot tell you that the fix for a known memory-safety issue had stalled since 2024 because a small, stretched security team could not settle on one.

The Embargo Leaked from Every Side

Coordinated disclosure depends on intermediaries. Linux distributions, LTS vendors and hardened-image providers get patches early so their customers can update the moment details go public. PHP2Shell showed how loosely that trust tier is governed.

According to the PHP Foundation's timeline, the CVE identifiers were circulating on forums by around 15:00 UTC on October 20, with the wrong severity score and release time. That evening, Calif mistakenly published a video of its proof of concept; it was deleted, but copies spread, and the Foundation says this accelerated public exploit development. Mitigation advice shared with a few critical infrastructure providers may also have leaked.

Then, at 07:41 UTC on October 21, more than six hours before the coordinated release that the leaks had already forced forward by a day, Chainguard published built images containing the fix. The Foundation says this broke the embargo and let any attacker study the patch in binary form while other users waited. Chainguard's CEO, Dan Lorenc, has said the company shipped early because of reports of exploitation in the wild, which a PHP Foundation board member has disputed, described the volume of such disclosures as “the new normal for the industry,” and apologized to the Foundation for the extra stress.

The trouble may have started earlier still. Amazon reports that its MadPot honeypot network recorded a PHP2Shell exploitation attempt dated October 17, four days before disclosure, and says it is unclear how the actor got the information.

None of this requires bad faith from any single party, because pre-disclosure access runs on trust and convention, and when you choose a distribution or image vendor, you also choose how it behaves under embargo, a question that few procurement processes ask.

Nobody Could Answer, “Where Does PHP Run?”

That was the first question most CISOs faced on October 21. CISA warned that PHP is often a component of other software and that its prevalence may not be directly observable. CERT-EU pointed organizations to a GitHub repository maintained by the Dutch NCSC, which NCSC-NL itself describes as incomplete and still growing.

A crowdsourced list is a sensible emergency measure, but its existence shows that, several years into SBOM mandates, most organizations still cannot answer a runtime inventory question by running a query.

The runtime itself complicates remediation, because updating WordPress or Drupal does not touch the flaw: researchers stress that PHP workers must be restarted after the upgrade, and container images built on a PHP base must be rebuilt and redeployed, not merely rescanned.

End-of-life versions widen the gap further, because they get no official release: PHP 7.4, 8.0 and 8.1 receive only minimal source backports, while researchers report affected releases going back to PHP 5.4. Those runtimes, buried in appliances and control panels, are exactly what SBOM programs tend to miss.

Patching Cannot Recall Leaked Secrets

CVE-2026-109619 can disclose PHP worker memory without code execution. PHP's advisory confirms memory disclosure as an impact, and the researchers say that memory can include passwords, authentication tokens, API keys and certificates belonging to other requests. Patching stops further leakage, but it does nothing about secrets that may already have been exfiltrated.

This turns PHP2Shell into a non-human identity problem as well as a vulnerability problem. The credentials at risk are the ones applications hold to reach databases, payment providers, cloud APIs and partners. If you cannot say which secrets a PHP workload holds, or rotate them quickly, you are stuck choosing between an expensive blanket rotation and an assumption you cannot evidence.

Fix the Chain This Year: Four Measures for Your Roadmap

• Score upstream health. Add maintainer depth, security process and funding to third-party risk. For components as central as PHP, sponsoring the maintainers is a risk control and deserves to be budgeted alongside the other controls you fund.
• Put embargo conduct in contracts. Agree with distribution, LTS and hardened-image vendors what they receive before release, and when they may ship it.
• Test your SBOM against this scenario. Extend SBOM programs to runtime and base-image inventory, then time it: how long does it take to list every system running a given interpreter version?
• Measure rotation time. Track how long it takes to rotate the credentials each workload holds, and report it as a resilience metric alongside patch latency.

Built for May, Tested in October

The PHP ecosystem did see conventional attacks this year. In May, attackers rewrote release tags across four Laravel-Lang Composer packages, producing more than 700 malicious versions, and a separate campaign hit eight Packagist packages, which is exactly the kind of tampering that supply chain security tooling is designed to catch. KuppingerCole's 2026 Leadership Compass on Software Supply Chain Security named attestation as the market's weakest capability, but stronger attestation would not have changed October's outcome.

At the same time, discovery is getting cheaper. AI-assisted research turned a weakness first noticed in 2024 into working attack paths from several directions in quick succession: Calif and OpenAI on the same day in August and Wiz less than two weeks later, and earlier in the year the Foundation had already scanned PHP with Anthropic's Claude Mythos through the Alpha-Omega project. Choosing the right fix for a long-standing design decision, reviewing it and shipping it across every distribution under embargo is not getting cheaper at the same rate.

As discovery gets cheaper, your exposure depends less on the integrity of the artifacts you consume and more on the capacity of upstream maintainers to fix what is found, the discipline of the intermediaries who distribute those fixes, and your own ability to find affected systems and rotate what they hold, so a supply chain program that measures only artifact integrity will keep meeting incidents shaped like this one. Patch, restart and rotate this week; put upstream health, embargo terms, runtime inventory and rotation speed on your 2027 roadmap. To see how vendors compare on the capabilities this market does address, read KuppingerCole's Leadership Compass on Software Supply Chain Security.

The headlines called it a Skynet moment. On our Analyst Chat at the time, I put it differently: OpenAI had a pet tiger, the tiger escaped, and Hugging Face was just walking down the street.

Lost in the excitement was the boring part: what the victims had in common. Hugging Face had credentials exposed online, the Australian portal had an endpoint that required no authentication, and the organizations Anthropic's models breached never noticed anything at all. Most of these hacks required far less sophistication than the headlines suggested, and far more persistence, of exactly the kind we expect from agentic AI.

Knowingly or not, all these organizations relied on security by obscurity. Unfortunately, obscurity only protects you for as long as nobody bothers to look, and an AI agent working through its task list will look everywhere it can reach, whether anyone asked it to.

Obscurity Was a Bet on Attention

Nobody defends obscurity in theory. Auguste Kerckhoffs settled that back in 1883 with his principle: a system must stay secure even if everything about it except the key becomes public. In practice, plenty of infrastructure still depends on it: undocumented endpoints, forgotten staging hosts, admin panels on unusual ports, guest access paths added for testing and never removed.

This worked because attacker attention was limited. A human attacker has only so many hours, and most targets are not worth them. For decades, a lot of exposure went unnoticed for that reason alone, and AI agents, which never sleep or get bored, have changed that almost overnight.

The Australian case shows how little it takes. An OpenAI agent researching government spending on medicines for skin conditions in Victoria reached internal files on the Medicare Statistics Reporting Service. Security researchers later found that the portal's own code directed visitors to an unauthenticated guest endpoint. The agent needed no exploit; it followed the instructions the site itself provided.

What Changes This Time

Over a decade ago, Martin Kuppinger wrote about Shodan, a search engine that indexes internet-connected devices. Tools like Shodan largely ended hiding at the network level: anything with an open port could be found and attacked.

What remained was obscurity inside applications: undocumented endpoints, parameters the UI never sends, logic hidden in client-side code. Scanners find open ports but do not read code, while agents do it routinely. And since every AI system acts through APIs, undocumented APIs are the first place an agent will stumble over.

Back in 2019, I wrote in The Dark Side of the API Economy that assuming nobody knows about your API is a dangerous myth. Seven years later, the myth gets tested every day, by attackers and by ordinary agents alike. As the Australian case showed, an agent does not need hostile intent to find your exposure. Any agent with a task and enough persistence will do, which means your threat model now must include ordinary software going about its business.

Rethinking Priorities

In June, I argued that AI turns patches into blueprints for exploits and shrinks the time defenders have to apply them. That covers known vulnerabilities. This is a different problem: exposure that has no CVE entry and no patch, because nobody knew it existed. A guest endpoint that works as designed will not show up in any vulnerability scan.

Most prioritization models assume exploitation is the bottleneck: fix what attackers actively exploit and schedule the rest. That approach breaks down when agents find and use exposure as a side effect of ordinary work. Patching everything is not an option either, since that only produces an endless backlog.

In practice, both the order and the tools change:

1. Prioritize by reachability. Anything an autonomous agent can reach and act on from outside is in scope, documented or not.
2. Then by how easily an agent could abuse it without any novel technique. Missing authentication, broken object-level authorization, guest access paths, and responses that return more data than needed come first.
3. Treat active exploitation as one signal among several. By the time an issue appears in threat intelligence, someone's agent has likely found it already.
4. Use agents for your own discovery, since the cost of finding exposure has dropped for defenders just as much as for attackers. As Matthew Gardiner put it, you cannot secure the AI agents you don't know about, and the same is true for the APIs they will find.

The ironic part is that this list covers the least exciting work in security. What AI has changed is the shelf life of basic mistakes, which used to last for years and may now hold only until the next agent wanders past.

Access control still works. A properly authenticated and authorized endpoint does not care how persistent its visitor is. The identity models behind it, however, were designed for human-speed users and need attention of their own, since an agent acting on a valid credential at machine speed is a different problem from a human logging in.

Who Looks First?

Every organization now has visitors that read its code and follow every link without ever getting bored. Some are run by attackers, but most belong to researchers, vendors, and ordinary users whose agents stumble onto your systems while working on something else.

Nobody can keep every tiger in its cage, and you will not stop agents from walking down your street either. What remains your responsibility is making sure there is nothing on that street worth finding: start with the reachable, easily abused exposure from the list above, and point your own agents at your estate before somebody else's agents get there first.

Three scenes

You run a service your customers reach remotely: insurance, banking, telecoms, healthcare, a public portal. Three things happened last week at businesses like yours. Not one of them raised an alert.

A retired teacher gets a phone call. Money is leaving her account right now, the voice says; it has to be stopped this minute, and the only way to stop it is for her to confirm the cancellation herself. A request will appear on her phone: approve it, and the payment is blocked. The voice keeps talking, keeps her on the line, never leaves a gap long enough for her to wonder. Her phone buzzes. She enters her PIN. What she has just approved is the payment.

A man gets a text message from his bank: a payment he does not recognise is about to leave his account, and he should check immediately. He taps the link. The site looks exactly as it should, because it is a copy that passes everything he types straight through to the real one. He logs in. His phone buzzes exactly when he expects it to, and he approves. Nothing about the request looks wrong, because nothing about it is wrong. It is a real request from his real bank. It is just not his session. Somebody else is now signed in as him and is about to make the payment the message warned him about.

A man wants a better deal on his insurance. A comparison service offers to do the work for him. He just gives it his login. From then on, the service wears his identity: it does not act on his behalf, it acts as him. He trusts it to compare prices; he cannot see what else it does in his name, and he has no way to control it.

Three events. In the logs of three different companies: three identical, flawless, fully compliant high-assurance authentications.

What you thought you bought

At some point your business connected to your country’s national electronic identity scheme. Most countries now have one of their own. They are separate services, built to a similar design.

There was no real alternative: nothing else came with a national user base already in place. Your customers already had it on their phones. Your regulator recognised it. Your competitors had been using it for years. Somewhere along the way it became the national standard for proving who somebody is, and its reliability is not something anyone in your organisation is expected to question.

But what you were really relying on was never the login. It was evidence: three claims you could stand behind afterwards. This was your customer. They were present. They understood what they were agreeing to.

Any of the three can fail now, and nothing in the record tells you which one did. All you know for certain is that your customer’s credential was used.

The gap

Notice what nobody checked in any of those three scenes: whether the phone doing the approving and the screen showing the transaction were in the same room, or a thousand kilometres apart. Nothing in the chain establishes that the person approving is anywhere near the thing being approved. The approval is portable, and it can be given at any distance.

Worse, the attacker often picks the moment. Triggering the prompt usually needs nothing more than the national personal identity number, the local equivalent of a social security number. How well that number is protected varies a great deal from one country to the next. Where it is easy to come by, the fraudster can make your customer’s phone buzz and call in the same second to explain why.

None of this is a defect, and none of it is vendor negligence. It is a deliberate design from a period when the mobile phone was the only reliable way to reach a citizen. It is what made these schemes possible at all. It also made every transaction structurally an identity-not-present transaction, and we have carried on treating them as though the customer were standing at the counter.

Why this is different now

Two public facts from my own part of Europe, and they fit together.

Supply. In August 2026, Latvia’s road traffic safety administration disclosed a breach of historical payment records: names, personal identity codes, registered addresses, vehicle plates. It covered 1.2 million individuals and 200,000 companies, in a country of fewer than two million people. In practice that is almost every car owner in the country, myself included.

Demand. In December 2025, Eurojust coordinated raids on fraudulent call centres operating out of Ukraine and targeting victims in Latvia, Lithuania and the Czech Republic. Around a hundred employees, recruited across Europe. Commission of up to 7% of proceeds, with bonuses of cars or apartments for anyone clearing €100,000. More than 400 identified victims and over €10 million in losses, roughly €25,000 each.

Personal data on one side, an industrialised sales organisation on the other. Neither is an authentication story on its own. Put together, they describe the conditions your authentication now has to work in.

Why you cannot fix this on your side

I have lost count of the people around me who have had one of these calls. How many have you heard about?

After the Latvian breach, the national computer emergency response team (CERT) advised citizens never to approve an authentication request they had not initiated themselves. The advice is correct. It is also, at national level and following an incident of that scale, the strongest control anyone had available. Not because the CERT is weak, but because the design leaves no other lever to pull.

Consider what that lever is up against. On one side of the phone call: a person who read a warning leaflet once. On the other: a salaried professional on commission, working from a script, with a supervisor and a bonus plan, doing this for the fortieth time today. Awareness training makes the customer the last line of defence against a professional who does this for a living.

I work on identity for an insurer, so I look at this from the side that integrates these schemes rather than the side that builds them. From where I sit the options are narrower than they look. You do not own the identity provider or its roadmap. Step-up authentication does not help when every step shares the same weakness. Your fraud engine sees a clean session, a familiar device pattern and a valid signature, because that is exactly what it was. When the customer comes back and says it was not them, that signature is what your disputes process has to work with. Everything you can build on your side is a compensating control, not a cure.

What proximity means

One sentence: the approval must happen next to the thing it approves.

Passkeys are the familiar illustration. A passkey is bound to the origin it was created for and to the device holding it, so the credential cannot be presented to a site that is not the real one. Phishing against that credential is not made less likely, it is made impossible, because there is no way to present the credential to the wrong site at all. Passkeys are not a drop-in replacement for a national scheme, and nobody should pretend otherwise. The point is narrower and more useful: the industry now has a working example of what it looks like when presence is built into the design instead of being asked for.

And it does more than stop fraud. Scraping behind a customer’s login ends with it too. What ends is the impersonation, not the service: an aggregator would still be free to offer exactly what it offers today, it just could not do it by becoming the customer. It would have to ask for the data it needs, for a stated purpose, and be told yes or no. That is a better product than the one those customers have now, and it does not leave anyone carrying a risk they cannot see.

What only the schemes can do

The technology is no longer the obstacle. Apple, Google and Microsoft have spent years moving ordinary consumers onto passkeys, at a scale nobody else could have tested. That was the hard part, and it is now behind us. What has not followed is the other end of the market: the schemes standing behind contracts, payments and sensitive personal data, where the assurance matters most.

None of that makes the change cheap, and two objections deserve stating plainly.

Investment. Many of these schemes were built and funded by the banking sector. Adding proximity binding means rebuilding and writing off part of what was built. Set against that is what the gap already costs, year after year, in fraud operations, dispute handling and awareness campaigns that never remove the cause.

The people it would hurt most. Any change to how people authenticate falls hardest on those who find it hard already: customers who are less confident with digital services. They are also the ones the fraudsters call first. Whatever proximity would cost them, the flow they have today is not protecting them.

So, what we are asking for is simple. An approval used to prove that it was your customer, that they were there, and that they knew what they were agreeing to. Today it proves only that their credential was used. Proximity is what brings the rest back.

There is also a question of timing. European digital identity wallets are being built now, under rules that are already agreed. Rules do get revised, and protecting people from this kind of fraud is a fair thing for the next revision to take on. In the meantime, the wallet market is open by design. A provider is free to offer proximity-bound approval and to compete on it.

Card-present, twenty years on

The payments industry has been here before. It did not solve card fraud by asking people to be more careful. It separated card-present from card-not-present, admitted that the second was structurally weaker, and then changed what a transaction required.

Digital identity is roughly where cards were twenty years ago, except that the industry has not yet admitted the distinction exists.

What to do next

European digital identity wallets are arriving, and with them a choice of providers. Proximity-bound approval is something you can require of them, and something you can choose between them on, while the market is still forming.

With your existing scheme, ask where it stands on proximity binding: whether it is on the roadmap, what it would take, and what would trigger it. No provider will rebuild for one customer, but enough of them asking the same thing is how these schemes have changed before.

Until that changes, the rest stays with you. Every remote approval you accept is a decision about how much evidence that transaction deserves, and nobody else is going to make it for you.

Key Topics:

🤖 “When the internet was rolled out, we had time to catch up. Agents roll into a world where businesses are already completely dependent on IT and there are hundreds or thousands of them doing different things.” Matthew Gardiner on why this time really is different.

📊 KuppingerCole Analysts’ AI Visibility and Observability Platform research is live and the AI Security Fabric is landing in days. Watch this episode, then dive into the research at kuppingercole.com.

The price is the first thing to notice. Reports of takeover interest first surfaced in June, when Bloomberg reported that Varonis was fielding preliminary interest from Blackstone, Vista Equity Partners and Thoma Bravo, Proofpoint's owner. The shares rose as much as 23 percent intraday and closed with the company valued at about $4 billion. The $49.75 per share offer is a 52 percent premium to the June 22 close, the last trading day before the rumors, but only 17 percent above the September 1 close, before further reports of a sale. That is a modest premium for a company that had been reported to be exploring a sale since June.

The capability fit is the second thing, and it is genuine. Proofpoint knows people and messages: email security, DLP, insider risk, information protection. Varonis knows data and permissions: classification across cloud storage, behavioral tracking of who touches what, and the access graph that says who should be able to reach which file.

Stitch those together and you can answer a question few organizations answer cleanly today. Who accessed what, was it appropriate, and should they have been able to reach it at all? From the mailbox through to the file share. That is a real capability, and it is the thing most buyers say they want and few of them own.

The thesis is stated plainly on Proofpoint's own deal page: "Connecting intent and behavior with data and access." The joint press release describes a unified platform that finds and protects sensitive data, controls what people and AI can access, and stops data loss.

That framing captures the chain-of-custody problem for agentic AI in the buyer’s own words. It does not, however, establish whether the architecture they purchased is the right solution. That’s a question worth examining, and it divides into two bets.

The First Bet: The Capability Fit Is Real

My colleague Martin Kuppinger makes the point that this deal is about data security, and that is what makes it interesting. Look at the consolidation we have been watching for two years and most of it is XDR, SIEM, SOC tooling: capability overlap dressed as platform. This is different. Proofpoint's strength is the person and the message. Varonis' strength is the data and the permission. They are adjacent rather than overlapping, and the seam between them is exactly where the interesting security problems now live.

Martin's read is that the fit adds value to both sides. Proofpoint becomes materially larger and acquires a capability it would have taken years to build. Varonis, which he describes as a somewhat boring asset on its own, becomes considerably more valuable inside the combination. That is a sound strategic logic.

This bet is easy to see and most observers will see it. It is not, however, the bet that decides whether the $6.3 billion was well spent.

The Second Bet: The Architecture, and Who Owns the Integration

Here is the part that requires more caution, and Martin's framing of the acquirer is the key to it.

Proofpoint is owned by Thoma Bravo, which took it private in 2021 for approximately $12.3 billion and is providing committed equity financing for this deal. The logic of Proofpoint plus Varonis forming a larger entity, cutting costs, and pushing toward an IPO is a perfectly valid approach. It is also specifically Thoma Bravo's business. Thoma Bravo is not a strategist in the sense of building larger entities around functional integration. They approach this financially. That matters, because the value of this deal depends entirely on whether anyone intends to do the functional work.

Martin also notes that SailPoint, another Thoma Bravo portfolio company, has already been through its IPO. Thoma Bravo retained roughly 88 percent at the February 2025 IPO and remains the majority holder, but a listed company is no longer a piece it can quietly fold into a private combination. That undercuts the tidy "buy and build an identity giant" narrative that the market has been carrying since 2022. What is left is a financial operator assembling scale, with an announced architectural thesis attached to it.

So the second bet is this. Proofpoint's stated model connects intent and behavior with data and access. That is an inference model, even where it enforces: know more, correlate more, infer intent from behavior, and decide from the pattern whether the action was legitimate. Proofpoint's own agent security product, Proofpoint AI Security, launched in March, applies intent-based detection to evaluate whether an AI action aligns with the original request and intended purpose. Its September launch added intent-based access control, which checks whether an AI action matches company policy and the stated purpose of the person or agent behind it. That is enforcement. But the decision still rests on an inferred purpose.

There is a competing school, and it is not a variation on a theme. Call it authorization. It says you should not be inferring what an agent intends from its behavior. You should bind the agent to a human principal, attach an explicit, scoped, auditable mandate to the actions it is permitted to take, and let the permission decide. The pattern is evidence. The mandate is the control. Both schools enforce; they differ on what the enforcement decision rests on. Vendors such as Cerbos, with its policy-as-code authorization engine, and Cakewalk, with a runtime gateway that approves or denies each agent action before it reaches the application, are building on this side of the line. So, in a different register, is Certiv, which intercepts agent actions at the endpoint rather than inferring intent from the network.

Those architectures fail in different places. Inference-based security fails quietly, when the agent's behavior looks plausible but is wrong, and the anomaly never rises above the noise. Authorization-based security fails loudly, when a legitimate action is blocked because the mandate was scoped too tightly. Quiet failures do not show up in a budget review. Loud ones generate tickets and complaints. That asymmetry tends to favor inference at the point of purchase, whichever architecture is actually safer.

The industry has been here before. For twenty years we tried to detect insider threat by watching behavior, and for most of that time false positive rates left those programs struggling to produce results a real SOC could act on. The programs that worked did not infer intent. They reduced standing privilege, scoped entitlements, and required a reason for access. The lesson from the insider threat era was that authorization beats inference, and the industry keeps rediscovering it at considerable expense.

There is an obvious objection to placing this deal in the inference school. Varonis is not purely an inference product. Its access graph and least-privilege remediation, stripping stale and excessive permissions, are exactly the standing-privilege reduction that worked in the insider threat era. Read that way, Proofpoint has bought the authorization half it lacked. The distinction is scope. Varonis governs which humans and groups can reach which files. It does not issue per-action mandates to agents bound to a human principal, and the announced thesis folds its permission data into an intent and behavior model rather than a mandate-based control plane. Whether the combined product uses the access graph as a source of correlation signals or as an enforcement point is the question that decides which school Proofpoint has actually joined.

On the evidence of the announcement, Proofpoint has agreed to spend $6.3 billion consolidating the inference school and giving it one of the largest data estates in the category. If inference is the answer, this could be the smartest acquisition in security this decade. If authorization is the answer, they have bought the most sophisticated possible version of the thing that gets displaced, unless they turn Varonis' permission model into the enforcement layer.

Three Things to Watch

First, whether the integration happens at all. A financial owner optimizing for cost reduction and an IPO is not the same as a strategic owner building a product. The announced thesis is unusually architectural for a financial buyer, which cuts both ways: either the intent is real, or it is IPO narrative. Watch the product roadmap, not the press release. This is where many of these deals quietly fail, and it takes around two years to find out.

Second, the agentic roadmap. Proofpoint's deal page lists the combined scope as running from data posture and data access governance through insider risk, DLP and AI governance. That is several products with different buyers. Watch whether the AI governance piece arrives as a real control plane, with policy scoped to agents and their principals, or as intent scoring wrapped around permission data. The announcement promises control over what people and AI can access. The question is whether that control is anchored in an explicit mandate or an inferred purpose.

Third, whether the authorization school gets funded. If Proofpoint's move is read as the definitive answer to agent governance, the money follows it, and the authorization vendors stay small. If it is read as one expensive bet by a financial owner, there is room for a challenger to make the opposite case to CISOs who were told to consolidate and still cannot explain what their agents are doing.

The wider context matters here, and KuppingerCole is documenting it now. Palo Alto Networks announced its acquisition of Protect AI in April 2025, for model and application security. SentinelOne agreed to acquire Prompt Security in August 2025, extending its platform into GenAI and agent security. Cato Networks acquired Aim Security in September 2025, adding AI-SPM and agent security to its SASE platform. Veeam agreed to pay $1.725 billion for Securiti AI in October 2025, fusing data resilience with DSPM, privacy, governance and AI trust. Add Proofpoint and Varonis to that list and the pattern is consistent: AI security is consolidating into the larger platforms. The list is not exhaustive; Varonis itself bought AllTrue.ai for $150 million.

KuppingerCole predicts that AI-SPM will survive as a module inside cloud, data, network and enterprise security platforms rather than as a category most buyers purchase on its own. The reason is arithmetic rather than conviction. Five acquisitions in eighteen months, at reported deal sizes from roughly $250 million to $6.3 billion, tell you where the exit path for a specialist vendor now runs: into a platform, not onto an exchange. A startup that wants to sell AI security directly to enterprises has to build a sales motion against buyers who are already consolidating their vendors, and it has to do that inside a window that is closing. On the current trajectory, we expect most standalone AI security vendors to face a platform-or-acquisition decision within roughly three years. Vendor CEOs should plan the product on that assumption, or plan to be acquired.

Which brings us to the measurement problem. "The industry's largest data and AI cybersecurity organization" is a claim, not a fact, and it depends on how you measure. By customer count, 16,000 enterprises is real scale. By data-security revenue, the deal values Varonis at 8.4 times trailing revenue, implying roughly $750 million a year, which is not a market leader being crowned. By AI security capability, the category does not yet have a clear leader, which is precisely why the thesis is contestable and why so many of these players are buying their way in.

What This Means for Security Leaders

If you are a Proofpoint or Varonis customer, nothing changes in the near term. The deal is expected to close in the first half of 2027, subject to shareholder and regulatory approval, and the two companies will operate independently until then. What you should do now is the thing you should have done anyway: work out what your agents are permitted to do, and whether that is expressed as a rule someone can audit, or as a pattern someone hopes to detect.

The acquisition does not change the hard question. It just makes it more expensive to get wrong.

Vendor consolidation is often sold as simplification. What it does is concentrate a bet. Proofpoint has placed a very large one, in public, on the idea that the right answer to AI risk is understanding intent rather than authorizing action. Security leaders will be living with the consequences of that bet for years, whichever way it goes.

I would treat the premium as the tell. Acquirers rarely pay 52 percent over the pre-rumor price for a company reported to be exploring a sale since June unless they are more afraid of the alternative than they are excited about the asset. The alternative, in this case, is a world where the agent, not the inbox, is the new center of gravity in security, and the platform they have spent two decades building ends up aimed at the wrong target.

That does not make the acquisition wrong. It makes it a hedge, by a financial owner, and hedges are priced for the risk, not the opportunity.

•  why an agent exists,
• within which bounds it may act,
• and who answers for it.

Technology can register, authorize, audit, and stop agents with increasing reliability. It cannot decide who is accountable for them. Organizations that stop at the technical layer will end up with excellent enforcement of decisions that nobody can explain or defend.

The accountability gap

The gap shows most clearly after an incident. Our Advisory Note When AI Agents Break the Security Model names four questions any auditor will ask:

• what did the agent run,
• what did it access,
• who authorized the agent and its access,
• and what did it do.

A well-built control plane can answer three of them from its own records. The question of authorization is of a different kind, and most organizations cannot answer it with confidence today.

The usual answer is the owner field in the agent management platform. In practice, that field contains the person who created the agent, typically a developer, a platform engineer, or the owner of the platform it runs on. This person knows how the agent works, but rarely why it exists in the sense in which a manager knows why a role exists in the organization. The owner field tells you whom to email when something breaks. When that developer changes teams, it points to nobody, and the agent keeps running.

The owner field tells you whom to email when something breaks. It does not tell you who answers for what the agent does.

Token-based delegation does not close this gap either. Token exchange can carry the acting party and even a nested delegation chain, and well-designed chains narrow authority at every hop. That chain, however, starts with whoever initiated a request. The person accountable for the agent’s business purpose, a service owner, a department head, or a risk owner, is rarely that initiating actor and therefore does not appear in the token. Neither does the decision that this agent may hold that authority in the first place.

Enforcement requires a decision

A policy engine can enforce a boundary, but it cannot decide who is accountable for setting it. Consider an agent that may place orders of up to EUR 10,000 per run. The control plane can enforce that limit perfectly. It cannot tell an auditor who decided on EUR 10,000, who may approve an exception, or who answers if the limit was wrong. A perfectly enforced policy can still rest on a decision that nobody actually made or owns.

A policy engine can enforce a boundary. It cannot decide who is accountable for setting it.

Closing the gap is organizational work, and none of it requires a new product category:

• A business-side owner who accepts responsibility for how an agent, or a class of identical agents, is used. One owner per class is sufficient only where the instances share purpose, authority, and risk. The same agent deployed in two business contexts may well need two owners.
• Purpose and bounds defined before the first credential is issued. Provisioning either establishes accountability or skips it, and retrofitting it later is considerably harder.
• A lifecycle tied to purpose. Nobody resigns on an agent’s behalf. The end of an agent’s purpose has to become the offboarding trigger, and the control plane has to enforce it through to delegated credentials, child agents, and queued actions.

Figure 1: Closing the accountability gap

A capable identity registry can hold this information. The demanding part is the governance process that produces it and keeps it current, and that process is human work.

Why the control plane alone is not enough

None of this diminishes the progress on the technical side. Vendors, standards bodies, consultancies, and analysts have published blueprints for agent identity that are largely coherent. Our whitepaper From AI Agents to Trusted Digital Workers describes the core capabilities: registering every agent as a first-class identity, issuing short-lived credentials per task, evaluating authorization at runtime and close to the action, maintaining an immutable audit trail, and stopping an agent that deviates from its expected behavior. Standards such as Rich Authorization Requests, DPoP, and token exchange are maturing in parallel. Organizations that build to such a blueprint are ahead of most.

These blueprints, however, assume a clean start: one platform, one identity provider, every agent registered at birth. Enterprises carry years of service accounts, scripts, RPA bots, pipelines, and OAuth grants in SaaS tenants, spread across subsidiaries, outsourced operations, and regulatory regimes. Most organizations were never particularly good at governing these existing non-human identities. Agents do not arrive in an empty room, and they inherit every accountability gap that already exists.

Figure 2: Key elements of an agent control plane

The question to start with

The control plane will keep improving, and organizations should continue to invest in it. The next real advance in agent governance, however, will come from decisions only the organization can make. Ownership and accountability stay human, even for agents that are numerous and short-lived, while enforcement can and should be automated. The first step is to review the agents already in production. For every new agent, one simple rule applies: no runtime credentials are issued until its purpose, its bounds, and an accountable owner are documented.

Organizations that stop at the technical layer will end up with excellent enforcement of decisions that nobody can explain or defend.

One question sums this up. Every employee has a manager who knows what they are there for, can tell them to stop, and notices when they leave. Who is your agent’s manager?

Guillaume Teixeron, Senior Analyst at KuppingerCole Analysts and author of the Leadership Compass on Identity Verification, will walk through the Leader charts and the evaluation methodology behind them, explaining which capabilities now separate Leaders from Challengers: layered deepfake and injection attack defenses, document forensics and NFC chip verification, eID and wallet integrations, and enterprise orchestration. He will examine how reusable verified identity is emerging as a distinct market segment, why organizations engage multiple vendors for coverage and redundancy, and share practical guidance for defining vendor selection criteria for your own identity verification strategy.

The keynote was called “A Fabric Is Only as Strong as Its Edges,” and nobody in the line needed the point explained. Someone described a payroll system still sitting outside the central directory. Another mentioned a SaaS tool a department had bought with a corporate card. A third, holding the stir sticks, said theirs was both.

A month later, at AI & NHI Impact Day in Munich, a similar huddle formed. The conversation had shifted from comparing fabrics to examining what was acting within them.

Cologne: The corridor was a federation layer

Split agendas always bring the dilemma of choice. Panels on orchestration and SaaS governance ran alongside sessions on team design and predictive AI, making it impossible to attend everything. The corridors became a point of convergence, where people exchanged session takeaways and carried them into further discussion.

“This was my first Identity Fabric Impact Day, and what I appreciated most was being able to take what was said in the sessions and discuss it straight away with other identity practitioners. There are many ways to achieve the same goal, and that exchange is how you find out someone else has already solved the same problem. The industry is rightly focused on agentic AI; the challenge I believe needs more focus is identity at the edges, an operational population that remains significantly underrepresented.”

James Naughton, Independent Identity Professional

The questions people raised weren't just about technology. By the end of the sessions, they were asking about Monday morning. Who owns the fabric once the architecture is agreed? Who needs to be hired to run it? What should be triaged first?

Those questions echoed the afternoon keynote, “The Fabric Is Not the Deliverable: The Triage You Run This Week,” and an earlier session on how team design becomes an identity capability. The agenda and the audience had arrived at the same place without coordinating.

KuppingerCole Lead Advisor Patrick Teichmann highlighted the panel on shadow IT sprawl:

“My personal highlight was the panel ‘Taming the Shadow IT Sprawl,’ where we discussed the nature of agents and where we had quite different approaches and views. All four agreed that you cannot govern what you cannot see, but they split on what follows from that: whether AI agents are a separate identity type requiring their own governance model, or simply the fastest-moving members of a non-human identity population we already know how to handle. This is always the most interesting part of such events. So I see this event as a kind of ‘pitstop’ for organizations, where they can check in on what has changed in the industry.”

Munich: The question moved from “where” to “who”

At AI & NHI Impact Day, variations of the same question surfaced at the end of more than one session: Who approved that?

The agenda had been circling the question all day. “Who Approved That? The One Question Your Agent Logs Cannot Answer.” “Every Machine Is Another Identity, but Who Authorized the Outcome?” “The Owner Is Not the Principal.” The panel title put it plainly: “Your AI Agent Is Not a Service Account.”

At the microphone, the questions became practical. If an agent acts on a task someone has given it, who is accountable for the result: the person who owns the agent or the person who made the request? Nobody in the room claimed to have a definitive answer.

The registration desk had already illustrated a small version of the same problem. A badge carries a name and a company. It identifies you, but it doesn't tell you what you're authorized to do. Nobody at the event lent their badge to a colleague. Yet that's effectively how many agents operate today: using someone else's identity to get things done. One session on the program captured the principle in a single line: “Delegate Authority, Never Your Identity.”

We asked attendees what they enjoyed most, and their answers sounded a lot like the conversations in the corridors. Networking and open discussion came up repeatedly: meeting peers, hearing analysts' perspectives and exploring topics in greater depth. One attendee highlighted the concrete insights shared by Allianz, Mercedes-Benz, DIF and KuppingerCole. Others singled out the opening keynotes and Grace Rachmany's session on the question agent logs cannot answer.

One first-time KuppingerCole attendee called the day “flawless” and said it wouldn't be their last. Taken together, the feedback captures what made the day valuable: the sessions supplied the questions, and the breaks were where people tested them against someone else's setup.

What the two days have in common

Cologne was about how things connect. Munich was about who acts through those connections. Underneath both was the same unglamorous checklist: know what's there, know who owns it, and know who answers for it.

Nobody needed a new vocabulary for that. They needed ten minutes with someone who had a similar system.

Explore the sessions:

• Identity Fabric Impact Day, Cologne, September 9
• AI & NHI Impact Day, Munich, October 6

Next up: Customer Identity and Access Management

The next Impact Day turns the same questions towards the customer, with AI already on the other side of the login. The focus shifts to delivering secure, privacy-centric digital experiences while preparing for emerging identity ecosystems.

If Cologne asked what the fabric didn't reach and Munich asked who approved the agent, the next question is about the identity on the other side of the interaction: Is it a customer acting for themselves, an agent acting on their behalf, or something else entirely?

CIAM Impact Day takes place on November 18 at the Hilton Frankfurt. It's designed for identity professionals, digital leaders, security teams and customer experience specialists looking to understand what's next for customer identity.

In Part 2 of this conversation, Berthold Kerl sits down with Thomas Tschersich, CSO of Deutsche Telekom Group, at Deutsche Telekom’s headquarters in Bonn. Thomas has led security at one of Europe’s largest critical infrastructure operators for decades, overseeing cyber, physical, and personnel security and running Deutsche Telekom Security, which serves more than 700 external clients.

This episode goes deep on the gap between compliance and real defense, the role of mindset and organizational culture in security, and what the latest generation of AI models (including early access to GPT Cyber 5.5 and Mythos) actually means for vulnerability management, red teaming, and the economics of agentic security workflows.

Thomas also makes the case for where security leaders should focus first: 80–90% of attacks are organized crime, not nation states. Get that under control before worrying about the other ten percent.

Topics covered: Compliance vs. real security, threat modeling, red teaming, AI-powered vulnerability discovery, super patches, agentic security workflows, security culture, critical infrastructure defense.

As identity security programs mature, the focus is expanding beyond privileged human users to include machine identities, service accounts, workloads, APIs, and AI agents. This evolution is driving the convergence of PAM and broader Identity Security initiatives, making privileged access controls a critical component of modern cybersecurity and compliance strategies.

In this panel discussion, Martin Kuppinger, Distinguished Analyst at KuppingerCole Analysts and Vera de Chauvigny, Senior Marketing Inteligence Lead and Guido Kraft, Field CISO & Compliance Expert at Wallix will examine the current state of the European PAM market and discuss the trends shaping the future of identity security. Together, they will explore how organizations are responding to evolving regulatory requirements, increasing cyber threats, and growing demands for digital sovereignty.

The panel will provide diverse perspectives on topics such as the rise of non-human identities, cloud entitlement and privilege management, the role of AI in cybersecurity, and the increasing importance of PAM as a foundation for modern Identity Security platforms. Drawing on market insights and real-world experience, the speakers will share best practices for combining security, compliance, operational efficiency, and sovereignty requirements in complex European environments.

The two incidents differ in scale and in method. Yet both raise the same question: what happens next? A data breach is rarely only about the records that were taken. It is about what those records make possible afterwards.

The DTU Breach: Two Decades of Records Behind One Login

The DTU breach began with compromised credentials. How the attackers obtained them has not been confirmed, and credential stuffing and phishing are among the possible routes. Once authenticated, they had access to DTUBasen, the system that holds identity data for staff, students and alumni.

What they found there spanned more than twenty years. Nearly 40,000 active users and around 160,000 former users may be affected. The exposed information includes CPR numbers, full names, home addresses, profile pictures, work details and next of kin information. In MITRE ATT&CK terms, the attack maps to Valid Accounts (T1078) for initial access, Data from Information Repositories (T1213) for collection and Exfiltration Over C2 Channel (T1041) for the final step.

Several technical gaps may have made this possible. First, it is not yet known which authentication controls protected DTUBasen. If valid credentials alone were enough to reach a repository of this sensitivity, the absence of a second factor or step-up verification would be a significant weakness. Second, the attackers were likely able to escalate privileges and move across user databases, which suggests weak segmentation within the IAM environment. Third, large volumes of data left the system before anyone noticed. This points to limited monitoring of bulk queries and outbound traffic.

There is also a quieter issue. Around 80 percent of the affected records belong to people who no longer have any relationship with the university. Data retention, in other words, multiplied the impact of the breach fivefold.

The CPR incident: The Access Was Legitimate

The CPR incident followed a different path. Under the Danish CPR Act, companies with a legitimate interest may look up information on individuals. One such company held valid search access to the register, and unidentified parties misused that access to run unauthorized searches during September. The CPR administration spotted irregular activity on the evening of 2 October, confirmed the unauthorized access over the weekend and cut the company off.

The scale is striking. The register contains records on about 11 million people, including those who have died or emigrated, which explains why 8.8 million affected records exceeds Denmark's population of roughly six million. Names, addresses and CPR numbers were exposed. People registered for name and address protection were not affected, a small but telling sign that some controls held.

Based on what is known so far, no vulnerability was exploited and no password was guessed. The system did what it was designed to do: answer queries from an authorized party. That is precisely the problem. Authentication confirmed who was connecting, but nothing adequately checked whether the volume and pattern of searches matched a legitimate business purpose. The anomaly was eventually detected, but only after weeks of activity.

The CPR number sits at the heart of Denmark's highly digitized public sector. Every resident relies on it to deal with government agencies, banks and healthcare providers. When it is exposed together with a name and address, the damage is not limited to one register.

Context Is the Real Prize

Names, addresses, CPR numbers, employer details and next of kin create something more valuable than any single field: context. Context makes phishing more convincing. It strengthens social engineering. It can be combined with data from other breaches or public sources to build a detailed profile of an individual or an organization.

Artificial Intelligence (AI) amplifies this. Large language models (LLMs) can process large datasets, connect data points and write personalized messages in fluent Danish at scale. An email that mentions your former department at DTU, your home address and the name of your next of kin is far harder to dismiss. The minister has urged citizens to be vigilant about suspicious calls and emails. Vigilance, however, cannot carry the burden alone.

Lessons Learned for Cybersecurity and IAM

Both incidents point to lessons that go well beyond General Data Protection Regulation (GDPR) compliance or individual caution.

Protect the identity system as critical infrastructure - An IAM platform grants access to everything else. It deserves phishing-resistant multifactor authentication (MFA), privileged access management (PAM) for administrative functions and conditional access policies, in line with GDPR Article 32 and NIS2 Article 21.

Treat data retention as an identity governance decision - Former users should be deprovisioned, and their data minimized or deleted once its purpose has expired. Data that no longer exists cannot be exfiltrated.

Monitor behavior, not only authentication - Valid credentials and legitimate access say nothing about intent. User and entity behavior analytics, query rate limits and alerts on bulk exports would shorten the window between abuse and detection.

Govern third-party access continuously - The CPR company passed the initial test of legitimate interest. What matters is whether its use stays within that purpose over time. Purpose-bound entitlements, periodic access reviews and contractual audit rights belong in every arrangement where external parties query sensitive registers.

Prepare for non-human identities (NHIs) - As organizations give suppliers, systems and AI agents access to their data, the CPR case offers a clear warning. Access granted for one purpose can quietly be used for another.

The question Denmark now faces is not only who was behind these breaches. It is how many other legitimate doors remain open without anyone watching how they are used.

Today's enterprises often operate multiple identity and access management (IAM) solutions simultaneously, including several identity governance and administration (IGA), customer identity and access management (CIAM), and identity provider (IDP) platforms. As identity environments become increasingly fragmented through cloud adoption, mergers and acquisitions, and evolving business requirements, organizations face growing challenges in connecting and coordinating these systems effectively.

John Tolbert, Principal Analyst at KuppingerCole Analysts will explore how identity orchestration is evolving beyond traditional user journeys to encompass API-level integration, policy coordination, process orchestration, and resilience across complex IAM ecosystems. Participants will learn how orchestration can help organizations streamline joiner-mover-leaver (JML) processes across multiple platforms, support IAM modernization initiatives, improve business continuity, and enable seamless integration of both human and non-human identities.

Marco Venuti, IAM Enablement and Acceleration Director at Thales Group will provide a practical perspective on how organizations can leverage orchestration to maximize the value of existing IAM investments, simplify complex identity architectures, and address emerging requirements such as AI agents, non-human identities, account recovery, and human-in-the-loop approval processes.

These changes are pushing SaaS security beyond the traditional boundaries of SSPM. Discovery and configuration monitoring remain foundational, but the market is evolving toward broader visibility and control across identity posture, OAuth and third-party integrations, data exposure, active threats, remediation workflows, compliance, cost governance, and AI agents. What is emerging is not simply a larger feature set, but a more unified control plane for SaaS and AI risk.

Drawing on the findings of the SaaS Security and AI Governance Leadership Compass, this webinar will examine where the market is heading, which requirements are moving from optional to essential, and where capabilities remain immature or fragmented. Attendees will gain a research-driven view of the market’s evolution and the implications for security architecture, governance, and program priorities.

Matthew Gardiner, Fellow Analysts at KuppingerCole Analysts will present the central findings from KuppingerCole’s SaaS Security and AI Governance Leadership Compass research. He will explain how AI is changing the scope and direction of SaaS security, identify the capabilities moving from optional to essential, and discuss what this evolution means for enterprise security architecture, governance, and investment priorities.

An acquisition can bring together different security environments. A cyberattack can disrupt essential services. Technology dependencies can become strategic concerns. Geopolitical developments can change how organizations think about their digital infrastructure.

For today’s CISO, security is increasingly part of decisions that reach well beyond the traditional security perimeter.

Four episodes of The CISO Perspective look at what that means in practice.

Security starts before the deal

An acquisition brings together more than two businesses. It can also bring together different technology environments, identities, attack surfaces and security cultures.

In When Giants Merge: Securing M&A Integrations, Max Killinger and Berthold Kerl explore the security challenges of major acquisitions, including due diligence, identity, attack-surface visibility and the challenge of bringing different security cultures together.

The key point: security work starts before integration day.

When the business is critical infrastructure

The stakes are different when the organization you protect helps keep the lights on.

In When the Lights Go Out: Cybersecurity at Europe's Energy Grid, René Rindermann of E.ON discusses cybersecurity in the energy sector — including IT and OT security, ransomware, Zero Trust, AI and crisis preparedness.

Here, resilience is not just about protecting data. It is also about keeping essential services running when something goes wrong.

That changes the question from “Can we prevent an attack?” to “Can we keep operating if one happens?”

Technology dependencies become a security question

Cybersecurity also increasingly involves decisions about the technology an organization depends on.

The European CISO Dilemma: Sovereignty, Dependencies, and Tool Sprawllooks at the practical challenges behind European cyber sovereignty — from understanding dependencies to managing complexity and making decisions about platforms and providers.

There is no single answer. But understanding where those dependencies sit is an increasingly important part of security decision-making.

And geopolitics is part of the picture

In The Evolving Battlefield: AI, Zero Trust, and the Case for European Cyber Sovereignty geopolitics and sovereignty come together.

For security leaders, the challenge is to understand how changes outside the organization can affect its technology choices, dependencies and resilience.

The CISO conversation is getting bigger

Across these four episodes, security connects directly to M&A, operations, critical infrastructure, technology strategy and geopolitics.

That is what makes these conversations interesting: they show security leaders dealing with questions that increasingly sit at the intersection of cybersecurity and the wider business.

This is one side of the CISO story.

The other looks at how AI, identity, emerging threats and quantum computing are changing the security landscape.

Explore The CISO Perspective and continue with AI, Identity and the CISO’s Changing Agenda.

Steal the session, and you inherit the documents the agent can read, the systems it can reach, the skills it possesses, and the voice it uses when it writes on your behalf. That makes the agent an insider in every sense that matters to a security team.

Compare that with a stolen password. A password gets an attacker to a login page, where MFA, device checks, and risk scoring still stand in the way. A session token has already passed all of those tests. For the attacker, it is the difference between a forged concert ticket that still has to get through the gate and an access wristband already on your wrist.

Tomorrow at AI & NHI Impact Day in Munich, this is the argument we will put on the table. Here is a first look at it:

Every insider control assumed a human

Organizations spent two decades building insider threat programs. I helped define that security category, and I know what went into it: least privilege, user and entity behavior analytics (UEBA), session monitoring, and segregation of duties. Every one of those controls assumed a human behind the keyboard.

UEBA builds a baseline of how a person works: the hours they keep, the systems they touch, the volume of data they move. Segregation of duties splits sensitive tasks across human roles, so that no single person can both request and approve a payment. Session monitoring watches what a person does for signs of harmful intent.

AI agents break each of these assumptions. An agent acts with our authority, so its access is our access. It works at machine speed, so its volume would trip any human-centric detection. The agent often holds the permissions of several roles at once, because it was set up to help across a whole workflow, thus potentially violating segregation of duties. And it sits inside our trust boundary, where most monitoring is weakest.

In 2026, many organizations are deploying agents with broad permissions, deep context access, and the ability to act, without the controls they would demand for a new employee with the same reach. The threat model we perfected for humans is missing for the non-human colleagues we just gave the keys to.

The gap is not a lack of awareness. Most security leaders know that agents hold broad access. The gap is ownership: identity teams see agents as applications, application teams see them as productivity tools, and the insider threat program does not see them at all.

Four attack paths, one pattern

Evidence from recent weeks shows attackers already treating the agent as the trusted path into the enterprise. Four vectors stand out.

• Session theft. Infostealers now harvest AI session tokens alongside browser cookies. A stolen agent session skips the login, the MFA prompt, and the device check, because the session has already passed them.
• Prompt injection at scale. Research has moved from one-off demonstrations to industrialized evaluation. Work such as CAITLYN, LongPIBench, and ECLIPSE shows how big the problem is. LongPIBench finds that simple injections hidden in long documents bypass state-of-the-art defenses. ECLIPSE builds stealthy attacks that steer long-horizon agents through multi-step tool chains. CAITLYN finds that static defenses stay vulnerable to new injection techniques. One poisoned document, email, or web page can redirect an agent long after it was initially reviewed and deployed.
• Consent-based social engineering. The ClickFix campaign compromised 31 organizations through fake consent screens. People approved what they saw, and machines then executed what they approved. Agents widen that gap: a user grants a permission once, and the agent uses it from that point forward.
• Poisoned supply chains. The TanStack npm poisoning and the TeamPCP arrests show malicious components flowing into the same package pipelines that coding agents pull from. An agent that installs dependencies on its own can import an attacker's code with the developer's full privileges, but without their consent.

The pattern is the same in each case. The attacker does not break the trust boundary; the attacker borrows an agent that already sits inside it. Traditional controls look for an outsider trying to get in, or a person behaving oddly. They are not built to question an authorized agent doing what it appears to have been asked to do, at speeds far beyond any human.

This is why the insider threat frame fits for AI agents. An insider is dangerous because the organization has already decided to trust them. The same is true of an agent, and the attacker's job is simply to leverage that trust. Like human insiders, agents do not need an attacker to cause harm. A poorly scoped or misconfigured agent can delete records, leak data, or pay the wrong supplier while it tries to do its job.

What comes next

If the controls we built for human insiders miss agents, what does that do to fraud detection, and what should security teams do about it? We will take both questions up after the event, with what we hear in Munich.

Until then, one thing you can start today: find out how many agents your organization runs, who owns them, and what they can reach. You cannot apply least privilege to an identity you do not know exists.

Join us at AI & NHI Impact Day, October 6 in Munich to continue the conversation. Register here.

That gap matters more now because generative music and voice cloning are becoming easier to use while detection remains imperfect. KuppingerCole Analysts has examined how modern voice-cloning systems can reproduce a person’s tone from limited source material. The music industry therefore needs more than an end-of-process label saying that “AI was used.” It needs an attributable production history.

Content Credentials offer one way to provide it. Based on the Coalition for Content Provenance and Authenticity (C2PA) specification, they associate a music asset with a cryptographically signed manifest describing its provenance. The point is to preserve verifiable evidence so labels, platforms, rightsholders and creators can make better-informed decisions.

Why Music Provenance Is Now an Identity Problem

The discussion around AI music often begins with detection: can a platform determine whether a track, voice or instrument was generated? Detection has a role, and it belongs in the toolkit alongside watermarking and content authentication, but on its own it is an arms race. Compression, remixing and deliberate alterations can weaken technical signals while generative models continue to improve.

Provenance asks a different question: what claims accompanied the asset, who made them, and have they been changed?

C2PA records claims about an asset and its history. The Creator Assertions Working Group’s (CAWG) Identity Assertion Specification adds an identity layer by allowing a named actor to prove control over a digital identity and bind it to selected assertions in the C2PA manifest.

In music, the actor might be a performer, songwriter, producer, engineer, label, distributor or mastering service. A vocalist could be associated with a performance, a producer with a mix, and a label with the release submitted to a platform.

This matters because the credential signing a C2PA manifest may identify the software, service or organisation operating the claim generator rather than the human creator. CAWG provides a way to make a person’s or organisation’s relationship to particular claims explicit.

What this buys is attribution: the identity claim becomes tamper-evident and traceable to whoever made it. Trust still depends on which credentials, identity providers and issuers the relying party accepts.

What the Manifest Can Say About a Track

A C2PA manifest can describe production history through actions, source types and ingredients.

Actions describe what happened. A singer may create a vocal recording. A producer may open it, edit it, place it into a session, mix it and export a new track. In C2PA, “created” means that an asset came into existence; it does not mean it was made entirely by a human.

The digitalSourceType associated with an action describes how that operation was performed. A recorded vocal may be classified as digital capture. A generated instrumental may be trained algorithmic media. Conventional noise reduction may be algorithmically enhanced. Existing audio altered through generative AI may be composite with trained algorithmic media.

This classification belongs to the relevant action, not automatically to the entire song. A track may contain a captured vocal, a generated pad, a licensed sample and a manual mix. Reducing that history to one “AI” label loses information that platforms, policymakers and audiences need.

Ingredients describe what was used: vocal takes, stems, samples, loops, previous mixes or AI-generated layers. When ingredients already have Content Credentials, the final manifest can reference their earlier manifests through cryptographically bound links, preserving the production chain.

C2PA can also identify a region of interest. If generative AI replaces four seconds of a vocal, the provenance record can identify that time range instead of implying that the entire track was generated. The specification’s c2pa.ai-disclosure assertion can add structured information about the model and human oversight, complementing rather than replacing actions and ingredients.

Where Content Credentials Fit, and Where They Do Not

Three things get better immediately.

AI disclosure becomes more precise. Platforms can distinguish generation, AI-assisted editing and ordinary algorithmic enhancement rather than asking creators to choose an ambiguous label.

Provenance can also support copyrightability and chart-eligibility reviews. A manifest might show that a human vocalist was recorded, an instrumental was generated and the final mix was completed manually. It cannot make the legal or policy decision, but it can provide better evidence.

And credits can travel with the production history. CAWG identity assertions can associate named actors with the contributions they endorse, strengthening the information supplied to credit, rights and payment systems.

Content Credentials should work alongside Digital Data Exchange standards, not replace them. DDEX supports the exchange of recording, contributor, rights and commercial metadata across the music value chain. C2PA and CAWG can provide an upstream provenance layer, capturing information during recording, generation, editing and mixing. Labels and distributors can then use that evidence to support downstream DDEX workflows.

The boundary must remain clear. A valid manifest shows only that particular claims were signed with a particular credential and have not been changed since, not that a sample was licensed, that the signer owns copyright or that every contributor was paid. Legal, contractual and policy decisions remain with the relevant organisations.

The Persistence and Trust Challenges

Provenance is useful only if it survives the route from studio to listener.

Music is transcoded, normalised, clipped, streamed and incorporated into user-generated content. These transformations may strip embedded metadata. The C2PA Soft Binding Resolution API can help recover a separated manifest by using a watermark or fingerprint to locate it in a repository.

For audio, the recovery method must be imperceptible, robust under common processing and resistant to false matches. Soft binding should remain optional: a company should not have to adopt watermarking simply to participate in Content Credentials.

Trust is the harder challenge. A validator can confirm that a manifest is well formed, unaltered and signed with a particular credential. Policy must still decide whether that signer is trusted to claim that a performer participated, a label approved a release, or an AI disclosure is complete.

The user experience must communicate this distinction. “Valid signature” cannot become shorthand for “all claims are true.” KuppingerCole Analysts’ discussion of content authenticity in the age of AI similarly frames the problem as a hybrid ecosystem involving content, identity and governance, not a single universal authentication protocol.

What Music and Identity Leaders Should Do Now

Organisations should begin with a narrow, policy-driven deployment rather than trying to record every studio event.

1. Define the decisions provenance will support. Decide whether the priority is AI labelling, contributor credits, release acceptance, chart review or another use case. Record only the information needed for that decision.
2. Establish the identity and trust model. Specify who may make or endorse each claim, which CAWG credentials are accepted and how validators distinguish a tool operator from a human or organisational contributor.
3. Capture provenance at creation boundaries. Start with tracks, stems and major components. Note-level or automation-level provenance would add complexity without proportionate value.
4. Keep provenance separate from legal conclusions. Use Content Credentials as evidence for rights, credit and policy systems, not as a replacement for licences, contracts, royalty databases or human review.
5. Design for persistence and privacy. Test what survives transcoding and platform ingestion. Use soft binding only where necessary, minimise repository telemetry and explain what is disclosed to each audience.

The music industry does not need another universal “AI” badge. It needs a verifiable account of how a track moved from studio to stream: which sources were used, which actions occurred and which actors stand behind the resulting claims.

Content Credentials will not judge the music. Their job is to preserve enough trustworthy context that the people and systems receiving it can judge the evidence for themselves.

Key Topics:

• Why AI removes the development bottleneck in IAM — but exposes the real one: requirements definition
• The danger of saying yes too easily: how AI makes it tempting to build what should never be built
• Security risks in AI-generated IAM code: what the research actually shows
• A seven-step framework for evaluating any IAM customization before writing a single line
• The customization registry: how to build transparency and governance into what already exists
• When to stop customizing and ask whether the platform itself is the wrong tool

⚠️ "AI makes code cheap but the bottleneck in IAM was never primarily creating the code." Patrick Teichmann on why removing the development barrier without fixing requirements definition is a recipe for a new generation of Lotus Notes.
📄 Patrick's advisory note on IAM Customization Governance is published on the KuppingerCole Analysts website now; watch this episode first, then dive into the research.

Today's environments are significantly more complex than the infrastructures for which traditional compliance models were designed. Organizations must manage identities across on-premises systems, multi-cloud environments, SaaS applications, partner ecosystems, and growing numbers of non-human and machine identities. As a result, the gap between documented compliance and operational reality continues to widen.

Many organizations discover critical issues only when preparing for an audit or after a security incident has occurred. Orphaned accounts, excessive privileges, dormant access rights, policy violations, and identity governance gaps often remain hidden for months because visibility is fragmented and assessments occur too infrequently. Regulatory frameworks such as SOC 2, ISO 27001, NIST, and others increasingly require organizations not only to demonstrate compliance, but also to prove that controls remain effective over time.

In the conversations from KuppingerCole’s The CISO Perspective, four security leaders look at different parts of that challenge: from securing AI today to preparing for threats that may take years to materialize.

AI is changing the game

AI is already influencing both attackers and defenders.

In Full Steam Ahead: AI, Attackers, and Why CISOs Must Keep Pace, Michael Schrank and Berthold Kerl look at what AI means in practice for security teams.

AI can automate repetitive work, support investigations, and make security processes more efficient. But when organizations adopt AI faster than security teams can establish the right controls, new risks emerge.

For security leaders, that means being part of the conversation about how the business adopts AI, not just managing the risks afterwards.

Then there’s the question of identity

As organizations use more AI, applications, machines and AI agents are increasingly acting alongside people.

That raises a basic security question: who or what is allowed to access which resources?

That is the focus of Identity at the Epicenter: Why AI Makes It the Most Critical Control in Security.

The fundamentals haven’t changed. But there are more identities to manage, and more things that can act on behalf of an organization. 

Security also has to look beyond technology

In Bigger Than Technology – A 360-Degree View of the Modern Threat Landscape, Thomas Tschersich of Deutsche Telekom takes a broader view of cybersecurity: looking at business impact, resilience and the environment in which organizations operate.

As he puts it: “So you need to get a much broader view in my perspective.”

The point is simple: security decisions affect more than systems. They affect people, operations and the organization’s ability to keep going when something goes wrong.

And some threats need to be addressed before they arrive

Quantum computing is a different kind of challenge.

In The Harvest Is Done: A CISO's Take on the Quantum Cryptography Threat, Connie McIntosh looks at what quantum computing could mean for today’s cryptographic foundations and why organizations need to start preparing now.

Her advice is practical: “You must start with the inventory and mapping your dependencies.”

Across all four conversations, the message is consistent: the CISO’s agenda is increasingly about looking ahead: understanding what is changing, where dependencies are emerging, and what the organization needs to prepare for next.

Explore The CISO Perspective for these conversations and more, including M&A, critical infrastructure, cyber sovereignty and the broader business role of the CISO.

• Why traditional CNAPP is evolving to address AI-native applications and autonomous workflows.
• How leading vendors are integrating AI-SPM, runtime intelligence, and attack-path analysis.
• Why runtime context is replacing static posture as the primary method of prioritizing cloud risk.
• How agentic AI is transforming cloud security operations through automated investigation and remediation.
• What organizations should look for when selecting the next generation of CNAPP platforms.

Jonathan Care, Practice Lead AI at KuppingerCole will examine how identity and access management must evolve as AI agents become autonomous actors. They will explore the distinction between agent ownership and delegated authority, why conventional human and service-account models fall short, and how organizations can establish clear boundaries, governance, and accountability for agents acting on behalf of others.

Grace Rachmany, Executive Director at Decentralized Identity Foundation (DIF) will explore how delegated authority can be implemented and demonstrated in practice. They will address scoped and revocable mandates, binding agents to verified principals, and creating an evidence chain that connects an agent’s actions to its authorization. This allows organizations to establish not only what happened, but who authorized it and within what limits.

Human Responsibility

Before answering that it is worth considering the case where you asked a colleague to do the deed. In UK law a criminal liability for many criminal offences, depends upon a prohibited act (actus reus) together with the required state of mind (mens rea).

In the conventional human case, criminal liability for many offences requires both. If I intentionally instruct a colleague to commit an offence and the colleague knowingly commits it, the law has established concepts for dealing with both actors. CPS guidance describes a principal as someone who performs or causes the actus reus with the required mens rea, while someone who intentionally assists or encourages the offence may incur secondary liability.

Agent Responsibility

With an AI agent, however, you potentially separate the two elements in a novel way.

The AI agent may perform the physical or digital acts constituting the actus reus, but, under the present UK legal framework, it isn't a human defendant possessing a legally recognisable guilty mind in the ordinary sense. Saying that a model "intended", "decided", or "knew" something computationally is not the same thing as establishing mens rea in a legal person.

Human Intent

If I deliberately instruct an agent, “Hack this competitor's system and steal its customer database,” the conceptual problem is relatively manageable. My own intention is evident, and the AI is essentially the instrument through which I cause the prohibited conduct. The fact that software executes the instruction shouldn't necessarily create an accountability vacuum.

But suppose I say: “Find out what products our competitor is developing and give me a report.”

The autonomous agent subsequently discovers that it can obtain better information by circumventing authentication on the competitor's system. I never requested that action, expected it, or perhaps even knew that the agent possessed the necessary capabilities.

The prohibited conduct may therefore occur without an obvious human actor possessing the mens rea required for the relevant offence.

And there is an intermediate case that may be even more interesting: “Find out whatever you can about our competitor. I don't care how you do it.”

Here the agent selects the particular unlawful method, but the human's instructions and surrounding circumstances may become highly relevant to determining the human's intention, knowledge or potentially other applicable mental state. English criminal law already deals with concepts such as conditional intent; importantly, mere foresight is not automatically equivalent to intent, although it can be evidence from which intent is inferred.

Chain of Responsibility

The important security question isn't merely: Which agent performed the act?

We may need to establish:

Who deployed it? → Who instructed it? → What instructions were given? → What authority was delegated? → What identity and credentials did it use? → What actions did it independently select? → What policies constrained it? → What actually happened?

That is effectively a digital chain of responsibility.

As AI agents become more autonomous, identity infrastructure must provide a verifiable chain connecting machine actions to human authority. Knowing which agent acted is no longer sufficient; organizations must be able to establish who authorized it, what authority was delegated, and where human instruction ended, and autonomous machine decision-making began.

Agent Response

From an identity and governance perspective, there are three particularly important classes of response:

• “I can't do that” means the action is unavailable to the agent because it lacks the necessary capability or effective permission.
• “I won't do that” means the agent may technically be capable of performing it, but a policy, legal constraint, risk control, or delegated-authority boundary prohibits it. That is much closer to how we expect human and organizational governance to operate. An employee may technically be capable of transferring a customer database to a personal account, for example, but organizational policy says they must not. Effective governance doesn't depend on making every prohibited action physically impossible; it establishes boundaries on permitted behaviour and enforces them.
• “I need authorization” means I could perform it, but the action exceeds my current authority and requires human or higher-level approval. This is particularly important. Suppose an AI purchasing agent normally has authority to place orders up to £10,000. It identifies an opportunity requiring a £100,000 commitment. A well-governed agent shouldn't simply be incapable of creating such an order, nor should it necessarily refuse permanently. It should recognize that the proposed action exceeds its delegated authority and escalate it to an appropriate human principal.

Mature AI Identity Governance

Mature agent governance should be able to distinguish between: "I won't perform that action because it violates policy" and "I can't perform that action because I lack the required capability or authorization."

The distinction matters because the first tells us something about trustworthiness. The agent possesses capabilities but operates within externally established constraints.

There is also an important security architecture implication. We shouldn't rely entirely on an agent's internal reasoning to decide that it “won't” do something. For higher-risk actions, the surrounding identity and authorization infrastructure should independently enforce those boundaries. In other words, agent governance should combine behavioural policy with deterministic authorization controls.

Trust in an AI agent is not simply knowing what it can do. It is knowing what it is allowed to do, what it will refuse to do, and when it must ask for additional authority. Explore this Live at AIdentity & Non-Human Identity Impact Day 2026 October 6 in Munich. 

Join the in-person conference for analyst insight and practitioner case studies on building this foundation in your own environment. 

Register Now  |  See the full agenda

Key Topics:

✅ The LocalAI attack: 23 unprotected MCP servers, root access in minutes, military data exposed
✅ Is MCP a new security problem or just a new label for old ones?
✅ The Deadbugs attack: how tool descriptions were silently poisoned to manipulate AI agents
✅ Who is responsible for MCP security: Anthropic, the vendor, or you?
✅ Tool poisoning, prompt injection, and the gaps between AppSec, NetSec, and endpoint teams
✅ Monday morning recommendations: what to actually do about MCP security right now

🔐 "Models reason, APIs act, and identity grants the authority to act" Alexei Balaganski's one-line summary of why MCP security cannot be solved by a single tool or a single team.

📅 MCP is a symptom, not the disease, join KuppingerCole Analysts at the upcoming AIdentity & NHI Impact Day, CIAM Impact Day, and Identity-Centric Cybersecurity Summit events in Germany to continue this conversation in person.

Three years ago, if you searched an IAM job description for the word "AI," you mostly found it in the acronym soup around "AIM" typos and vendor marketing decks. Today it's a line item: required skill, and not a nice-to-have. Somewhere between those two states, the identity market went through a structural shift. I wanted to trace it in detail, with numbers.

This piece looks at how AI moved through identity management hiring in stages: where it started, how the job market absorbed it year by year, which vendors led and which are still catching up, how M&A reshaped who owns what, which entirely new IAM specializations exist only because of AI, and where this is heading through 2027.

A note before the data: I've used cybersecurity-wide figures as the closest available proxy where IAM-specific numbers don't exist, and I've flagged every place where that substitution happens.

Where This Actually Started

AI in identity did not begin with ChatGPT. It started years earlier, inside a completely different acronym: UEBA, User and Entity Behavior Analytics. Gartner coined the underlying concept in its 2015 Market Guide, explicitly extending the model to cover non-human actors like servers, routers, and endpoints. In practice, this meant IAM and SIEM vendors were bolting machine-learning risk scoring onto access management by the mid-to-late 2010s: flag the login that doesn't match the user's usual pattern, flag the access request that doesn't match the role. Nobody called this "AI" in a job posting. It was "analytics." It was a quiet phase, and it matters because it means the technical groundwork for AI-driven identity governance predates the current hype cycle by the better part of a decade.

The visible break came in 2022-2023, for the same reason it hit every other corner of tech hiring: generative AI. Lightcast's tracking shows job postings requiring generative-AI skills growing roughly ninefold in non-IT roles and 35-fold in other IT roles between 2022 and 2024. IAM rode that same wave, but with a lag. Identity vendors needed a product cycle before "AI" became a sellable, then hirable, feature.

That product cycle landed in 2023-2024. SailPoint began marketing "AI-Driven Identity Security" as a platform pillar and launched AI-powered application onboarding on June 13, 2024, followed by GenAI-generated entitlement descriptions. Okta introduced AI-based identity threat signals under the "Okta AI" label. This is the point where "AI" starts showing up as a named requirement in IAM job descriptions rather than being folded into generic "automation" language.

2024 is also when a second, more consequential shift began: non-human identity. AI agents are themselves non-human identities, and every enterprise now generating AI agents is generating a governance problem that didn't exist at this scale before. By 2025-2026, "agentic AI" became its own tracked skill cluster in labor-market data, and NHI/agent governance graduated from a side note to a genuine new hiring category. (More on exactly which vendors moved here, and how, in the M&A section.)

AI in IAM Jobs, Year by Year

Before 2021, the quiet baseline. AI-tagged skill demand in security roles is negligible and largely unlabeled. Generative-AI-specific job postings in the US are essentially a rounding error: Lightcast counted 55 unique generative-AI postings in January 2021, the closest baseline data point, climbing toward the low thousands by 2023.

2023, the inflection year. CyberSeek data, per secondary reporting puts AI-skill requirements at roughly 6.5% of all cybersecurity postings. This is the first year the number becomes a trackable line rather than noise. (Cybersecurity-wide)

2024, vendor branding meets job descriptions. CyberSeek's data release puts the figure at approximately 10% of employers recruiting for cybersecurity positions citing AI as a requirement over the twelve months to April 2025. Separately, Cisco's AI Workforce Consortium report (a different methodology and time window, covering Cornerstone/Indeed job-posting data) shows 14.2% of cybersecurity postings requiring AI skills in the twelve months to March 2025. That gap between the two figures is a useful reminder of how much the number moves depending on which slice of the year and which underlying dataset you use. This is also the year SailPoint's and CyberArk's machine-identity moves start generating job requirements rather than press releases. (Cybersecurity-wide)

2025, doubling and a new skill cluster. The same Cisco AI Workforce Consortium report shows AI-skill requirements in cybersecurity postings reaching 28.5% for the period October 2025 to March 2026, roughly double the year before. Five skills recur across AI-tagged postings: Python, prompt/context engineering, AI security, agent orchestration, and MLOps. Meanwhile, Stanford's AI Index added "Agentic AI" as its own tracked skill cluster for the first time, showing it jump from 0.06% of US postings in 2024 to 0.23% in 2025: a 280%+ increase, representing roughly 90,000 postings. Non-human identity volume grew 44% year-over-year through this period, and the NHI-to-human identity ratio estimates range from 45:1 to 82:1 depending on whose methodology you use (Rubrik Zero Labs vs. CyberArk's 2025 Identity Security Landscape study). (Cybersecurity-wide plus identity-specific NHI data)

2026, governance becomes the hiring story. This is the year the conversation shifts from "does the platform use AI" to "who governs what the AI agents are allowed to do." Teleport's  2026 Infrastructure Identity Survey found that 92% of organizations already have near-term AI initiatives in production infrastructure, 79% are evaluating or deploying agentic AI specifically, but only 13% feel "extremely prepared" for it. That gap, widespread deployment paired with minimal readiness, is exactly the kind of gap that generates job requisitions. AI governance postings specifically (a broader category than IAM but heavily overlapping with it) grew 150% year-over-year according to LinkedIn's 2026 Skills on the Rise report, among the fastest-growing skill categories LinkedIn tracks in any field.

2027, the projection. One hard deadline makes 2027 predictable in a way most labor-market projections aren't. The European Commission's enforcement timeline confirms the EU AI Act's high-risk system requirements (Annex III) become enforceable on December 2, 2027: a compliance deadline with the same structural effect on IAM/AI-governance hiring that GDPR had on IAM hiring in 2017-2018. Worth noting this date is itself a delay: the original deadline was August 2, 2026, pushed back to December 2027 via the EU's "Digital Omnibus" simplification package, finalized in mid-2026. And Gartner's projection that 33% of enterprise applications will incorporate agentic AI by 2028 (up from under 1% in 2024) implies that by 2027, NHI and agent governance stops being a specialization and starts being a baseline expectation for mid-to-senior IAM roles, the same way cloud IAM knowledge became non-optional a few years earlier. If the 2024-to-2025 doubling pattern in AI-skill cybersecurity postings holds even at half that rate through 2026-2027, AI/agent-governance literacy moves from "differentiator" to "assumed" for the majority of IGA, PAM, and access management postings by the time the EU AI Act deadline lands.

Three Fields AI Turned into Hiring Categories

IAM has absorbed new technologies before: cloud, mobile, zero trust. But those were adaptations of existing IAM work to a new environment. The following three were either absent or niche concerns until AI turned them into standing hiring categories.

ITDR (Identity Threat Detection and Response). ITDR platforms use behavioral analytics and anomaly detection, the direct descendants of that mid-2010s UEBA groundwork, to detect identity-based attacks continuously and in real time, rather than relying on periodic log review or investigation after a breach has already been reported. It draws heavily on existing PAM and SIEM practice, but it is organized around a different assumption: that AI-speed attacks require AI-speed detection, and that traditional, batch-oriented monitoring cycles cannot keep up.

NHI / Machine Identity Governance. Service accounts and API keys existed long before AI. What's new is the scale and the actor: AI agents now generate, use, and discard machine identities autonomously, at a volume no manual process can track. The job category, governing credentials that no human requested, uses, or remembers to revoke, is a direct consequence of agentic AI operating at machine scale and machine speed.

Agentic AI Governance. This is the newest and least standardized of the three. It covers the specific problem of what an autonomous AI agent is allowed to access, under what conditions, and with what accountability trail when something goes wrong: a governance question that literally could not exist before agents capable of independent action existed. Purpose-built products now cover parts of this directly, such as Ping Identity's "Identity for AI," which reached general availability on March 24, 2026, and Okta's Cross App Access, which became a stable, official MCP authorization extension on June 18, 2026, with early MCP-provider partners including Asana, Atlassian, Canva, Figma, and Supabase. When a new product category forms around a problem this specific, hiring for that problem usually follows a year or two later.

How Vendors Bought Their Way Into AI

Organic product development explains part of the shift above. The faster part of the story is acquisition, and the dates tell a specific story: AI wasn't the driver from the start. It became one partway through 2024, and by 2026 it was the dominant rationale in the space.

2022-2023: consolidation, not AI. The defining moves of this period were Thoma Bravo's take-privates of SailPoint (April 2022, $6.9B), Ping Identity (October 2022, $2.8B), and ForgeRock (August 2023, $2.3B) (Identity Management Institute). None of the announcements from this period, across dozens of smaller deals as well, framed the rationale around AI. This was financial and capability consolidation in a fragmented market, plain and simple.

2024: the first genuinely AI-adjacent deal, framed as "machine identity," not "AI." CyberArk acquired Venafi (signed May 20, 2024; closed October 1, 2024; approximately $1.54 billion). The announcement framed the deal around securing "every identity, human and machine." Worth flagging precisely: this deal predates the agentic-AI framing entirely. It's about cloud and DevOps-driven machine identity growth, not AI agents specifically. I'd classify it as AI-adjacent infrastructure rather than AI-motivated in the strict sense, and it's the closest thing to a bridge between the old consolidation logic and what comes next.

2025: AI framing becomes explicit, and the pace picks up.

•  CyberArk acquired Zilla Security (announced February 13, 2025; approximately $165 million cash plus a $10 million earnout, per TechCrunch). AI-motivated, though less explicitly than the framing suggests at first glance: TechCrunch reports that CyberArk sought tools "purpose-built for the cloud, with AI at its core," and describes Zilla as having spent recent years "adding more automation and AI-enabled features" to its platform. CyberArk CEO Matt Cohen's quoted rationale, however, centers on governance and scale rather than AI specifically: "we will reshape identity governance with scalable automation that delivers compliance and helps maximize security for the modern enterprise."
• Palo Alto Networks acquired CyberArk (announced July 30, 2025; approximately $25 billion equity value; closed February 11, 2026). Also explicitly AI-motivated: the press release states the deal will "deliver Identity Security for agentic AI by securing autonomous AI agents." This is the largest deal in the space and the clearest single signal of AI as the strategic driver behind identity M&A. The combined business has since been rebranded Idira under Palo Alto.
• Okta acquired Axiom Security (announced August 26, 2025; closed September 4, 2025; reportedly around $75 million per Israeli press). AI-motivated per Okta's framing: Computer Weekly headlined its coverage "Okta makes AI identity play," and Okta's CTO cited AI-related risk explicitly as a driver.
• Zscaler acquired SPLX (announced November 3, 2025; terms undisclosed). Explicitly AI-motivated: SPLX specializes in AI red-teaming and AI asset discovery.

2026: AI and non-human identity become the dominant M&A rationale in the entire identity sector.

• CrowdStrike acquired SGNL (announced January 8, 2026; reportedly around $740 million). AI-motivated: the press release is titled "Transform Identity Security for the AI Era," with CrowdStrike's CEO stating, "AI agents operate with superhuman speed and access, making every agent a privileged identity that must be protected."
• Silverfort acquired Fabrix Security (announced April 28, 2026; terms undisclosed). AI-motivated: Fabrix is described as "AI-native," and the deal is framed around delivering "autonomous Identity Security at runtime" for the AI era.
• Cisco acquired Astrix Security (announced May 4, 2026; reportedly $300-400 million per press estimates, undisclosed officially). Explicitly AI-motivated: Cisco's blog post announcing the deal is titled "Securing the Agentic Workforce" and frames AI agents as "an entirely new class of coworker."
• Zscaler acquired Symmetry Systems (announced May 21, 2026). AI-motivated: explicitly described as "identity mapping and data access for AI security".
• Snowflake acquired Natoma (announced May 27, 2026; terms undisclosed). AI-motivated, and notable because Snowflake isn't a traditional IAM vendor: this is a data-platform company buying an MCP and agent-identity governance layer specifically to control what AI agents can do with enterprise data.
• SailPoint acquired Entro Security (announced June 15, 2026; closed June 29, 2026; reportedly around $200 million per SecurityWeek). AI-motivated: framed explicitly around securing "agentic identities" as non-human identity volume "has eclipsed human identities"
• 1Password acquired Apono (announced June 15, 2026; reportedly $250-300 million per Israeli press). AI-motivated: described as "just-in-time access governance for humans, machines, and AI agents".
• Okta acquired Permiso Security (announced July 30, 2026; deal terms undisclosed by either company). Per TechCrunch's original reporting, a person with knowledge of the deal put the price at just under $200 million, almost all cash; Okta's spokesperson did not dispute the figure when asked. Closing was expected within Okta's fiscal Q3 2027 (by end of October 2026), per the same report. AI-motivated: Okta's press release describes Permiso as "a cloud-native identity security platform that detects and mitigates threats across human, non-human, and agentic identities in multi-cloud environments."

The pattern across all these deals is unambiguous once you line them up by date. Zero AI-framed IAM acquisitions in 2022 or 2023. One AI-adjacent deal in 2024, framed around machine identity rather than AI specifically. Four deals in 2025 with AI stated explicitly as the rationale. Eight AI or NHI-motivated deals in 2026 alone, more than the entire prior two years combined. Whatever else is uncertain about how this market develops, the acquisition timeline itself is a clean, dated record of exactly when "AI" stopped being marketing language and started being the reason boards approve nine and ten-figure checks.

Underneath this wave sits the older consolidation wave that gave several of these buyers the balance sheet to go shopping in the first place: Thoma Bravo's ownership of both SailPoint and Ping Identity is a good example (hhhypergrowth; MajorKey Tech). Private-equity and platform-scale ownership structures across the sector are part of what made rapid, repeated AI-capability acquisition financially possible rather than something every vendor had to build from scratch.

What this means for hiring: vendor consolidation is deciding which AI capabilities get bundled into a single platform versus sold as a point solution, and that decision shapes the job posting itself. An employer that just absorbed an NHI acquisition is more likely to hire for "NHI governance" as a platform-agnostic skill than for a single vendor's feature set. Expect that framing to keep growing in job postings as more of these deals close and the acquired teams get folded into bigger platforms.

Who Moved First & Who's New

Early movers. SailPoint has the most consistent public AI positioning of the established IGA vendors. "AI-Driven Identity Security" is framed as foundational to its platform, and it shipped agent-identity connectors for Copilot, Bedrock, Vertex, Foundry, Agentforce, ServiceNow, and Snowflake Cortex in March 2026, followed by Agentic Fabric, launched May 11, 2026. CyberArk's 2024 Venafi acquisition (see M&A section above) was the clearest early single-vendor signal that machine and AI-identity security was becoming core business rather than an add-on.

The new players. Before being acquired, the pure-play NHI and agentic security vendors (Entro Security, Astrix Security, Oasis Security, SGNL, and others named in the M&A section) didn't exist as a category two years ago. Several generated original research that is now cited across the industry (Entro's NHI ratio tracking is a good example) before being folded into larger platforms. Oasis Security, notably, moved from a standing letter of intent with Cyera to a closed deal in September 2026, which leaves almost no independent vendor in this category. This is the fastest-consolidating corner of the vendor landscape, and correspondingly the one with the thinnest available talent pool for anyone hiring against it directly.

Where AI-in-IAM Skill Demand Concentrates

By sub-domain. IGA has the most mature AI integration: KuppingerCole's 2026 research agenda states that "IGA purchasing decisions will be driven by measurable AI outcomes such as less access review effort, reduced toxic access, and more automation" by 2026, with AI-driven access recommendations and anomaly detection now a standard evaluation criterion. PAM's AI story is increasingly about machine-credential rotation and monitoring rather than human privileged-account management. Access Management/SSO's AI story is narrower, mostly adaptive, risk-based authentication. NHI/agentic governance is the newest and least mature domain, and the one growing fastest from a small base.

By skill type: "use AI" versus "build/govern AI." The majority of current IAM postings ask candidates to use AI: interpret vendor risk-scoring output, work inside AI-assisted certification workflows, understand what the copilot-style interface is recommending and why. A smaller, faster-growing, better-paid segment asks candidates to build or govern AI: NHI/machine identity governance specifically, agent orchestration, AI governance frameworks (NIST AI RMF, EU AI Act readiness), and AI security for identity systems themselves rather than AI as a tool inside them. This is the same build-versus-use distinction that shows up in every broader AI labor-market study, and it's sharpening inside IAM specifically as agent governance moves from theoretical to mandatory.

By country. The cleanest available signal is Stanford HAI's 2026 AI Index, via Lightcast's contributor page, which measures the share of all job postings (not IAM-specific) mentioning AI skills: Singapore leads at roughly 4.7%, followed by Hong Kong (3.5%), Luxembourg (3.4%), and Spain (3.3%), with the United States at 2.6%, just ahead of Chile (2.4%) and the United Kingdom (1.9%).  Separately, Eurostat's December 2025 release of its enterprise AI-adoption survey (a different methodology, measuring organizational use rather than job-posting language) puts Denmark (42.0%) and Finland (37.8%) at the top of the EU, against an EU average of 20.0%. These two rankings disagree because they're measuring different things: job-posting concentration versus enterprise deployment.

What This Means, Practically

For IAM professionals: the AI skill that pays is not "I used a chatbot." It's non-human identity governance, agent orchestration, and AI-specific security and compliance knowledge: the build/govern track, not the use track. If you're a DevOps engineer who already manages secrets, or an ML practitioner curious about identity, you are closer to the fastest-growing part of this market than most traditional IAM job titles suggest.

For hiring organizations: the data shows a consistent pattern of widespread deployment paired with minimal readiness: 79% of organizations are evaluating or deploying agentic AI, while only 13% describe themselves as extremely prepared for it. That gap closes on its own timeline regardless of budget cycles, and the EU AI Act's December 2027 enforcement date puts a hard floor under how long it can stay open.

Key Topics:

✅ The three breaks in agentic AI authorization: intent, anonymous tokens, and unattributed logs
✅ Why enterprise systems weren't designed to distinguish human actions from agent actions
✅ How a vague human prompt can silently grant an AI agent sweeping, unintended permissions
✅ KYAOS: an open, compatible standard for scoped, time-bound, cryptographically signed agent authorization
✅ Surgical credential revocation — without taking down the entire service
✅ Live demo preview: tamper resistance, expired credential revival, and forensic speed

🤖 "I didn't realize I was giving it permission to use emojis" and if that innocent mistake is hard to trace, imagine a financial access or database permission. KYAOS is the open standard designed to close that gap.

📅 Catch Grace's full presentation and live demo at the AIdentity & NHI Impact Day on October 6th in Munich

Omada's First Strategic Move Since the GRO Deal

On 24 September 2026, Omada announced that it has acquired EmpowerID, the US-based identity vendor headquartered in Dublin, Ohio. Financial terms were not disclosed. EmpowerID's technology will be integrated into Omada's IGA platform, with a focus on runtime governance of AI agents, and EmpowerID CEO and co-founder Patrick Parker joins Omada as Chief Innovation Officer.

The deal follows last year's change of ownership. On 29 April 2025, Omada announced that GRO Fund III, together with Kirk Kapital, would take a majority ownership position. That transaction provided a full exit for CVC Growth Funds and GRO Fund II, with J.P. Morgan Asset Management's Private Equity Group and Danish pension fund P+ joining as co-investors. Then-CEO Michael Garrett said Omada intended to "explore strategic M&A opportunities," and EmpowerID appears to be the first strategic acquisition to follow that commitment.

EmpowerID Extends Omada Beyond Governance

Omada is known primarily as an IGA vendor with strong out-of-the-box capabilities, standardized user experience, and a well-defined process framework. EmpowerID has moved beyond IGA. It has expanded from identity lifecycle governance into identity services such as authorization, orchestration, and connectors, and more recently into AI agent governance.

With EmpowerID, Omada gets a foothold in markets such as PBAM, PAM, and Zero Trust, and a technical foundation for moving IGA toward real-time access control covering human identities, non-human identities (NHIs), and AI agents. This moves Omada substantially closer to being an Identity and Access Management (IAM) platform provider rather than an IGA specialist with a few adjacent capabilities. Martin Kuppinger summarized it in the announcement: "AI agents act at machine speed, and governing them after the fact is not enough." Beyond governing who is entitled to access, runtime authorization adds a check on what an agent is permitted to do at the moment it acts, which periodic certification cycles do not cover.

How the CRUD Service and EmpowerNow Complement Omada

Part of EmpowerID's EmpowerNow AI stack, the CRUD (create, read, update, delete) Service acts as a wrapper around target systems, including legacy ones. Administrators describe the capabilities of a system in YAML, and the CRUD Service exposes them to workflows and agents in a consistent way. Because the user's identity flows through to the target system, actions are executed in the right context. For Omada, this simplifies integration with target systems and helps enforce better identity information quality, which has long been one of the harder parts of IGA deployments in environments with large SAP landscapes and homegrown applications.

Closely related is AI-assisted connector building. EmpowerID states that custom connectors can be built in 15 to 30 minutes with AI assistance, working directly in AI development tools, compared to hours of traditional engineering effort. It also offers more than 300 pre-built connectors. Connectors have traditionally been the slow and expensive part of IGA projects, so if Omada and its partners can deliver more and deeper integrations at speed, including adaptations to customer-specific changes to target systems, it would shorten IGA deployments.

The EmpowerNow components also bring runtime authorization for AI agents. This covers controls for what an agent can do and delegated authority, and it allows agents to complete actions without holding reusable credentials. EmpowerID is also certified for OpenID AuthZEN 1.0. For Omada, this adds runtime enforcement to the offering and should help it make fast progress in AI security.

EmpowerID Fills Gaps in Omada's Agent and AI Roadmap

Omada launched Agent Governance in June 2026, focused on visibility, ownership, and least privilege for AI agents and NHIs, together with compliance evidence for audits. Runtime enforcement was not included in that release.

In recent conversations with Omada customers and partners, confidence in Omada's approach to agents was mixed. Several were uneasy about key capabilities sitting on the roadmap for the end of this year while other vendors have already published solutions. The broader use of AI has also been one of Omada's challenges.

From what EmpowerID has shown in vendor briefings, it brings mature capabilities in AI usage and enhancement, including integrated chatbots, role mining, flexible workflow engines, and analytics. At the same time, customers report that EmpowerID's flexibility has not always translated into robust standard functionality, an area where Omada's out-of-the-box functionality is well established.

Integration Risks Worth Watching

As with every acquisition of vendors playing the same field, there is overlap in IGA. Omada covers it from a commercial off-the-shelf (COTS) perspective with standardized user experience and process frameworks, while EmpowerID follows a developer-centric approach focused on flexible, AI-powered customization. Customers of each will want to know which path their deployment is on. Combining a standardized platform with a highly configurable one will take a while, and the goal should be more flexibility and faster delivery in customized environments without leaving customers with two overlapping ways of solving the same problem.

The benefits described above depend on Omada leveraging EmpowerID's strengths and combining both technical solutions into an integrated approach. If EmpowerID ends up as a separate product line next to Omada Identity, most customers would see little benefit from the deal.

Much of what EmpowerID and EmpowerNow have on the roadmap for agentic authorization is with Patrick Parker and his team. Bringing him in as Chief Innovation Officer and keeping that team engaged through the integration will be essential. Omada will also need to show customers quickly that the acquisition closes the gaps they have raised, especially on agents and AI-assisted governance, ideally with committed delivery dates.

Agent Governance Becomes a Baseline Requirement for IGA

Over the past year, identity vendors have been buying their way into agent and NHI security at a steady pace.

These deals indicate that agent governance is turning into a standard expectation for IGA platforms. Buyers will expect their IGA platform to discover agents, assign ownership, and certify their access, and over time they will expect it to enforce what agents can do at runtime as well.

Omada's deal has a different focus from the others. Most of the other acquisitions were about gaining visibility into NHIs and agents, and EmpowerID brings runtime enforcement and integration speed on top of that.

A Broader Market Position for Omada

KuppingerCole's Leadership Compass on Identity Governance and Administration describes modern IGA moving toward continuous reconciliation and event-driven lifecycle management, with governance extending across human identities and NHIs alike. The EmpowerID acquisition pushes Omada further along that path and into adjacent areas such as policy-based authorization.

A combined Omada and EmpowerID platform points toward a real-time access solution that brings together IGA, policy-based authorization, PAM capabilities, and agent governance. That is a much broader market position than Omada has held so far, and it puts Omada in direct competition with vendors that already market themselves as identity security platforms. Over the next 12 to 18 months, Omada will need to deliver the combined roadmap while keeping the IGA foundation its customers value.

Recommendations

If you are an Omada customer, there is no need for immediate action, but you should ask Omada for a concrete roadmap on runtime agent authorization, AI-assisted role and policy building, and connector development, and for clarity on when EmpowerID capabilities will be available within your current deployment model.

If you are an EmpowerID customer, confirm support commitments and the future of the product line you run today. Where your deployment relies heavily on customizations, ask how these will be carried forward as the platforms converge.

If you are evaluating IGA, you should now treat agent governance as a mandatory requirement, and test discovery, ownership, certification, and runtime enforcement for AI agents during the evaluation. Integration speed is best assessed against your own target systems, including customized ones, since connector counts alone say little about how quickly your environment can be onboarded.

If you are a partner or integrator, AI-assisted connector building may change the economics of your IGA projects considerably, so ask Omada early how and when you will get access to these tools.

As agent governance moves into the core of IGA, Omada has given itself a good starting position, and the integration work ahead will decide how much of it reaches customers as usable capabilities

AI Agent Visibility and Observability Platforms (AI-VOPs) are the category of security tooling built to close these gaps. A security team cannot enforce policy on an invisible agent, hold an owner accountable when none is registered, or judge the risk of unobserved behavior. AI-VOPs watch the agents themselves, regardless of what those agents are used for, who deployed them, or which system hosts them. To advance the conversation, KuppingerCole has formalized AI-VOP as its own market category and opened a Leadership Compass project to evaluate vendors and the market against a full set of requirements.

Why Agent Discovery Alone Isn't Enough

Agent discovery is only the starting point. In the blog You Cannot Secure the AI Agents You Don’t Know About, I made the straightforward case that organizations cannot secure or govern agents they cannot see. A follow-up post, AI Agent Observability: The Seven Controls Needed After Agent Discovery, went further. Knowing an agent exists tells a security team nothing about what it did, which credentials it used to do it, or whether the organization could reconstruct that activity in an audit. Three of the seven controls that post laid out were runtime telemetry and trace capture; interaction and delegation mapping; and behavioral analytics and policy violation monitoring. Each supplies something discovery cannot: agent behavior, chains of delegated authority, and the evidence a response team needs before it can act.

What AI-VOP Covers

The AI-VOP Market Definition lays out seven areas against which solutions will be evaluated:

1. Agent discovery and visibility
2. Agent inventory, ownership, and identity context
3. Runtime telemetry and trace capture
4. Interaction and delegation mapping
5. Permission, credential, and tool access analysis
6. Behavioral analytics and policy violation monitoring
7. Explainability, audit, and governance reporting

Agent discovery and visibility means continuously discovering and tracking agents and agentic workflows across enterprise environments, including sanctioned and unsanctioned agents, shadow AI deployments, platform-native and developer-built agents, and agents embedded in SaaS, cloud, automation, and business applications. Agent inventory, ownership, and identity context adds the detail that makes a discovered agent governable: owner, creator, purpose, operating identity, delegated authority, and the users, service accounts, OAuth grants, API tokens, secrets, and connected resources underneath it.

Runtime telemetry and trace capture records prompts and responses, tool invocations, API calls, reasoning traces, Model Context Protocol (MCP) activity, code execution, data access events, errors, and cost and latency signals.

Interaction and delegation mapping traces the relationships and execution paths among agents, sub-agents, users, tools, APIs, and data sources, including the delegation chains that form when one agent acts under another's authority. Permission, credential, and tool access analysis flags access that is excessive, stale, over-privileged, transitive, or inconsistent with least privilege and separation of duties.

Behavioral analytics and policy violation monitoring evaluates agent activity against organizational policy and surfaces anomalies, suspicious tool use, and violations. Explainability, audit, and governance reporting explains how and why an agent reached a decision and produces tamper-resistant evidence for internal governance, EU AI Act, DORA, and NIST-CSF review.

Where the Category Boundary Sits

Vendors and other interested parties should weigh in on these seven areas. If you think the definition is missing a capability that belongs to the AI-VOP category or includes one that should carry less weight or sit outside of it, let us know. Where the boundary sits matters, because adjacent categories are already crowded. LLM and application observability tooling measures the quality of a model or an application; AI security posture management (AI-SPM) continuously assesses the configuration, exposure, and vulnerabilities of the AI estate itself (models, pipelines, datasets) and the infrastructure they run on. AI-VOP instead tracks the agent as an acting identity: what it reached, under whose credentials, and with what authorization.

We understand that most vendors will not offer pure AI-VOP solutions. Most will also span one or more of the other categories in KuppingerCole’s six-category agentic AI security framework as well as more traditional, non-AI security controls. This overlap is expected and normal in an early-stage market.

What Comes Next

KuppingerCole recently sent vendor invites for participation in the AI-VOP Leadership Compass. If you were missed, it is not too late to take part. The evaluation runs primarily using a technical questionnaire organized around the seven areas described above. If you think your solution should be included, reach out to KuppingerCole Analysts by mid-October 2026 and we will forward you the invite for your consideration.

An organization cannot govern, secure, or budget for what it cannot see. Agents that no one in security has reviewed often hold standing credentials, touch sensitive data, and act on someone’s behalf, whether or not that action was authorized. AI-VOP is the control layer that makes agents visible and keeps them monitored. Everything else in agent security and governance builds on top of this layer. If you are an enterprise security leader, start by asking how many agents are running in your environment and who owns them.

This panel brings together an independent analyst and One Identity practitioners to examine how AI agents and non-human identities are changing workforce identity models, privilege management, and governance, and what to do about it now.

Machine identities get created and never cleaned up, accumulating as orphaned, over-permissioned accounts. Credentials get hardcoded and rarely rotated, so one leaked key can open a path to critical systems. And IAM built around job titles and static roles has no equivalent for software that requests and escalates its own access in milliseconds, while approvals still run on a human calendar. Agentic AI doesn't create these problems. It scales them.

The fix starts with discovery: inventory every non-human identity, assigning a human owner to each. Then extend the same discipline already applied to people: least privilege, defined lifecycle, regular certification, revocation in minutes rather than quarters. Treat privileged machine access as a first-class PAM problem: vault secrets, rotate credentials, replace standing privilege with just-in-time access. The controls that govern human identity are the right controls for machines. They just have to be applied before agentic AI closes the window to do it by hand.

And non-human identity is the leading edge of a larger shift. Identity and Access Management is at an inflection point, where AI-driven machine identities, decentralized trust models built on blockchain, and the coming cryptographic disruption of quantum computing all reshape how organizations think about workforce identity, authorization, and governance. Agents and NHIs are the pressure teams feel first. Getting those controls right now is what prepares a program for everything behind them.

In my previous blogs on this I described the risks related to who operates their cloud, who controls the technology, the laws that the service is subject to, whether critical services can continue operating if a supplier becomes unavailable, and whether workloads can realistically be moved elsewhere.

STACKIT has a strong answer to these questions. However, it also illustrates an important reality: sovereign infrastructure does not automatically make a cloud service sovereign.

From German Cloud to European Ecosystem

STACKIT is part of Schwarz Digits, the IT and digital division of Germany's Schwarz Group, best known for its Lidl and Kaufland retail businesses. This gives STACKIT an unusual position among European cloud providers, it developed from the requirements of one of Europe's largest retail organizations.

Schwarz Group remains an important "customer zero." STACKIT supports the applications used by the retail arm ranging from enterprise software to large-scale AI workloads. For example, every night it uses the service to generate more than two billion retail forecasts. In addition, it uses the platforms for AI based computer vision, SAP, ServiceNow, and software development.

This provides STACKIT with both financial backing and a large environment in which to prove its technology. But the requirements of Schwarz Group are not necessarily the requirements of every European enterprise or public-sector organization. STACKIT has used this experience in collaboration with partners to create standardized services that are more widely usable.

Building Out the Ecosystem

One of the clearest messages from Cloud X Summit was that infrastructure sovereignty alone is not sufficient. Customers need applications, data platforms, cybersecurity products, and AI services to operate and grow their businesses.

To support this, STACKIT is expanding its ecosystem through relationships with other enterprise technology providers. These include SAP, ServiceNow, Snowflake and Zscaler alongside European and international AI providers to offer sovereign, open-standard enterprise data analytics, and Generative AI in Europe. This is strategically important to compete in a market where customers continue to depend upon non-EU clouds for higher-level services.

STACKIT is also strengthening its own data and AI capabilities, MLOps, developer services and confidential computing. Hardware-backed confidential computing provides additional protection against access by the cloud service provider to the customer data.

However, STACKIT is not trying to reproduce AWS, Microsoft Azure, or Google Cloud service for service. STACKIT says it wants to maintain a comparatively lean portfolio, and it estimates that this currently addresses around 80% of workloads. However, it acknowledges that individual services do not yet generally match the feature richness of the hyperscalers.

There is merit in simplicity, but it also creates a challenge where many organizations have become highly dependent upon specific hyperscaler capabilities.

Sovereignty and Software as a Service

Organizations want solutions, not just IT infrastructure. This raises a sovereignty challenge when software from a non-European supplier runs on sovereign European infrastructure.

For example, in the case of ServiceNow, STACKIT installs, configures, and runs the software on the STACKIT infrastructure. This potentially provides greater data and operational sovereignty than consuming the same application as a non-EU SaaS service.

But it does not eliminate dependency on ServiceNow. The original vendor still develops the software and supplies future releases, security updates and patches. Locally operating the service can therefore reduce operational dependency, but it cannot eliminate the underlying software supply-chain dependency.

This is not a weakness unique to STACKIT. It illustrates the multi-dimensional nature of sovereignty that is captured by the EU Cloud Sovereignty Framework.

Cloud Migration and Cloud Exit

Another important announcement was the STACKIT Cloud Adoption Framework. Rather than being another collection of cloud documentation, this framework is intended to bring together guidance, reusable assets, tools, training, and partner expertise that help organizations adopt STACKIT and move workloads onto the platform.

This addresses an important but sometimes neglected element of sovereignty: practical portability. It is easy to state that an organization should avoid cloud lock-in.

The hyperscale clouds have well developed tools to support inbound workload migration. Another alternative often proposed is to “modernize” the workload for example by recoding it to use containers. Either option introduces risks and organizations need reassurance that the benefits of the move are worthwhile.

The Cloud Adoption Framework could therefore become an important part of STACKIT's proposition if it makes migration easier. But organizations also need to ask another question: how easily could we subsequently move away from STACKIT?

A sovereign European cloud should not merely replace dependency on a US provider with dependency on a European one. Open technologies, portable architecture, documented interfaces and credible exit plans remain important regardless of who owns the cloud.

From German Strength to European Scale

STACKIT has particularly strong credentials in Germany, but becoming a European sovereign cloud requires more than exporting a German model.

However, public sector sovereignty requirements differ between European markets. Some German public-sector organizations have requirements for data to remain in Germany or even within a particular federal state. The same is also true around the EU where for example, Franch public services have  requirements for SecNumCloud certification.

STACKIT is responding through partners and procurement frameworks rather than attempting to build a direct services organization in every country. This appears sensible, but success will depend on establishing trusted local ecosystems and demonstrating that its definition of sovereignty matches national requirements rather than assuming there is a single European model.

A European Choice

The Cloud X Summit demonstrated how far STACKIT has moved beyond providing basic IaaS. The Schwarz Group provides scale and a demanding customer-zero environment; the service portfolio is expanding; major enterprise software providers are joining the ecosystem; and STACKIT is investing in data, AI, security, confidential computing, and practical cloud adoption.

The EU is an enormous and growing market for IT services and exploitation of AI. STACKIT provides European organizations with an increasingly credible sovereign cloud option. It will not eliminate every technology or supply-chain dependency, nor does it yet match the breadth of the hyperscalers. But sovereignty does not require complete technological isolation. The important question for European organizations is which dependencies they are prepared to accept, which they need to control, and how much they value having a European alternative.

Key Topics:

✅ Orchestration inside the Identity Fabric: capability, not product category
✅ Integration debt: how organizations quietly accumulate orchestration they no longer understand
✅ The Lotus Notes warning: what vibe coding and no-code/low-code get wrong at scale
✅ Why AI can document and test code — but still doesn't understand what it's doing
✅ Start with orchestration strategy, not the tool — and always ask "how do I get rid of this?"
✅ Ownership and governance: who is responsible for orchestration artifacts when people leave?

🪷 "Lotus Notes: a wonderful example of where vibe coding went rogue — organizations ending up with thousands of databases, not knowing who did it, why, or if it's still needed." Sound familiar? Martin Kuppinger on why orchestration governance is non-negotiable.

📅 Join KuppingerCole Analysts at the AIdentity & NHI Impact Day on October 6th in Munich

Virtual machines access storage. Containers communicate with databases. Serverless functions call APIs. CI/CD pipelines deploy applications, and microservices communicate with each other. Increasingly, AI models, inference workloads and autonomous agents are joining this web of machine-to-machine interaction.

Every interaction requires answers to two fundamental questions: What is making the request, and should it be trusted?

This is the challenge of workload identity and cloud-native trust.

The Cloud Has an Identity Problem

Identity and Access Management has traditionally focused primarily on people: employees authenticate to applications, administrators receive privileged access, and customers authenticate to digital services.

Cloud computing has changed the balance. Modern environments contain enormous numbers of non-human identities (NHIs) associated with workloads, applications, APIs, service accounts and infrastructure automation. Industry estimates vary considerably, but studies suggest that NHIs may outnumber human identities by between 20 and 90 times.

More importantly, they are everywhere.

A cloud-native application may involve identities associated with virtual machines, containers, serverless functions, storage, databases, microservices, APIs and CI/CD pipelines. Generative AI adds model endpoints, inference workloads, vector databases and AI agents.

Unlike human identities, these identities may also be created and destroyed continuously as workloads scale, move or disappear. The result is an identity population that is large, distributed, dynamic and difficult to govern.

Cloud-Native Trust Is Fragmented

Cloud providers give organizations powerful identity controls, but they also make workload identity management more complicated.

AWS IAM roles, Microsoft Azure Managed Identities and Google Cloud service accounts address broadly similar requirements but use different identity constructs, policy models and administrative interfaces. This makes consistent workload identity governance across multiple clouds difficult.

Cloud-native infrastructure is also increasingly ephemeral. A traditional service account might exist for years, while the identity associated with a container, serverless function or CI/CD pipeline may exist for seconds.

This creates a fundamental question: How do you establish persistent trust when the workload itself may not be persistent?

The answer cannot simply be to give every workload a long-lived password or API key.

Secrets Are Not Identities

One persistent weakness in cloud-native security is dependence on static credentials.

API keys, tokens and passwords may be embedded in configuration files, stored in repositories or passed between applications. If an attacker obtains one of these secrets, they may be able to impersonate the workload that owns it.

A secret proves possession of a credential. It does not necessarily prove that the entity presenting it is the workload that should possess it.

Cloud-native architectures therefore need to move towards stronger workload identity, where workloads establish what they are and receive appropriate, preferably short-lived, credentials based upon that identity.

This represents an important evolution:

Static secret → managed secret → short-lived credential → trusted workload identity

Secrets management remains important, but reducing dependence on persistent secrets can eliminate an entire category of credential risk.

Establishing Trust Through Workload Attestation

Moving away from static credentials raises another question: How does a workload prove that it really is what it claims to be?

This is where workload identity and attestation become important.

The Secure Production Identity Framework for Everyone (SPIFFE) provides an open standard for assigning identities to workloads across heterogeneous environments. Rather than tying identity to a long-lived secret, a workload receives a cryptographically verifiable SPIFFE identity that it can use to authenticate to other workloads and services.

SPIRE, an implementation of SPIFFE, provides mechanisms for establishing whether a workload should receive that identity. It can attest the node on which a workload operates and the workload itself using evidence from its execution environment.

This changes the trust question from “Does this process possess the correct secret?” to “Can I establish what this workload is and whether it should receive this identity?”

Once attested, workloads can receive automatically issued, short-lived identity credentials. This is particularly valuable across hybrid and multi-cloud infrastructure, where cloud providers use different native identity constructs.

Attestation, however, only establishes part of trust. Knowing that a workload genuinely is Workload X does not determine whether Workload X should be allowed to access a database or modify a cloud resource.

Put simply: Attestation establishes what the workload is. Identity establishes who it is. Authorization establishes what it may do.

Identity Without Least Privilege Is Not Trust

Excessive permissions remain one of the most significant cloud identity risks. Service accounts, workload roles and tokens are frequently given broader permissions than required because doing so makes applications easier to deploy.

A workload that only needs to read objects from one storage bucket should not have administrative access to the cloud account.

The principle is straightforward: a workload should have only the authority required to perform its role, for only as long as that authority is required.

The difficulty is maintaining this principle while workloads, infrastructure and identities continuously change.

There is also the problem of identities organizations do not know about. CI/CD systems can create temporary service identities. SaaS integrations may introduce service accounts. Marketplace applications can create back-end identities with cloud access. Applications may be decommissioned while their identities and credentials remain active.

Discovery and inventory are therefore foundational to workload identity governance. But organizations need more than a list. They must understand the relationships between identities, workloads, credentials, resources and permissions.

Multi-Cloud Visibility Is Not a Single Identity Model

Claims of complete NHI visibility across every cloud should be treated cautiously.

AWS IAM roles, Azure Managed Identities and Google Cloud service accounts are different constructs, and each cloud exposes different information. Some identities are also created indirectly by applications and services rather than appearing cleanly through IAM interfaces.

Ephemeral infrastructure creates another challenge. By the time a periodic scanner looks for an identity, the associated workload may already have disappeared.

A multi-cloud identity security platform can normalize much of this information into a valuable, consolidated view. But a single dashboard should not be confused with a single underlying identity model.

This matters for Zero Trust. “Never trust, always verify” must apply to machine identities just as it applies to humans.

When one service calls another, trust should be based upon verifiable workload identity, appropriate authorization and policy rather than simply possession of a valid credential.

Agentic AI Changes the Equation

AI agents behave differently from traditional NHIs.

Traditional workloads generally execute predefined application logic. An AI agent may decide which tool to use, which API to call, what information to retrieve and which action to take.

Agentic AI therefore changes NHI security from primarily a problem of quantity into one of quantity, unpredictability and control.

Each agent may require its own identity, while agentic workflows may create sub-agents or processes requiring additional identities. Agents also need access to applications, cloud services, data stores and APIs, and their access patterns may change according to the task being performed.

This creates a difficult security question: What constitutes normal behavior for a machine designed to make decisions dynamically?

It also makes least privilege and delegated authority increasingly important. An agent may be technically capable of calling an API, but that does not mean it should be authorized to use every operation exposed by it.

From Workload Identity to Agentic Trust

AI agents introduce another dimension to workload identity: on whose authority is the workload acting?

A conventional application normally operates according to permissions assigned to it. An AI agent may operate autonomously on behalf of a human user.

Organizations therefore increasingly need to understand not only:

Which identity performed this action?

but also:

On whose behalf was it acting?

This can create a chain of trust:

Human user → AI agent → workload identity → API → cloud resource

Every step needs sufficient identity and authorization context to establish who initiated the activity and what authority was delegated. Otherwise, an audit trail may tell us that a token accessed a database without explaining why it happened or whose authority ultimately enabled the action.

This suggests that the principles underlying workload attestation may become increasingly relevant to agentic trust. For a conventional workload, we want evidence of what workload is running and where. For an AI agent, organizations may increasingly need to establish which agent is operating, who instantiated it, which tools and services it can use, what authority has been delegated, and which policies constrain its behavior.

Five Priorities for Cloud-Native Trust

Organizations should therefore focus on five areas:

1. Discover and inventory NHIs across cloud infrastructure, applications, CI/CD, SaaS integrations and AI environments.
2. Reduce long-lived secrets by moving towards short-lived credentials and identity-based authentication.
3. Implement least privilege, continuously aligning permissions with the minimum that workloads need and only for as long as needed.
4. Monitor identity use, correlating authentication and access with workload, application and cloud-resource context.
5. Apply Zero Trust to machines, requiring verifiable identity and explicit authorization for machine-to-machine interactions.

Identity becomes the Cloud Trust Fabric

Cloud-native computing has already forced organizations to think about identity beyond the human user. Applications now consist of constantly changing workloads, APIs, containers and services, each requiring identities and permissions.

Agentic AI accelerates this transition by introducing machine identities capable not only of executing instructions but of making decisions and taking actions.

Organizations therefore need to know what is acting, what it is allowed to do, which resources it can reach and, increasingly, on whose behalf it is acting.

Workload attestation establishes what is running. Workload identity enables it to authenticate. Authorization determines what it may do. Governance constrains how that authority is exercised.

Together, they provide the foundation for cloud-native trust — and increasingly, for trust in the agentic enterprise.

Explore This Live at AIdentity & Non-Human Identity Impact Day 2026

Attestation, identity, and authorization are not just architectural principles. They are the working sessions at this year's AIdentity & Non-Human Identity Impact Day 2026, October 6 in Munich.

Join the in-person conference for analyst insight and practitioner case studies on building this foundation in your own environment.

Register Now  |  See the full agenda

Two Categories of Identity: Human and Non-Human

IAM has traditionally worked with two categories of actors, human and non-human identities. The distinction rests on ownership, lifecycle, and accountability.

A human identity represents a person. The person acts autonomously within an assigned role and holds discretion over how a task is carried out. Beyond technical controls, a person is bound by intrinsic ethics and by the organization itself. Acting against one’s own employer carries consequences. This binding is not perfect. Accidents happen and insider threats exist. The framework of judgment, responsibility and moral accountability still applies.

A non-human identity represents a technical actor such as a service, a script or a scheduled job. Its purpose, authority and decision logic are defined before runtime. A service retrieves a file, calls an API or synchronizes two systems. The implementation may be complex and the environment may change. A predefined process still determines the response. Organizations can therefore document its purpose, limit its authority, protect its credentials and manage its lifecycle.

An AI agent can execute actions and entire workflows autonomously. Its defining trait is that it combines reasoning with operational execution. The same properties create new exposure. Autonomous behavior is difficult to control and AI agents often require extensive system permissions. Furthermore, accountability and governance remain open challenges.

These challenges are not coincidental. They arise because an AI agent does not fit neatly into either category. It combines properties that the two established categories clearly distinguish. Ownership and lifecycle place it among non-human identities. The way it behaves and decides places it closer to a human one. Neither category was designed for an actor that is a mix of both worlds.

Where the Non-Human Label Breaks

The break becomes visible in practice, not just in theory. When Eleni Richter of EnBW spoke at the European Identity and Cloud Conference 2026 about the shift from backup jobs to AI agents, she distinguished deterministic services from complex NHIs that use AI to simulate human behavior. That line is where the classification comes under strain. A conventional non-human identity receives a defined process. An AI agent may receive an objective without a complete path to the outcome. It can interpret information, select tools, evaluate results and adapt its next action. The same objective and the same authority can produce different execution paths, because the decisions are made at runtime.

This is where the agent resembles a human identity. A person also receives an objective and holds discretion over the path. The resemblance ends at accountability. For human identities, organizations rely on approvals, separation of duties and monitoring, and on the ethical and organizational binding that a person carries. An AI agent holds the discretion without that binding. The controls built for non-human identities do not close this gap, because they are static and limited to the deterministic actions those identities were expected to perform.

This leaves the agent in a difficult position. Discretion is present. The internal constraint that would normally limit it is absent. Additionally, the controls available on the non-human side do not extend to the decisions made by the agent. In this respect, the agent behaves like a permanent insider threat, without the intent usually implied by the term.

A Valid Identity Making a Wrong Decision

A short example makes this concrete. It follows an AI agent through a routine finance task and shows both sides of the actor at once.

Consider a finance team that uses an AI agent to process supplier invoices placed on hold. The agent can review supplier records and previous correspondence, and it may release a hold once a discrepancy has been resolved. In ownership and lifecycle this agent is a non-human identity. It was provisioned by finance operations, it has a documented purpose and approved authority, and it can be terminated like any other service account. That is the non-human side, and it is fully in order.

One invoice arrives with bank details that do not match the supplier record. The agent finds an email asking finance to use the new account and treats it as sufficient confirmation. It releases the hold. That is the wrong decision. A single email is not sufficient evidence for a change of bank details.

Here the human-like side takes over. A conventional non-human identity receives a defined process and would have followed a fixed rule, either passing the mismatch on or stopping. This agent instead received an objective and worked out the path itself. It interpreted the email, judged it trustworthy and chose to release the hold. The decision was made at runtime. On another day the same objective could have produced a different outcome. This is human-like discretion, sitting inside an actor that is non-human in every other respect.

This is where the example turns dangerous. A person in the same role holds the same discretion but carries the binding that goes with it. That person might have paused at an unusual change of bank details, aware that a wrong release would be traced back to them. The agent carries nothing comparable. From an access perspective nothing went wrong. The identity was valid and the access was approved. The wrong decision was made inside approved authority, which is what makes it hard to detect.

Are We Solving the Wrong Puzzle?

Clearly, an agent is not a human identity. Nor is it entirely a non-human one. The label 'agent' identifies the actor, but does not express the degree of discretion between an objective and an outcome.

The missing piece may not be another identity type at all. We may be assembling the wrong puzzle. The distinction between human and non-human answers one question and establishes where ownership, lifecycle and accountability reside. However, it does not address the second question of how closely the actor’s decisions must be governed. What separates the invoice agent from a conventional service is not ownership, because both are non-human. It is autonomy. The service follows a defined process. The agent decides at runtime.

The obvious responses fall short. Restricting permissions sets the outer boundary and nothing beyond it. The invoice agent may review a hold and release it. That permission alone does not determine whether release is appropriate in a specific case. Clear instructions do not reach further either, because the agent has to interpret them. When a rule conflicts with an objective, the agent may favor the objective and cross the boundary without malicious intent.

Accountability does not change. Autonomy changes how an action is selected. It cannot transfer responsibility to the agent. Ownership therefore has to cover more than the resources and operations available. It has to cover the decisions the agent may make and the conditions under which it may make them. It is not settled where those conditions belong or who defines them.

Conclusion: An Open Question Remains

Classifying an AI agent as a non-human identity is correct in ownership and lifecycle. It is incomplete as a control profile. The label captures who is accountable. It does not capture how much the actor decides on its own.

An agent can hold a valid identity and approved access and still make a dangerous decision. The discretion is present. The internal constraint that normally limits it is absent. A better identity label does not change that.

However, if agents are non-human in ownership but human-like in discretion, can IAM still govern them on the human versus non-human distinction alone?

Nitish Deshpande, Senior Analyst at KuppingerCole Analysts, presents key findings from the 2026 Leadership Compass on IAG, offering an independent perspective on the current market landscape. He discusses evaluation criteria and leadership positioning and provide guidance on how organizations can align their access governance strategies with business and security priorities.

The threat does not start or end with quantum. For decades, organizations treated cryptographic infrastructure as permanent: algorithms chosen at deployment, embedded across applications and platforms, then forgotten until an audit forced attention. That model no longer holds.

Machine identities now outnumber human users by orders of magnitude. APIs carry the operational fabric of digital business. Cloud-native workloads authenticate continuously. AI agents negotiate trust relationships at machine speed. Every one depends on cryptographic primitives spread across systems, libraries, and hardware that most organizations cannot fully inventory, let alone update on demand.

NIST finalized its first post-quantum standards in 2024, and the conversation has moved from "should we prepare" to "demonstrate readiness." Crypto-agility is the answer: not a product or a one-time migration project, but the organizational and technical capability to adapt cryptographic systems continuously, safely, and at scale.

The Blind Spot Problem

Take identity providers (IdPs). Many organizations treat them as the authoritative inventory of what the business is running. They unfortunately are not. IdPs represent known sanctioned applications and user accounts. An IdP sees federated application access, meaning access that has been registered and routed through it for authentication and SSO. Everything else typically stays invisible to the IdP: local application accounts, personal account logins, marketplace-sourced extensions, and non-human actors such as service accounts and AI agents.

These are growing sources of Shadow IT. A business unit can directly subscribe to a new SaaS application. An individual employee can enable an embedded AI copilot with one click. Neither action goes near a security review or an IT asset inventory.

The Cloud Security Alliance has reported that 56% of organizations see employees uploading sensitive data to unauthorized SaaS applications. Separately, 62% of financial services organizations report they have already deployed AI agents, with 93% of those using agents granting some level of autonomy, but most believing a new agent authorization framework is still required. Discovery relying exclusively on traditional identity provider logs will miss both. The gap is not a rounding error in an otherwise solid application inventory.

Why the Risk Compounds

Discovering an application is not the same as securing it. OAuth grants, API tokens, browser plugins, and SaaS-to-SaaS integrations create trust paths that monitoring and threat detection tools rarely see. Excessive scopes accumulate. Integrations get abandoned but retain their access. Third-party applications often go unreviewed for security and data handling processes. Any one of these can turn a small, low-profile integration into a route for a serious breach.

AI agents raise the stakes further. An agent with delegated access acts at machine speed. Its reasoning path is not deterministic and thus can’t be predicted with certainty. AI agents can execute tasks and move data faster than any human reviewer can. Governance built around annual policy or access reviews cannot keep pace. What is needed instead is real-time operational control: permission analysis, runtime observability, and an auditable record of what an agent did and why.

Further creating risk, applications change security-relevant settings and capabilities regularly, and the defaults are not always set to the safest option. An application configuration that was reviewed and approved last quarter may be operating differently today. And who administers these applications day to day? Often not someone from the IT or security team. Treat posture as a point-in-time check rather than a continuously monitored state, and drift will go unnoticed.

The Solutions Market Is Evolving Quickly

The security market's response has been to move through and past SaaS Security Posture Management (SSPM) for configuration hygiene and drift monitoring. What has emerged is a combined SaaS security and AI governance solution market. These systems cover identity posture, OAuth governance, supply-chain visibility, data exposure management, threat detection, remediation workflows, compliance reporting, and AI agent governance.

Keeping pace with the growing SaaS and AI application scope depends heavily on the security system’s discovery architecture. In response, vendors have built multi-source telemetry pipelines that pull from SaaS applications, browsers, endpoints, identity systems, data stores, activity logs, procurement and ITSM systems, threat intelligence, and AI platforms, correlating all of it. The industry shorthand for this continuously updated, correlated view is an enterprise security graph. This graph turns a pile of disconnected findings into a connected view of the organization’s actual attack surface.

What This Means for Buyers

For anyone building a vendor shortlist or drafting a Request for Proposal (RFP) for solutions in this space, discovery architecture and coverage should be a key element of the evaluation. A tool cannot govern what it cannot see, and coverage gaps in one telemetry source rarely show up until after deployment.

Two other criteria are also important and thus deserve equal weight. Identity governance needs to extend beyond human users to non-human identities and AI agents, each with its own lifecycle and ownership requirements. In addition, runtime controls for production agents need to be real, since a governance policy that only applies before deployment does nothing once an agent is operating. There is more to SaaS and AI governance than these three, but these provide a good foundation from which to start.

Join the Conversation

These findings, along with the full vendor landscape, are the subject of a live webinar on October 7, 2026: “Security at the Convergence of SaaS, AI, and Identity.” This session will cover the central findings of the SaaS Security and AI Governance Leadership Compass and Buyer’s Compass research, identify which capabilities are moving from optional to essential, and point out where market maturity still lags.

Register for the webinar

None of those goals are inherently at odds with the internet. What concerns me is the increasingly common assumption that digital sovereignty somehow replaces the need for interoperability. It doesn't.

If anything, the opposite is true.

The Internet Has Never Required Uniformity

The internet has never depended on everyone making the same policy decisions. It has depended on independently governed systems finding ways to communicate despite making different decisions. That distinction has always been important, but it becomes even more important as governments, industries, and enterprises develop their own trust frameworks.

One of the recurring lessons from standards work is that technical standards are often expected to solve problems that are fundamentally about governance. They can't.

A protocol can define how to exchange a credential. It can define how to communicate metadata or express an authorization decision. What it cannot do is determine whether one government should trust another government's identity system, whether one regulator should recognize another regulator's assurance model, or whether two organizations should accept each other's risk posture.

Those are policy decisions. Standards provide a common language for communicating the outcome of those decisions.

That distinction becomes particularly relevant when people talk about internet fragmentation. The conversation often assumes there are only two possible futures: either everyone converges on a single global approach, or every jurisdiction builds its own isolated ecosystem.

Neither seems especially likely.

Standards Translate Between Trust Frameworks

The internet has always accommodated diversity. Organizations have different security policies. Industries have different compliance requirements. Countries have different legal obligations. Those differences existed long before we started using the term "digital sovereignty." What made the internet successful was not eliminating those differences but allowing systems to interoperate despite them. Federated identity has generally worked on the same principle.

Federation never required every organization to have identical identity proofing practices. Certificate authorities operate under different policies and governance frameworks while using common certificate and validation standards. Even something as familiar as email depends on independent operators applying different policies while using common protocols and message standards.

I've started thinking about standards less as mechanisms for creating uniformity and more as translators between independently governed systems.

That isn't as elegant as a single global trust framework, but it is much closer to how the internet has evolved over the past forty years. We establish common ways to represent information, exchange evidence, and evaluate claims while leaving room for organizations to make their own decisions about what they will ultimately trust.

I suspect this is where identity architecture is heading as well.

Designing for a More Diverse Internet

European initiatives such as the EUDI Wallet are advancing an ambitious vision for cross-border digital identity while operating within a distinct regulatory environment. Other regions are making different choices based on their own legal, commercial, and societal priorities. Sovereignty requirements can create legitimate constraints on data movement, infrastructure, and trust relationships. The objective is not unrestricted interoperability, but sufficient interoperability within clearly defined legal, security, and policy boundaries. Those differences are real, but they are not necessarily  failures of interoperability.

The more interesting question is whether systems designed under different assumptions can still exchange enough information and evidence to make their own trust decisions.

That is where open standards continue to matter.

Interoperability should not be measured by whether every deployment looks the same. It should be measured by whether independently governed systems can understand one another well enough to accomplish useful work without forcing everyone into a single trust model.

Digital sovereignty changes who establishes trust and under what rules. It does not eliminate the need to communicate those decisions across organizational or national boundaries.

If anything, it raises the bar for interoperability. The future internet is unlikely to be less diverse than today's. The real challenge is ensuring that diversity does not become isolation.

In this webinar, Guillaume Teixeron, Senior Analyst at KuppingerCole Analysts will examine the changing authentication landscape and explain why passkeys are emerging as a key component of modern identity security strategies. The session will explore how organizations can reduce authentication-related risks, improve user experience, and strengthen their defenses against phishing-resistant attack vectors.

David Noel-Lardin, Authentication Devices Product Line Director at Thales Group will provide practical insights into the adoption of passkeys, discussing implementation considerations, deployment strategies, and lessons learned from organizations modernizing their authentication environments. The discussion will also look beyond current challenges and explore how organizations can prepare their identity infrastructure for future developments, including the impact of quantum computing on authentication and digital security.

Who Should Attend

This webinar is designed for IAM professionals, CISOs, security architects, identity and access management leaders, authentication specialists, and IT decision-makers responsible for securing workforce and customer identities.

Key Takeaways

• Understand why passwords and traditional MFA methods remain vulnerable to modern phishing and AiTM attacks.
• Learn how passkeys provide a phishing-resistant alternative to legacy authentication approaches.
• Explore the business, security, and user experience benefits of passwordless authentication.
• Discover practical considerations for deploying passkeys across enterprise environments.
• Gain insight into emerging authentication challenges driven by AI-enabled threat actors.
• Understand how organizations can prepare their identity strategies for the future impact of quantum computing.
• Learn how to build a resilient, future-ready authentication framework that balances security, usability, and long-term adaptability.

The 2026 Leadership Compass on Software Supply Chain Security benchmarks the market across source and build integrity, vulnerability and dependency management, secrets and non-human identity governance, package repository controls, and attestation, mapping where vendors lead, where they're acquiring their way to parity, and where the market remains critically underserved.

One finding stands out: platform vendors are closing the capability gap with focused specialists, but attestation remains a weak point across the board. With the EU Cyber Resilience Act, NIST SP 800-218, DORA, and NIS2 raising explicit requirements for provenance evidence and compliance documentation, organisations treating attestation as a future problem are already behind schedule.

Join this webinar to:

• Get an independent view of the 2026 software supply chain security vendor landscape and where the market is consolidating
• Understand which capabilities separate market leaders from the rest, across source and build integrity, dependency management, secrets and non-human identity governance, repository controls, and attestation
• Learn why attestation remains the most underserved capability in the market, despite mounting regulatory pressure
• See how the EU Cyber Resilience Act, NIST SP 800-218, DORA, and NIS2 are raising the bar on provenance and compliance evidence
• Get a practical framework for prioritising investment based on risk exposure, not feature lists
• Software supply chain risk has moved from edge case to boardroom agenda

Berthold Kerl speaks with Michael about what a genuine AI-driven shift in security looks like in practice, beyond the vendor hype. They discuss where AI is already delivering measurable value. From cyber defense enrichment and GRC control mapping to identity access governance, to where the promises are still ahead of the results, including AI-assisted code review and vulnerability discovery.

Michael makes the case that classic disciplines like patching, vulnerability management, and cyber hygiene aren't becoming less important because of AI, but more so, and that the real opportunity for security teams lies in becoming a trusted enabler of AI adoption across the business rather than the "department of no."

The conversation also explores how much trust CISOs are willing to place in autonomous AI decision-making today, what genuinely differentiates AI-native security products from AI-washed ones, and how the skills security teams need are evolving as entry-level work disappears.

Thomas closes with his view that judgment: knowing what to do with what AI produces is the capability that will matter most for the CISOs of the future.

Topics covered: AI and the threat landscape, AI in cyber defense and SOC operations, GRC and control automation, identity access governance, AI washing among vendors, autonomous response and trust in AI, cyber hygiene, security as a business enabler, evolving security skill sets, the future of the SOC, passwordless authentication.

The United Kingdom (UK) and the European Union (EU) each picked one. For most of the last decade the difference looked like a matter of administrative preference. It was hard to judge, because neither model had delivered. Both models now have a delivery record, and in the space of ten months the UK managed to try both.

This post outlines what each has produced by mid-2026, which model the evidence suggests is slower, and what relying parties in both markets should do differently. The answer is not the one most buyers expect.

Two ways to manufacture trust

The UK model treats trust as something you certify. Part 2 of the Data (Use and Access) Act 2025 put the digital verification services trust framework and its register on a statutory footing, commencing on 1 December 2025. The state publishes rules, a conformity assessment body accredited by UKAS audits against them, and providers that pass appear on a public register. The state writes the rules and keeps the register. It does not issue the credential.

The EU model treats trust as something you issue. Under the amended eIDAS framework, every Member State must make a European Digital Identity Wallet available to citizens by the end of December 2026, with the architecture, security requirements, and certification specified centrally.

The interesting question is no longer which approach is more elegant. It is which one actually delivers. On that point, the conventional wisdom has been wrong.

The certification model is reaching the point of sale

The intuitive view is that the UK approach is the slow one: years of alpha, beta and gamma versions, accreditation bodies, conformity assessment, a trust mark. It was certainly slow to start. David Crack, chair of the Association of Digital Verification Professionals, told the Home Affairs Committee in Mandatory to manageable: the government’s plans for digital ID that the framework began in 2008, making the sector “the product of a long-standing cross-party consensus over 17 years.”

But it has compounded. As of 21 August 2026 the register listed 46 providers offering 63 certified services. Version 1.0 of the framework was published on 9 June 2026 and takes effect on 1 September.

More importantly, the framework is about to reach a point that assurance schemes rarely do: an ordinary transaction with legal consequences. On 30 June 2026 the Home Office laid a draft order amending the mandatory licensing conditions under the Licensing Act 2003. It removes the requirement that proof of age carry a physical security feature, such as a hologram. Instead, it permits a licensee to accept digital proof, provided that specific conditions are met. As of 1 September the order was still a draft, awaiting approval by both Houses.

Those conditions are the point, and OfDIA set them out when the order was laid. The provider must be registered, must deliver identification at “at least a medium level of confidence, as defined in the relevant versions of the UK DVS trust framework,” and the check must happen “through secure technological means, rather than someone simply looking at a digital proof of age on a screen.”

Once the order is made, an assurance level stops being an abstraction. It becomes the thing standing between a licensee and a license review.

What the order did not require is as telling as what it did. OfDIA set this out in guidance on 19 August 2026: “The new regulations do not introduce any new certification requirements for DVS providers and do not introduce any additional approval process.” A mass-market transaction with criminal liability attached is being fitted to the assurance framework without building anything new for it. The plumbing is already there.

The same country tried issuance, and stopped

The UK also tried the other model.

In September 2025, the government announced a state-issued digital ID. By the March 2026 consultation, the scheme had already softened: “There will be no legal obligation for people to have or present the digital ID.”

Even more striking, the consultation did not propose an alternative to the certification model. It proposed building inside it. The government intended the digital ID system “to operate within this ecosystem, adopting these standards and safeguards.” It expected the GOV.UK Wallet “to be certified as a DVS.” It stated that “only DVS providers that are certified under a current version of the trust framework and present on the government register will be able to programmatically verify a digital ID presented from the GOV.UK Wallet.”

The state’s own wallet was to be certified under the framework built for private providers.

It did not survive. On 21 July 2026 the programme was cancelled. The public record is thin: the cancellation appears as a line of funding in a Treasury announcement about a VAT cut on household electricity, costed at £1.8 billion over three years. There is no dedicated statement, because Parliament rose on 16 July.

The certification track carried on. Its statutory basis, its register and its September framework date all sit on separate legislation with a separate budget line.

It also outlived the department that owned it. DSIT was abolished on 21 July 2026 and digital identity policy moved to the Department for Digital, Culture, Media and Sport. OfDIA published operational guidance on 19 August and updated the register on 21 August. An assurance regime that keeps working through the abolition of its parent ministry is telling you something about where the durability sits.

The EU is committed to issuance, and still assembling the assurance behind it

The EU cannot make the same choice, because its model is in a regulation with a date attached.

Two pieces of evidence bear on readiness, both from EU institutions. ENISA’s candidate cybersecurity certification scheme for the wallet was still in public review between 4 and 30 April 2026. Member States owe certified wallets by the end of the year. The Regulation fills the gap with national certification schemes, which cover the requirements that European schemes "do not, or only partially, cover". So certification does not depend on the ENISA scheme alone. But a common scheme that was still a draft candidate in the spring shows how much of the shared assurance layer remained unfinished late in the delivery cycle.

The second is the Commission’s own report on the interoperability testing event it ran in December 2025. Of the 11 Member States that brought wallet applications, roughly half used the Reference Implementation, which the report notes means “fewer than one quarter of Member States participated with EUDI Wallet enabled applications.” Its conclusion is direct: “While this suggests that only a limited number of Member States are likely to meet the November 2026 EUDIW deadline, it also demonstrates that the Reference Implementation is effectively supporting early testing, experimentation, and learning, particularly for less mature implementations.”

The same report identifies where the gap sits: “trust infrastructure onboarding remains a weak point,” with “limited use of the trust lists available and incomplete onboarding to the EUDI trust framework.”

That is the mirror image of a register with 46 providers on it. The Commission is careful to limit its own conclusion to countries that attended, and so should anyone quoting it.

What relying parties should take from this

An organization accepting digital identity in both markets cannot run one acceptance strategy.

In the UK you evaluate a certificate held by a provider. The questions are which framework version, which assurance level, which service role, and whether the register entry still stands. In the EU you evaluate a wallet implementation and the Member State behind it, and on the Commission’s own evidence you should expect that assessment to differ sharply between Member States well into 2027.

Two further points follow for identity verification buyers. First, wallet availability is not wallet ubiquity, and IDV demand does not disappear when a wallet arrives, a point I have argued separately. Plan parallel wallet and non-wallet paths. Second, treat certification status as a live attribute rather than a procurement checkbox. Framework versions change, registers move, and in the UK the machinery of government moved in July.

Conclusion

Three things are worth carrying away. Certification models can be slow to establish, but they compound once the infrastructure is in place. The UK experience shows that. The EU experience shows something different: making wallets available does not remove the work of assurance, interoperability and trust-infrastructure onboarding, and the Commission's own testing report documents that work. And the two are not alternatives: the UK scheme was designed to run inside the certification framework, not replace it.

The due-diligence exercise is genuinely different in each market. That distinction belongs in your requirements now, not after December. KuppingerCole’s Identity Verification research and advisory team can help you determine the scope.

Our first approach placed an entire W3C Verifiable Credential inside a QR code. Cryptographically, it was attractive. Physically, it was not. The code was difficult to print reliably and difficult for ordinary phones to scan.

The pilot exposed a larger assumption. Most digital identity programmes begin with a smartphone wallet and treat paper as a fallback. But people may share devices, rely on intermittent connectivity, or access services through an employer, agent, kiosk, or government counter.

A printed, verifiable document reverses the burden. The holder carries paper; the verifier supplies the technology. Identity systems should not fail when a citizen lacks a compatible, charged, connected device.

Why the Timing Is Different Now

The standards have reached a point where this alternative can be designed seriously. The W3C published Verifiable Credentials 2.0 as a web standard in May 2025. CAWG’s Identity Assertion Specification 1.2 was ratified by the Decentralized Identity Foundation in December 2025. C2PA 2.4 also defines mechanisms for retrieving manifests using an identifier, a soft-binding value, or an asset.

This coincides with expanding wallet programmes. KuppingerCole Analysts has examined both what it will take to make the European Digital Identity Wallet a business success and why trust in wallet-based digital identity still has to be earned.

Printed verification should be designed alongside wallets before wallet-only assumptions become embedded in public-sector architecture. The opportunity is a hybrid model: a citizen can use a wallet when one is available and still present a verifiable physical document when it is not.

Identity leaders must decide what the paper carries, how the signed data is retrieved, and which component is trusted to display the result.

How C2PA and CAWG Divide the Trust Problem

C2PA (Coalition for Content Provenance and Authenticity) is best known as the technical foundation for Content Credentials. It assembles signed assertions into a manifest and binds that manifest to a digital asset. The manifest can record what happened to the asset, which ingredients were used, and which hardware or software produced the claims.

CAWG (Creator Assertions Working Group) adds an identity layer. Its identity assertion allows a credential holder to prove control over a digital identity and associate a named actor with selected assertions in the C2PA manifest.

For a government document, that actor could be the issuing authority. A CAWG identity assertion could bind an immigration authority’s organisational identity to the manifest and the claims it endorses. This makes the relationship attributable but does not automatically establish trust. A trust framework must define which issuers and credentials are authoritative for work permits.

Three relationships must remain distinct.

First is issuer authentication: evidence that the claims were authorised by the issuing authority.

Second are the subject’s claims, such as name, permit number, conditions, and expiry. C2PA and CAWG do not define a work-permit data model, so these fields require an application-specific assertion or embedded credential.

Third is presenter-to-subject binding: evidence that the person holding the paper is the person described by it. The manifest alone cannot establish this. A verifier may need to compare a signed portrait, inspect another identity document, or request a wallet-held credential.

C2PA and CAWG can make a document attributable and tamper-evident. They do not eliminate the need to connect issuer, claims, paper, and presenter.

Why the QR Code Should Carry a Pointer

There are two basic QR-code models.

In a payload model, the code contains the signed credential. This can support offline verification when the verifier has the required schemas, keys, and trust material. Its weakness is density, which undermined our pilot.

In a pointer model, the QR code carries a compact identifier or URL. The verifier uses it to retrieve the manifest and validate the signed information. The C2PA Soft Binding Resolution API supports retrieval using a manifest identifier as well as soft-binding values and assets.

The QR code is therefore a discovery reference, not proof. Proof comes from validating the manifest and matching its signed claims to the document.

A pointer keeps the code small while allowing the manifest to contain more information than a practical QR code can hold. Live retrieval can also support current status checks. A revoked permit could fail a later scan when a repository or status service exposes the change and the validator applies the correct policy.

That outcome is not automatic. Resolution requires a defined status mechanism, current status data, and validator behaviour that handles revocation appropriately. A payload can also reference an online status service, although that reduces its offline independence.

The Risks: Copying, Surveillance, and False Verification

A QR code can be copied perfectly. Place a genuine permit’s code on a forged document and it may still retrieve a valid manifest. If verification stops at “the signature checks out,” the forgery wins.

The signed data must therefore be bound to the page’s visible content: the permit number, name, conditions, expiry, portrait, or a canonical representation of those fields. The verifier must confirm that the paper matches what the authority signed. A conventional hash of the original PDF is insufficient because printing, scanning, scaling, and wear change the bits without necessarily changing the meaning.

The human workflow creates another risk. A dedicated validator can retrieve the manifest, validate signatures, evaluate trust, check status, and display the claims. A standard phone camera may instead open a webpage. That page can explain what was found and direct the user to a validator, but it must not become the source of the trust decision.

If it does, a malicious QR code could display an official crest and a green “verified” message without performing conformant validation. Teaching people that “scan and trust the webpage” equals verification would recreate a familiar phishing pattern.

Live resolution also creates a privacy trade-off. Every scan may reveal that a document was checked, when, and potentially where or by whom. The World Privacy Forum’s analysis of C2PA and CAWG highlights risks involving identity, correlation, surveillance, and governance.

For a movie poster, scan telemetry is analytics. For an identity document, it may become surveillance.

What Identity Leaders Should Do Now

Identity leaders should prioritise five decisions.

1. Define the trust framework first. Specify which issuers, certificate authorities, identity aggregators, repositories, and status services are trusted—and for which document types.
2. Separate discovery, validation, and presentation. The QR code locates signed information. The validator performs cryptographic and policy checks. The interface explains the result without treating a webpage or logo as proof.
3. Specify the paper-to-manifest binding. Decide which visible fields are signed, how they are compared with the document, and how photocopies, substitutions, damaged pages, and reprints are handled.
4. Minimise resolution telemetry. Document what the repository logs, avoid stable identifiers where possible, separate status checking from unnecessary tracking, and assess privacy-preserving or distributed resolution.
5. Design for degraded connectivity. Define which trust lists and status data may be cached, how long they remain acceptable, and when a verifier must refuse, defer, or escalate a check.

Digital wallets remain essential, but they should not be the only route to verifiable documents. The printed path works in layers: discovery through the QR code, provenance through the C2PA manifest, attribution through the CAWG identity assertion, and permit data through an application-specific assertion, with the validator applying cryptographic and governance-based trust across all of it. Only the final judgement is human, connecting those claims to the paper, and the paper to the person presenting it.

Public-sector identity programmes should treat printed QR references as a first-class architectural option. The future of digital identity is unlikely to be paper or wallet. It will be a hybrid system that keeps working when one half of it is unavailable.

Key Topics:

✅ Why SSPM is passé — and why SaaS Security and AI Governance belong together
✅ Shadow IT, shadow SaaS, shadow AI: the same problem at increasing speed and scale
✅ Discovery as the foundational capability: you can't govern what you can't see
✅ Where to sniff: browser plugins, email, endpoints, identity providers, and procurement systems
✅ AI agents as a new identity type — and why the controls for humans and NHIs are converging
✅ Market outlook: the AI side is hitting another gear, and acquisitions are coming

🔍 "The majority of SaaS and AI applications are still unknown to the IT and security team." Matthew Gardiner on why discovery is the gating capability — and why most organizations haven't closed that gap yet.

James Naughton argues these two problems are more connected than the industry realizes and that by ignoring frontline workers and IoT at the edge, we've left the hardest identity problems unsolved for decades.

Key questions answered:

The core question hasn't changed: who is trying to access what, and are they entitled?

The hard part is answering it at the very edge of the Fabric.

Key Topics:

✅ AI in software development: from hype to structural baseline — but governance is still improvised
✅ Three tectonic shifts in AppSec: provenance, scale, and non-human identity
✅ Why organizations have industrialized code production but not code assurance
✅ The core question: can you trust AI to verify AI-generated code?
✅ Agent autonomy in production pipelines — the next flashpoint nobody has resolved yet
✅ How regulation (CRA, NIS2, DORA) will settle the provenance argument before the market does

⚡ "We have industrialized code production. We have not industrialized code assurance." Jonathan Care on why the security control set was built for human-authored code moving at human speed — and neither assumption is true anymore.

📅 Join KuppingerCole Analysts at the AIdentity & NHI Impact Day in Munich this October — where the accountability and provenance questions raised in this episode will be front and center.

Oracle has placed a similar bet on application development, and it rests on two layers working together rather than on whatever writes the application. Oracle APEX AI Application Generator is now generally available in Oracle Cloud Infrastructure (OCI) on Autonomous AI Database Serverless as part of Oracle APEX 26.1. It points AI at APEXlang, a new Application Definition Language that is open, documented, and human-readable, and hands the resulting definition to the managed Oracle APEX runtime to compile and execute.

Why Citizen Development Stopped Mattering

For two decades, low-code and no-code platforms were sold on a single claim: writing code is the obstacle, and removing it lets business users build the applications they need. AI can now produce code in any language for anyone able to describe what they want, which leaves the “citizen developer” pitch obsolete.

What remains is the part low-code vendors used to apologize for: the narrow scope, the fixed catalog of options, and the runtime you cannot escape. They are now the only part of the proposition a coding agent does not offer on its own. You can vibe-code a working prototype of a business app over a weekend, but that delivers code and nothing else: no specification, no owner who understands what was built, and nobody accountable eighteen months from now.

Why a Narrow Target Beats a Better Generator

Divers standardize their rigs so that a dive buddy can find the alternate air source in poor visibility. I have had to breathe from someone else's regulator more than once, and it was where the convention put it every time. I still check before every dive, because when I need it there is no time to search.

Code generated into a general-purpose language such as JavaScript or Python is a rig assembled to personal taste: it may work perfectly for the organization that generated it and be useless to anyone else. What you get is an artifact that only one organization in the world runs, with no operational history, no shared validation, and no standard remediation path when something goes wrong. A runtime carrying millions of applications accumulates evidence about what fails and how, and Oracle APEX has been doing that for over 20 years. Such a one-off accumulates nothing and freezes its security posture on the day it was generated, and a better model only produces one-offs faster.

KuppingerCole’s Leadership Compass on Software Supply Chain Security finds that AI-authored code has made provenance and attestation baseline expectations, with attestation still the market's largest gap. Generating fewer unique artifacts is cheaper than proving the provenance of each one.

An APEXlang definition describes intent instead of implementation, so the platform decides which JavaScript library renders a chart and how data access is enforced. Oracle maintains the engine underneath, so an application generated today still runs on a current platform in three years. Your definition stays unique to you; the implementation does not, and the implementation is what carries a security lifecycle. Applications inherit the data-layer controls of Oracle AI Database, which is where enforcement has to sit once humans, services, and AI agents all reach the same data.

Ownership Is Settled Before Anyone Writes a Prompt

Every public statement about this release stays carefully inside Oracle's own ecosystem. The principle underneath is broader, however, because what AI is aimed at determines who owns the result. Aim generation at a general-purpose language and your organization inherits a codebase along with its security lifecycle, permanently. Aim it at a definition language the vendor compiles on a maintained runtime, and you inherit a specification while the vendor keeps the implementation.

Recreational limits keep a great many divers alive, and what they govern is how you dive rather than where: they will not stop you descending on a site nobody researched. APEXlang works the same way, and the protection it does give you is real: compilation rejects definitions that are structurally invalid, while configured data-access controls are enforced at the platform and database layer.

What it cannot tell you is whether the privilege model is correct, whether an embedded AI agent has been pointed at data it should never reach, or whether the business rule it encoded is the rule anyone intended.

An application that calls a model at runtime also inherits the risks covered in KuppingerCole’s Leadership Compass on Generative AI Defense, from prompt injection to unintended data exposure, and no compiler catches those. That is the case for pairing the two, since a definition language necessarily leaves gaps that the database underneath it was built to close.

Oracle's position is unusual because enforcement sits one layer below the definition and holds whether or not the definition is right: Oracle Deep Data Security, Oracle SQL Firewall, and Oracle Database Vault apply policy inside the database, where a privilege model that grants nothing dangerous will stop an agent regardless of what the specification told it to do.

The Low-Code of the AI Era

The limits low-code platforms once treated as an embarrassment turn out to be their most durable asset, and the reason has nothing to do with development speed. A definition language narrow enough to review, sitting on a database that enforces policy whatever the definition says, is what decides in advance what your organization will still be holding in three years.

This is bigger than one product launch. Low-code is being reborn on the very terms it used to apologize for, and other platforms with a runtime worth defending will land in the same place.

If you already run Oracle AI Database, the shift is not an abstraction but a specific reallocation of who is responsible for what. The implementation, the patching, and the security lifecycle beneath your applications become Oracle's problem, and what stays with you is reading the diff before it merges and signing off on what it encodes. The frontier from here is intent, because nothing yet checks that the encoded rule is the one anyone wanted, and that is the space worth watching.

The APEX managed runtime absorbs much of that lifecycle rather than leaving it inside the application the model produced. What you gain is a narrower thing to own: a definition small enough to review, an implementation that stays current without your effort, and an application that will still be readable, supported, and yours to change three years from now. The citizen developer is dead; long live the low-code of the AI era.

How SBB Is Reshaping Enterprise IAM with Policy-Driven Self-Service

When organizations scale their software development, they inevitably encounter a systemic bottleneck: the traditional IAM queue. In modern multi-cloud environments, development and DevOps teams are accustomed to provisioning heavy infrastructure, such as databases, Kubernetes clusters, and streaming platforms, within minutes via automated self-service portals. However, when they require corporate identity integration, application registrations, or Application Programming Interface (API) permissions, progress grinds to a halt.

Historically, these essential IAM resources have been gated behind manual ticketing systems. Because central security teams are often overloaded, a simple permission request can remain unresolved for days or weeks. This creates an adversarial relationship in which security measures act as sources of friction rather than business enablers.

With the rapid growth of Non-Human Identities, including service accounts, workloads, and machine to machine integrations, this tension has only intensified.  Security teams must maintain strict compliance, but building monolithic "gates" will only lead to teams bypassing security altogether.

SBB is one of Switzerland’s largest employers of custom software developers and operates more than 2,000 heterogeneous applications. We recognized that the traditional model was unsustainable and chose to invert the paradigm. By converting corporate compliance rules into code and embedding identity directly into our enterprise self-service infrastructure, we demonstrated that business velocity and robust security do not have to be mutually exclusive.

This blog outlines the architectural blueprint and the strategic shift in responsibility required to achieve automated governance at scale.

The SBB Architecture Blueprint for Identity Fabrics

To deliver IAM resources safely to developers within minutes, an organization must look beyond individual tools and focus on a cohesive architectural framework. Our approach uses a decoupled, four-tier Identity Fabric architecture that isolates the developer from direct backend configurations while maintaining total control.

Self-Service Architecture

• The Consumer Layer: This is the visible interface, the single pane of glass or central portal through which developers interact with the system. Rather than forcing engineers to visit a standalone IAM silo, all identity and credential request capabilities are natively integrated into our centralized enterprise IT portal alongside standard cloud resources. These capabilities are also fully available through Infrastructure as Code (IaC), allowing developers to manage application registrations through Git repositories.

• The Automation Layer: Acting as the operational engine, this layer leverages GitOps workflows and Continuous Integration and Continuous Delivery (CI/CD) pipelines to handle the actual creation, modification, and provisioning of resources.
• The Policy and Guardrail Layer: This is where core governance occurs. Every automated pipeline must pass through a strict policy engine in which compliance rules, conventions, and security checks are evaluated and enforced.
• The Resource Layer: The final backend tier consists of the underlying source systems that the platform manages, including our core Identity Providers (IdPs), API gateways, and secret management tools.

Crucially, this stack is supported by a cross-cutting capability focused on monitoring, logging, and auditability. Every self-service transaction and underlying policy evaluation is recorded in an immutable or tamper-evident form that supports applicable audit requirements. This helps preserve full traceability even when human intervention is removed from routine provisioning.

Guardrails, Not Gates: Codifying Compliance

The operational foundation to automated IAM is translating high-level, abstract corporate directives (Konzernweisungen) into clear, machine-enforceable policies within the guardrail layer. Instead of expecting a developer to interpret a 50-page security policy document, the self-service interface naturally constrains their actions to a predefined, safe corridor.

For example, when a DevOps team requests a new Single Sign-On (SSO) application registration, our automated policy workflow dynamically enforces several core corporate requirements:

1. Unambiguous Ownership: The system requires each application to be assigned immediately to a designated corporate group, binding the identity to a defined responsibility unit.
2. Lifecycle Management: A definitive lifecycle plan and automated notification channels must be established from day one to support regular recertification or eventual deletion.
3. Least-Privilege Enforcement: Permissions must correspond to defined risk profiles, and time-bound constraints must be applied to elevated access requests.
4. Inventory Integration: The system requires an explicit link to our central Configuration Management Database (CMDB), ensuring data quality and mapping data protection risks appropriately.

By embedding these constraints directly into the graphical user interface and API validation processes, compliance becomes a natural outcome of the developer's normal workflow. Developers remain agile because they receive their credentials instantly, often completely unaware of how tightly the underlying governance framework is guiding their actions.

Inversion of Control: Shifting the Burden of Responsibility

Transitioning from tickets to automation requires more than just technical orchestration. It also demands a cultural and organizational shift known as "Inversion of Control".

In traditional enterprise structures, the central IAM operations team serves as the ultimate arbiter of access. When an application owner submits a ticket for a Microsoft Graph permission, the IAM team must interview the requester, manually verify least privilege, and document the justification. By implementing the change, the IAM team implicitly absorbs the long-term risk of that permission.

Under our new paradigm, we shift responsibility back to the natural business owners who understand the application's actual context. For low- and medium-risk permissions, we provide an expansive self-service catalog integrated with a mandatory, legally binding "Terms of Use" interface.

When developers request access to a specific endpoint, they are presented with explicit constraints regarding purpose limitation, least privilege, and confidentiality obligations. Only after checking "I accept" and documenting a clear business justification does the automation layer provision the permission instantly. The central IAM team ceases to act as a bottleneck. Instead, the application owner assumes direct accountability for the risk introduced to their environment.

We have mirrored this exact strategy across our corporate API Management Platform. Publishing an API, subscribing to data streams, and evaluating consumer access tokens are fully decentralized. The IAM department serves as a platform enablement team, building the secure tooling, designing the guardrails, and facilitating the flow, while the actual business units approve or deny granular requests.

Strategic Prerequisites and the Path Ahead

Achieving an automated, trusted identity ecosystem cannot happen overnight. Organizations looking to move away from legacy gating mechanisms should prioritize four foundational prerequisites:

• Total API Coverage: Every IAM resource intended for automation must be manageable through governed, stable APIs.
• Granular Resource Policies: Comprehensive, standardized authorization models must be mapped out for each resource type before automation of the corresponding resource begins.
• Native IT Integration: Organizations should avoid creating a separate "security portal." True adoption only happens when identity resources are available within the primary enterprise development platform.
• Immutable Traceability: Logging and control monitoring must provide evidence that automated decisions align with applicable compliance requirements.

It is important to be transparent about the implementation maturity. At SBB, our journey is ongoing. Automating most low-risk permissions has significantly reduced the workload of our operations teams, but highly critical resources still require manual workflows. Furthermore, we are actively working toward a unified "Policies as Code" dashboard to provide corporate management with holistic compliance Key Performance Indicators (KPIs).

Ultimately, an enterprise Identity Fabric must not sit in isolation. It serves as the vital connective tissue of the broader enterprise IT Fabric. Aligning IAM directly with overarching corporate IT strategy and business processes ensures higher visibility, smoother audit cycles, and optimal funding. By trusting automation driven by correct, codified policies, security teams can finally scale governance alongside the business, and sleep soundly at night.

Recorded at Deutsche Telekom in Bonn, Berthold Kerl speaks with Thomas about what a 360-degree view of cybersecurity means in practice. They discuss why employees should be seen as a first line of defense, how seemingly insignificant supply-chain dependencies can become critical security risks, and why Europe’s growing regulatory burden can create its own operational challenges.

The conversation also explores operational and data sovereignty, the security implications of AI agents and digital identities, and why organizations should take a more measured view of the quantum threat. Thomas argues that the real challenge is often not the technology itself, but understanding dependencies and gaining transparency across an increasingly interconnected threat landscape.

Topics covered: 360-degree cybersecurity, modern threat landscape, human factors, supply chain security, geopolitics, NIS2 and DORA, operational sovereignty, data sovereignty, AI agents, non-human identity, quantum computing, physical security, regulatory complexity.

Almost every organization breached through its AI estate had failed to extend to its AI systems the control discipline the identity industry has spent decades building.

It is tempting to read those organizations as careless. More likely, the architecture most enterprises now call an Identity Fabric has simply never been tested by an actor that behaves like an AI agent. Agents are the first identity population your fabric was not designed for, and they will find every seam in it.

This post makes three arguments: that "non-human identity" has stopped being a single governable category, that agentic AI separates designed fabrics from accreted ones, and that identity is necessary but not where this gets decided.

"Non-human identity" stopped being one thing

The term did real work. It marked off a population that behaved nothing like human users: cloud workloads, ephemeral containers, service accounts, IoT devices, machine-to-machine traffic. Then AI agents arrived, and the population split.

The exact multiple varies by source. KuppingerCole Analysts puts machine identities at more than 50 for every human; Palo Alto Networks' 2026 Identity Security Landscape report puts it at 109 to 1, up from 82 to 1 a year earlier, and attributes the increase to AI agents rather than to growth in the older population of service accounts and workloads. Other published estimates range from 17:1 to 144:1 depending on how much of the estate gets counted, but none of them puts the older, non-agent population anywhere near a majority of the total.

Palo Alto's own breakdown makes the point directly: of the 109 machine identities per human, 79 are AI agents. That is the figure worth sitting with. Treat it with some care, since a census counting everything marketed as an agent will overstate how much of the population is genuinely autonomous, but even a conservative reading puts AI agents at most of the non-human estate already.

The useful cut runs along autonomy, not humanity. As Alexei Balaganski argues in From Identity to Access, dependent identities such as workloads and devices act only as extensions of the system that owns them. Autonomous identities act on their own behalf within a delegated mandate, which puts them closer to a privileged human than to a workload.

The two classes fail differently. Dependent identities fail through scale and credential sprawl. Autonomous identities fail through missing accountability and unbounded blast radius. A governance model tuned for the first leaves the second largely uncovered.

Agentic AI separates designed fabrics from accreted ones

Most organizations that say they have an Identity Fabric have not built one. They have accreted one: an IGA platform here, a PAM tool there, three IdPs from three acquisitions, a secrets manager the platform team bought quietly, and integrations that hold as long as nothing moves fast.

That arrangement survives human users because humans are slow. A person authenticates once, works at human speed, and generates access requests a review board can plausibly inspect.

Agents remove the cushion. A single high-level task spawns dozens of sub-actions across multiple systems at machine speed, and agents delegate to further agents as they go. Every seam becomes a place where accountability is lost, faster than anyone notices.

This is where the Identity Fabric earns its keep or fails to. A fabric is a deliberate capability model with governance attached, not a diagram drawn after the fact to explain what procurement happened to buy.

Two sessions at Identity Fabric Impact Day 2026 in Cologne address this question directly. Matthias Jarka of WACKER opens with "Steering Identity as a Fabric," on how WACKER structures, evolves and actively governs its IAM: the operative word is actively. Marco Venuti, Field CTO at SGNL, follows with the orchestration toolbox and the adoption patterns separating organizations that have moved from integration to orchestration from those still wiring point to point.

Identity is necessary, not sufficient

Knowing who or what is acting solves very little of the security problem on its own, because the risk lives in what the actor is permitted to do. Balaganski's conclusion is that access, not identity, is the control point, and that enforcement belongs at the resource: the API, the service, the database where the action lands. Authorization at a gateway is coarse, and authorization left to an agent's own instructions is not authorization at all.

Three consequences follow.

• An API key is a secret, not an identity. Conflating entity, identity, account, credential and access is the most consequential mistake in the current vocabulary, and it is baked into many products that operate at one layer while carrying the name of another.
• Every account traces to an accountable owner. Attestation proves only that the thing presenting a credential is the thing that was enrolled. It never proves the enrollment should have happened.
• Pre-scripted access does not hold. Autonomous actors combine permissions in unplanned sequences and pursue intermediate steps nobody wrote down, which forces continuous evaluation, in context, at the moment of action.

Anmol Singh, Director and Global Head of IAM at Olympus Corporation, takes this on with a session on evolving the fabric for autonomous identities through delegation, governance and runtime authorization. Jonathan Neal, SVP and Field CTO at Saviynt, pushes further with "From Identity Fabric to AI Control Plane." Both are the right argument to be having; neither has a settled answer yet.

What to build, rather than what to buy

The vendor market is moving faster than the control problem is understood. My own advisory note, Navigating the Agentic AI Security Landscape, maps six categories across prevent, observe, detect/respond and govern, split into three procurement tracks with different buyers and budgets. Buying from the wrong track is a common and expensive error.

Architecture before procurement

In From AI Agents to Trusted Digital Workers, Martin Kuppinger sets out four pillars for governing agent identities: registration and lifecycle management, multi-tier authorization, governance and oversight, and auditability with provenance. The paper sequences them across three horizons, separating what enterprises can do now from what waits on standards that have not stabilized yet.

None of the four requires a new product category to begin. Registering agents as first-class identities with named owners is a lifecycle exercise your IGA platform can already model, badly at first. Establishing that every agent action resolves to an accountable human takes a policy decision, not a product. Both are unglamorous, and both are prerequisites for whatever the runtime authorization vendors sell you next year. Ownership is the harder gap: governance that belongs to no named team defaults to the platform teams shipping the agents, the one group with no incentive to constrain them.

Which is why Matthias Reinwarth closes the day with "The Fabric Is Not the Deliverable: What You Build on Monday." The fabric is the means. The governed access is the outcome.

The takeaway

The non-human category has split, and autonomous identities need a governance model closer to privileged human access than to infrastructure. And identity is the prerequisite, not the control point: enforcement has to reach the resource.

Identity Fabric Impact Day 2026 takes place on September 9 at the Hilton Cologne. It is a single day built for the people who own this problem rather than describe it. Register here, and come prepared to argue.

Key Topics:

✅ Anthropic's multi-agent experiment: three Claude instances, one codebase, unexpected outcomes
✅ Why coordination does not emerge naturally from intelligence — in agents or in humans
✅ The anthropomorphism trap: why comparing agents to dogs, kids, and wizards is useful but dangerous
✅ Social pressure, mechanisms, and the open research problem of agent cooperation
✅ Risk tolerance as a prerequisite for any agentic architecture — and how to define it
✅ Why correlated agents without coordination break your redundancy and business continuity assumptions

🤖 "If agents are highly correlated but lack coordination, redundancy does not provide the risk diversification we would expect." Jonathan Care on why multi-agent systems are a different beast and why CISOs need to treat them that way.

📅 Join KuppingerCole Analysts at the AIdentity & NHI Impact Day on October 6th in Munich where many of the open questions raised in this episode will be on the agenda

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