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 

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

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

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

AI Agents Create a Different Visibility Problem

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

Shadow AI Is Being Driven by Shadow Agents

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

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

Why Traditional Asset and User Inventories Are Not Enough

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

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

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

What Continuous Agent Discovery Must Provide

Effective agent discovery should provide five essential capabilities:

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

From Discovery to Governance

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

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

Visibility Precedes Observability

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

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

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

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

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

First, a reset: the protocol is not what failed

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

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

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

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

So what did that produce in practice?

What actually broke

Among the 103 sites tested:

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

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

Why this keeps happening

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

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

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

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

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

What this changes for buyers, starting with me

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

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

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

Questions worth adding to a passkey evaluation

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

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

The bottom line

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

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

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

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

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

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

Inventory Is the Foundation

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

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

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

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

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

Build a Living System of Record

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

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

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

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

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

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

Start With Workload Identity

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

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

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

Use SPIFFE IDs and SVIDs

SPIFFE offers a compelling model for workload identity.

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

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

An enterprise might use an identifier such as:

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

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

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

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

Preserve Dual Attribution

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

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

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

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

Assemble What You Already Have

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

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

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

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

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

Put Authorization Inside the Agent Loop

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

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

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

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

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

Planning can be probabilistic. Enforcement must be deterministic.

Make Delegation Explicit

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

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

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

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

Agentic identity should be built around delegation.

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

Begin With a Minimum Viable Architecture

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

A practical minimum viable architecture can begin with:

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

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

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

Start by Assembling

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

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

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

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

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

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

 Watch this Analyst Chat for the full argument.

Key Topics:

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

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

What Happened

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

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

Our Take

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

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

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

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

The Price Is the Story

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

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

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

Where This Deal Will Be Won or Lost

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

What It Means for the Market

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

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

What Comes Next

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

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

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

Recommendations

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

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

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

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

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

Privilege Becomes Dynamic

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

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

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

Rethinking Standing Privilege

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Audit Findings Return Despite Process Changes

What is happening?

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

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

What should be diagnosed?

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

Where should organizations start?

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

2. Access Reviews Complete Without Meaningful Decisions

What is happening?

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

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

What should be diagnosed?

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

Where should organizations start?

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

3. Exceptions Lack Clear Decision Authority

What is happening?

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

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

What should be diagnosed?

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

Where should organizations start?

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

4. Applications Are Connected Without Defined Ownership

What is happening?

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

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

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

What should be diagnosed?

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

Where should organizations start?

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

5. Lifecycle Automation Compensates for Poor Source Data

What is happening?

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

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

What should be diagnosed?

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

Where should organizations start?

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

6. Provider SLAs Are Green While Control Outcomes Are Not

What is happening?

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

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

What should be diagnosed?

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

Where should organizations start?

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

Outsourcing execution does not transfer accountability for IAM effectiveness.

7. Manual Processes Break End-to-End Control

What is happening?

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

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

What should be diagnosed?

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

Where should organizations start?

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

Start with One Capability

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

For the selected capability:

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

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

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

Technology Still Matters, Within the Right Organization

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

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

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

Continuing the Journey

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

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

Key Topics:

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

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

Key Topics:

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

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

Figure 1: KuppingerCole Reference Architecture highlighting IGA-related capabilities

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

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

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

Identity Data Correlation and Continuous Reconciliation

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

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

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

Lifecycle management needs to cover wide range of identity types

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

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

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

Governance is shifting to continuous evaluation

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

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

Access intelligence is becoming the real differentiator

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

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

What’s next for IGA

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

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

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

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

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

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

Your Best Defense Was Nobody Bothering

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

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

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

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

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

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

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

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

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

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

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

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

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