The shift we’ve been missing
For the past two decades, identity has largely been viewed as a gatekeeper. A user logs in, presents a password, an OTP, or a biometric, and the system decides whether to grant access. Once authenticated, most applications assume the user’s identity remains valid for the duration of the session.
That assumption worked reasonably well for traditional software because applications were mostly passive. They responded to explicit user requests, and the user remained directly in control of every significant action.
AI changes that model.
Increasingly, AI systems don’t just answer questions. They summarize documents, retrieve sensitive information, approve workflows, execute transactions, generate code, interact with APIs, and coordinate across multiple enterprise systems. In early enterprise deployments, AI agents are already beginning to make decisions and perform actions on behalf of users.
At that point, identity is no longer just about who logged in.
It becomes the foundation for determining who is asking, who is acting, who is being represented, and whether every action should be trusted.
Identity becomes infrastructure.
AI changes the architecture
Imagine an enterprise AI assistant connected to:
- HR systems
- Banking platforms
- Customer records
- Identity databases
- Internal APIs
- Government registries
A user types:
“Update this customer’s address.”
The language model may correctly interpret the instruction. But before any update occurs, the system still has to answer several questions:
- Is this person genuinely who they claim to be?
- Are they authorized to modify this record?
- Is the request consistent with their normal behavior?
- Has the session been hijacked?
- Is the instruction safe to execute?
- Should additional verification be required because the action carries higher risk?
None of these are language model problems. They are identity and trust problems. As AI systems gain more autonomy, those questions move from the edges of the architecture to the center.
Authentication is no longer enough
Many identity systems are designed around a single event: login.
But AI stretches the boundaries of a session. An AI agent may remain active for hours, perform dozens of actions, access multiple systems, and interact with sensitive data long after the initial authentication.
That changes the problem from:
“Can this user sign in?”
to:
“Can this action be trusted right now?”
The answer may change throughout the session. A device could become compromised. A request could deviate from normal behavior. A high-value transaction might warrant additional verification. A delegated AI agent might attempt an action the user themselves never explicitly approved.
In AI-enabled systems, trust is continuous, not one-time.
Identity moves closer to the core
Traditional enterprise architectures often treat identity as a supporting service:
Application
│
Authentication
│
Database
AI-driven systems require a different way of thinking:
User
│
Identity & Risk Engine
│
Policy Decision Point
│
AI Agent
│
Enterprise Services
│
Audit & Observability
The AI does not become the first component in the request path. Identity, risk evaluation, and policy enforcement do.
This shift reflects a broader architectural principle: before an intelligent system decides what to do, it must first establish whether it should act at all.
It also pushes identity in the same direction that logging, monitoring, and messaging have already moved — out of individual applications and into shared platform infrastructure. Reinventing trust controls per application does not scale, and it does not survive contact with regulators.
The engineering trade-offs
Treating identity as infrastructure introduces real architectural cost.
Continuous verification strengthens security, but it increases latency and operational complexity. Risk-based authentication reduces user friction, but it requires robust telemetry and carefully calibrated decision models — and a wrong calibration is felt either as fraud losses or as legitimate users locked out. Centralizing identity simplifies governance, yet it also raises the importance of resilience and availability, because more services now depend on a common identity platform. A five-minute identity outage in a centralized model is no longer a login inconvenience — it is a platform-wide stoppage.
These are engineering trade-offs, not just security decisions. Designing the identity layer therefore requires the same architectural discipline applied to other critical platform services.
What the rest of the industry is doing about this
None of these architectural questions are settled. What is striking, though, is how much movement there has been across regulators, standards bodies, identity vendors, and national governments in just the past twelve months. Several distinct patterns are emerging.
Standards bodies are working out how to extend identity for agents. In February 2026, NIST’s Center for AI Standards and Innovation launched its AI Agent Standards Initiative, and the National Cybersecurity Center of Excellence published a concept paper on AI agent identity and authorization. The framing is notable: rather than invent new protocols, NIST is asking whether existing standards — OAuth, OpenID Connect, SPIFFE — can be extended to cover AI agents. The hardest unresolved problem the paper flags is multi-hop delegation. Today’s OAuth handles a human delegating to an agent reasonably well. The problems start when Agent A spawns Agent B that calls Agent C, and the trust chain has to survive every hop. That is the hard architectural problem the next few years will be defined by.
Regulators are making non-disclosure of synthetic content illegal. Article 50 of the EU AI Act introduces transparency obligations requiring AI-generated and substantially manipulated content — including deepfakes — to be disclosed and made machine-detectable. The obligations are scheduled to become enforceable in August 2026, though specific deadlines remain subject to ongoing legislative adjustment as of mid-2026. The signal for identity engineers is the direction of travel: the regulatory environment is shifting from “verify the user” to “verify the user, verify the content, and prove which AI was involved.”
Platform vendors are racing to make agents first-class identities. Microsoft’s Entra Agent ID and Okta’s Identity Security Fabric, with its Cross App Access protocol announced at Showcase 2026, are both attempts to give AI agents the same identity primitives humans have — named owners, scoped and short-lived permissions, lifecycle management, and audit trails. Both vendors are betting that organizations cannot keep treating agents as anonymous service accounts at scale. Industry survey data supports the bet: a March 2026 Cloud Security Alliance and Strata Identity survey of 285 IT and security professionals found that only 18% of security leaders had high confidence that their current IAM infrastructure could handle AI agent identities, and 84% doubted they could pass a compliance audit focused on agent behavior or access controls.
Governments are designing identity and AI governance as one stack. Singapore is perhaps the clearest example. Singpass, the national digital identity, covers the vast majority of Singapore’s adult citizens and permanent residents, with face verification available for high-risk authentication. Alongside it, Singapore runs AI Verify, a testing framework for AI systems, and the National AI Strategy 2.0. The point is the combination: identity infrastructure, biometric assurance, and AI governance are being designed as a single stack rather than three separate workstreams. That coherence is increasingly the model other nations look to.
Workload identity standards are being repositioned for AI agents. SPIFFE — originally built for service-to-service authentication in microservices — handles short-lived cryptographic workload identity at scale, without long-lived shared secrets, using dynamic attestation. Several engineering leaders at Identiverse 2026 argued the same model applies directly to AI agents: an agent, fundamentally, is a workload doing math, and the discipline of dynamic attestation, short-lived credentials, and named ownership ports over.
The pattern running through all of this is the same: identity is being rebuilt as the substrate that AI sits on top of, not as a feature that AI calls into.
What this means for digital identity companies — including us
It would be dishonest to claim that any single identity company, including SEAMFIX, has fully solved the problem this article describes. Almost nobody has. The standards are still being drafted. The platform vendors are still in early product cycles. Even the largest enterprises, according to recent industry surveys, are operating without a defined owner for agent identity in their own environments.
For organizations like ours, that is both the challenge and the opportunity.
The challenge is that the scope of “identity” is expanding in ways our existing products were not originally designed for. Verifying a human at onboarding is no longer the hardest problem in the chain. The harder one is enabling systems to make trusted decisions throughout the lifecycle of a digital interaction — where users, AI agents, enterprise applications, and policy engines all participate, and where any of them might be the weakest link.
The opportunity is that the architecture is still being chosen. Markets where AI adoption is earlier are not behind — they are in the window where the patterns can still be influenced rather than inherited. The questions worth taking seriously now are not product questions. They are architectural ones:
- How do our verification flows behave when the entity on the other side is an autonomous agent rather than a human?
- Can our risk and policy engine express decisions about what an agent is allowed to do, not just whether a person is allowed to sign in?
- Does our audit trail let an investigator answer not only what action happened but which agent, on whose behalf, with what scope, and why?
- Are we tracking the work coming out of NIST, the EU AI Act, Singapore’s AI Verify, and the major IAM vendors closely enough to anticipate the requirements that will land in our markets within the next eighteen to twenty-four months?
Getting these right early will matter more than shipping the next product feature.
A practical starting point
If you are designing AI-enabled systems today, three architectural commitments make almost everything that follows easier, and they line up directly with where NIST, Microsoft, Okta, and the SPIFFE community are converging:
- Place identity and risk evaluation before the AI agent in the request path. Not after, not in parallel — before. The AI should never be the component deciding whether an action is allowed.
- Design for continuous trust rather than session-based trust. Assume the trust signal will change mid-session, and build the system to re-evaluate. Sessions are a useful abstraction, but they are no longer where trust lives.
- Treat the identity layer with the same operational discipline as any other critical platform service. That means SLOs, observability, capacity planning, failure modes, and runbooks — not just security review.
Agent capabilities, policy complexity, and audit requirements all become tractable when those three are in place. They become much harder to retrofit later.
Closing thought
The next generation of enterprise software will be built around AI. But AI alone cannot establish trust.
As intelligent systems become more autonomous, identity will increasingly serve the same role that networking, storage, and observability already do: a foundational layer that every critical service depends on.
The organizations that recognize this shift early — including those of us still navigating it — will build AI systems that are not only more capable, but also more secure, auditable, and worthy of users’ confidence.
Identity is no longer just how systems know who you are. It is becoming the infrastructure that determines whether AI should act at all.
