While much of the cybersecurity conversation has focused on how to authenticate AI agents, experts warn that organizations risk repeating a familiar mistake: creating yet another identity silo instead of solving the broader identity problem.
As AI agents increasingly access enterprise data, call APIs, and act on behalf of users and systems, identity strategies built around separate architectures may add complexity rather than strengthen security.
Q1. How can organizations secure AI agents without creating another fragmented identity architecture that ultimately makes the attack surface harder to manage?
Media Partner
By recognizing that agent identity is not a new problem, and that treating it as one is what produces the fragmentation.
For thirty years, identity has meant the user. That was always incomplete. Identity online is three things at once—the actor, the platform it runs on, and the conditions that make the action legitimate at that moment. The industry built for the actor and left the other two implicit, and it worked well enough because a human stood behind the assumption. There was a person, on a device you could mostly reason about, who would eventually notice something wrong.
An agent removes all of that. No person, no assumed device, nobody to notice. The two terms that were carried implicitly now have to be stated, because nothing else is holding them up.
A useful way to see how incomplete the old definition is: a user on an untrusted device cannot be an identity you give access to. The user is the same either way. What changed is the platform, and the old definition has no place to put that.
So, an agent doesn’t need its own identity system. It needs the definition of identity to be correct. Apply the full one—actor, platform, and conditions bound together—and an agent is simply another value in the first term. The actor changes; the architecture doesn’t.
That is also the test of whether a definition was right in the first place. A correct one absorbs a new kind of actor without a new stack. If yours needs a new system every time a new actor shows up, the problem was never the actor.
One boundary worth naming. An agent doing something harmful on its own is a different problem—that’s model behavior and governance, not identity. What identity answers is narrower: is this the authentic actor, on the authorized platform, with its conditions holding right now?
Q2. In what ways could giving AI agents access to enterprise data, APIs and critical workflows fundamentally change how organizations need to think about authentication and trust?
Less changes than people expect, and the part that does change is not the part being discussed.
What you have to defend against has not changed. A stolen credential is stolen the same way regardless of who steals it. A hijacked session is hijacked by the same mechanism. There’s no new class of attack here—there’s the existing class, arriving faster and in volume. The need itself is unchanged: you have to defend against these attacks effectively, and you had to before.
That doesn’t mean carry on with what you have. It means the opposite.
Two assumptions have been holding up the current defensive stack, and neither was ever a statement about the architecture being sound. Both were statements about what an attacker could afford.
The first is time. Detect the anomaly, raise the alert, have someone look, revoke the credential—every step in that sequence was budgeted against attacks moving at human speed. At machine speed, the budget is gone.
The second is reach. An attacker had to choose what to probe, so most weak configurations were never reached. Not because they were defended, but because nobody got to them. Automate the attacker and everything gets probed—every host, every endpoint, every stale service account, every misconfiguration you know about and haven’t prioritized. The weak spot that survived on obscurity stops surviving.
So, the requirement is unchanged, and the method has to change substantially. The direction that holds up under both pressures is prevention rather than reaction—settle the question before the transaction rather than examining it afterward. If a credential cannot be copied off the machine it lives on, speed doesn’t help an attacker who has to steal it first, and reach doesn’t help either, because there’s no configuration to find where the credential is sitting somewhere it can be taken. That property doesn’t weaken as the attacker gets faster or broader, because it never rested on either.
The other thing that changes is that there is no human at the keyboard. Nearly every control shipped in the last fifteen years assumes a gesture somewhere—approve the prompt, type the code, show your face. An agent can’t do any of it. That doesn’t change what you need. It removes what you were leaning on instead.
And it removes the reason the token existed in the first place. We issue a credential that stands in for the user for hours because you cannot ask a person to authenticate on every request—the token is a remedy for human friction. A machine has no friction to remedy. A signature inside the handshake costs nobody’s attention, so there is nothing to amortize and no reason to issue a stand-in that outlives the check. The agent stack brought the remedy anyway, without the problem it was there to solve.
Q3. Why is adding another identity platform for AI agents potentially a short-term fix that could create a much larger long-term security problem?
Because you don’t only get another platform. You get another seam, and seams are where things fail.
To be fair about where this is and isn’t happening: the standards work is mostly not building separate systems. OAuth, OpenID Connect, and workload identity are being extended to cover agents rather than replaced, and NIST’s own concept paper on agent identity starts from whether existing standards can be adapted and answers that they can. The separate systems appear at the product layer—agent inventories and non-human identity consoles bought alongside the directory that is already there.
That is where the seam gets built. The new system has to be mapped onto the ones already in place: which agent belongs to which human, which entitlements carry across, who removes the agent’s access when that person leaves. Those mappings get built under deadline, and they drift. An agent usually gets its access by copying a human’s entitlements at the moment it’s provisioned—copied, not derived. From then on, the two move apart. The employee changes role, and their own access is adjusted; the agent keeps the old scope, because nothing links them. The employee leaves, and joiner-mover-leaver runs against the directory, and the agent isn’t in it.
Ask your own team a plain question: for any agent running today, who does it act for, who approved it, and what happens to it at five o’clock on that person’s last day. In most organizations, someone has to go and look, and often the answer is that nothing happens at all.
Then there is what the platform will be built on. It’s worth knowing what’s under the hood here, because the marketing language is fairly uniform and the engineering isn’t.
Two paths are in use, and they are not equivalent. The one the agent stack reached for first is OAuth. The Model Context Protocol’s authorization specification puts the agent through an OAuth 2.1 flow—an authorization server issues an access token, and the agent presents that token on later requests. That is the human web’s model applied to a machine actor. New way of connecting, old way of proving.
The other path is workload identity—SPIFFE (Secure Production Identity Framework for Everyone) and its implementations. To SPIFFE an agent is just another workload, which is the right instinct. Worth knowing that SPIFFE issues identity in two forms: a certificate used in mutual TLS, and a bearer token for cases where a certificate isn’t practical. Its own specification treats the certificate as the form suited to securing communication between processes. The token is the fallback.
In the SPIFFE deployments I have seen running in production, hardware is used to attest at join: prove which host this is, at the moment the credential is issued. The key that then signs each handshake is software, held in memory, protected by the credential being short-lived and constantly reissued.
That’s a defensible engineering choice, and I’d rather praise it than pick at it. But it is not the same thing as the signing key living in hardware, and vendors sometimes describe both as “hardware-backed.” Two consequences follow, and neither is hidden—they’re just not usually stated. The model needs continuous reachability to whatever issues the credentials. And its security is a function of how short the lifetime is, which narrows the window rather than closing it.
A lifetime is a guess about the future. Shortening it makes the guess smaller, not correct.
So, a new agent platform is likely to be a second copy of the model you already have, with a new set of joins holding it on. That’s the long-term problem: not the platform itself, but that it preserves the incomplete definition and adds maintenance to it.
Q4. How does WinMagic’s approach to a common trust architecture differ from solutions that create a separate identity layer specifically for AI agents?
We didn’t add a layer, because the architecture doesn’t change when the actor changes.
MagicEndpoint puts the identity work on the endpoint. The user signs in to the device once, with real MFA (Multi-Factor Authentication). From then on, the device holds a key in its TPM (Trusted Platform Module) bound to that verified user, that machine, and the conditions policy requires. When the device talks to a server, that key is used directly in the mutual TLS handshake, so identity is asserted inside the transport layer itself. There is no separate login event afterwards, and no token issued that anyone can steal. For an agent, the actor slot takes the workload instead of the person; nothing else moves.
The concrete difference shows up where the network isn’t reliable—plants, vehicles, remote sites, air-gapped facilities. Agents are moving into operational technology, transport, field service and defence, and this is where the reissue model runs into a wall. If a credential is valid for minutes and is renewed by a service the site can’t always reach, the agent stops working. Operational environments are availability-first—a plant that halts is a real cost, sometimes a safety event—so the compromise is predictable. The lifetime gets stretched. Minutes become hours, hours become a shift, and eventually you have a long-lived credential with extra machinery around it. Nobody set out to build that; it’s what the constraints produce.
The question for anyone deploying agents off the corporate network is simple: what is the credential lifetime after the pilot, once operations has had its say?
Our key stays valid without contacting an issuer, because validity comes from conditions the machine checks locally rather than from a fresh grant arriving over the network. That’s what makes disconnected operation work rather than degrade into a long-lived secret.
I’d also be straight about where the line is. The human-and-device half is in production now, alongside existing SAML (Security Assertion Markup Language), OIDC (OpenID Connect), RADIUS (Remote Authentication Dial-In User Service) and LDAP (Lightweight Directory Access Protocol)—it doesn’t replace an IdP (Identity Provider); it gives the IdP a better identity to work with. An agent running in the cloud on behalf of a human somewhere else is genuinely open, and I’d distrust anyone who tells you otherwise. We’re taking that through the standards process rather than announcing it as a product category. Our draft on condition-bound credentials is in the IETF’s WIMSE working group.
Q5. In what ways does WinMagic’s MagicEndpoint evaluate the security conditions surrounding an identity or AI agent at the point of access, and how does that information influence the trust decision?
The conditions are evaluated on the endpoint, by the endpoint, continuously—is the verified user still present, is the device in the state policy requires, is the OS session still live, does posture still pass, is this the application and context policy allows.
That evaluation isn’t a report the endpoint sends somewhere. It’s wired into whether the key can be used at all. The key sits in the TPM under a policy and is available only while the conditions hold. Conditions hold, the key works. A condition fails, the key is not there to use. We call it a Live Key.
Which means the trust decision at the server is barely a decision. The handshake either completes or it doesn’t. If it completes, the user was verified, present, on that machine, with conditions holding at that instant—because otherwise it could not have completed. If encryption is possible, trust is verified.
It also changes what revocation means. When the user locks the screen or the device falls out of posture, nothing has to travel: the key is gone, and access ends with it. There’s no window between the condition failing and a message arriving, because there is no message. Revocations that originate elsewhere—a role removed, an agent withdrawn—come over a real-time signal channel and degrade gracefully when the endpoint is offline.
The reason this has to sit on the endpoint is simple. Whoever judges the condition has to be the one who can end the access, and both have to happen in real time. A server can check a signature, because the signature is in the message. It cannot check whether the machine at the other end is still sound, or whether the person who authorized the task is still there—that state is not in the message and cannot be put there. The endpoint is the only party present for the whole of it.
For anyone evaluating this space, three questions separate the approaches quickly. When conditions fail, does the credential stop working, or does it only stop being reissued—because the second means the credential in flight runs to expiry, and that’s the window an attacker operates in. Where does the key that signs each transaction actually live, not the key used at enrolment? And what happens when the human the agent acts for goes away in the middle of a task? A good vendor answers all three straight.
Where to start is narrower than the architecture suggests: agents running on managed endpoints, with the user present. That’s a large share of early enterprise agent work anyway, and it doesn’t require solving delegation across a network first. The endpoint already verified the user, already knows the device state, already has the hardware to hold a key. Use what’s there.
About Thi Nguyen-Huu:
Thi Nguyen-Huu is the Founder and CEO of WinMagic, which he started in 1997. Three decades in endpoint encryption and pre-boot authentication have grown into a broader mission: secure online access with no user action, built on the endpoint as the anchor of identity. He contributes to identity and credential work at the IETF and W3C. He can be reached on LinkedIn at https://www.linkedin.com/in/thinguyenhuu/
About WinMagic:
WinMagic’s mission is to secure the digital world through high standards and strong ethics. For more than two decades, the organization has led innovation in encryption and endpoint security. Today, WinMagic is advancing a new paradigm for online access—anchoring the endpoint as the foundation of trust. By letting endpoints speak for users, WinMagic turns cumbersome logins into seamless, automated exchanges. What was once user-to-machine communication now becomes a machine-to-machine relationship, governed by policy and anchored in cryptography. This evolution eliminates friction, reduces risk, and lays the groundwork for the Secure Internet—where security is continuous, effortless, and requires no user action. Learn more at https://winmagic.com/en/home/.
