This is the seventh and final article in a series tracing the history of digital identity from 1961 to the present. Part I began with Fernando Corbató's password on MIT's Compatible Time-Sharing System — the first time a computer asked a human to prove their identity. Part II followed the cryptographic revolution that replaced plaintext secrets with hashed proofs and public-key systems capable of establishing trust without shared secrets. Part III traced how Kerberos and LDAP extended identity across networks, and how Active Directory became the default identity system for enterprises worldwide. Part IV explored the web's identity crisis — how the stateless architecture of HTTP produced passwords, cookies, and the billion-account problem. Part V chronicled the federation wars: SAML, OAuth, OpenID Connect, and the rise of "Log in with Google" — solutions that reduced friction at the cost of concentrating identity in the hands of a few platform giants. Part VI examined how the smartphone made the body part of the identity stack — fingerprints, faces, and the biometric promise that you could stop proving who you are and simply be who you are.
Throughout those six decades, the identity stack was built around a primary assumption: the entity being authenticated was a human being, connecting from a known device, to a known network, through a defined perimeter. Non-human identities had always existed — Unix had daemon accounts, Kerberos had service principals, Active Directory had computer accounts, and bots had been authenticating to systems for as long as systems had been worth automating against. But they were a secondary category, managed as an adjunct to the human-centric infrastructure that received the protocols, the tooling, and the attention. In early 2020, every element of that primary assumption broke simultaneously. And in the years that followed, the secondary category grew to numerically dominate the primary one — joined, eventually, by a third category that fits into neither.
The World Before March 2020
For roughly thirty years, enterprise security rested on a spatial metaphor so intuitive it was rarely questioned: the castle and the moat.
The corporate network was the castle. It had walls (firewalls, literally named for the thing they resembled) and gates (access points where traffic was inspected before being allowed in). Inside the walls, things were trusted. Outside the walls, things were not. The security architecture of an entire industry was organized around the principle that proximity to the network conferred trust.
The metaphor wasn't merely decorative. It structured budgets, compliance frameworks, vendor ecosystems, and the daily work of hundreds of thousands of security professionals. It shaped what got funded and what got deferred. Intrusion detection systems watched the perimeter. Network access control guarded the gates. The VPN, or Virtual Private Network, served as the drawbridge: an encrypted tunnel that let a remote device reach inside the castle walls and, once inside, enjoy the same implicit trust as a machine plugged directly into the office Ethernet port.
The identity systems from earlier in this series were built on this assumption. Kerberos operated within a single realm, a defined boundary of trust. A ticket-granting ticket issued by the campus KDC was meaningless to a server in a different realm unless cross-realm trust had been explicitly configured. Active Directory organized identity within corporate forests, hierarchical domains that mirrored organizational structure and assumed well-defined boundaries. Even SAML and OpenID Connect, the federation protocols that extended trust across organizational boundaries, still assumed that the parties involved were defined entities: an identity provider here, a relying party there, an assertion flowing between them over a known and anticipated path.
Inside the castle, the inhabitants moved freely. An employee who had badged into the building, connected to the corporate Wi-Fi, and logged into their domain-joined laptop was, by the logic of the perimeter, trusted. The network was the authenticator of last resort. If you were on it, you belonged.
By 2019, this model was already under strain. Cloud migration had moved applications outside the castle walls. SaaS platforms like Salesforce, Workday, and Microsoft 365 lived on the public internet, not inside corporate data centers. Mobile devices connected from anywhere: hotel lobbies, airport lounges, coffee shops with unsecured Wi-Fi. The line between "inside" and "outside" was blurring.
Architectural change inside the data center was straining the model in a different way. The shift from monolithic applications to microservices, accelerating throughout the 2010s, multiplied the number of internal authentication events by orders of magnitude. A monolith that had a single database connection became fifty microservices, each authenticating to databases, message queues, caches, and other services. Containerization and orchestration tools like Docker and Kubernetes made it trivial to spin up new workloads, each of which needed credentials. The service account population, which had been a quiet sidecar to the human user population for decades, began growing exponentially. Most organizations were not rotating those credentials, were not scoping them tightly, and were not tracking them centrally. The perimeter was being asked to compensate not just for remote human users, but for an explosion of machine-to-machine authentication that nobody was managing well.
A growing body of security researchers and architects argued that the perimeter model was not just weakening but conceptually bankrupt, that trust based on network location was a fiction attackers exploited routinely once they got past the moat.
But the model persisted. Not because no one saw its flaws, but because it worked well enough. Entire industries had been built around defending the perimeter: firewall vendors, network security appliances, VPN concentrators, network segmentation consultants. Compliance frameworks (PCI-DSS, HIPAA, SOX) still asked about network segmentation and access controls defined in terms of network zones. The castle-and-moat model had institutional gravity. It was easier to patch than replace.
One organization had already replaced it.
Google's BeyondCorp: The Proof Nobody Followed
In January 2010, Google discovered that it had been breached. The attack, later known as Operation Aurora, was a sophisticated, state-sponsored intrusion attributed to Chinese intelligence services. Attackers had compromised Google's internal systems, accessed the Gmail accounts of human rights activists, and stolen intellectual property. The vector was a zero-day vulnerability in Internet Explorer, exploited through a targeted phishing attack on a Google employee. Once inside the network, the attackers moved laterally, because inside Google's network, as inside every corporate network, the implicit trust of the perimeter model gave them room to roam.
Google's response was not to build a better moat. It was to eliminate the moat entirely.
The initiative, called BeyondCorp, began in 2011 and was described in a series of papers published starting in 2014. The core principle was radical in its simplicity: access to internal applications should be determined by the identity of the user and the state of their device, not by whether they happened to be connected to the corporate network. A Google engineer in the Mountain View office and a Google engineer in a Jakarta hotel room should go through identical authentication and authorization. The network they were on was irrelevant.
Google decommissioned its internal VPN. Every request to an internal application, from any network, anywhere, was authenticated and authorized through an access proxy. The proxy evaluated the user's identity (authenticated through strong credentials), the device's identity (registered in a device inventory, checked for encryption status, patch level, and compliance with security policies), and the specific resource being requested. No network location provided implicit trust. Every request was individually evaluated.
BeyondCorp was widely admired within the security industry. It was narrowly adopted outside of it.
The reason was not that people disagreed with the principles. It was that BeyondCorp required an identity infrastructure maturity that most organizations simply didn't have. Google had a comprehensive device inventory. Most companies didn't know how many laptops they'd issued, let alone their patch levels. Google had fine-grained access policies for every internal application. Most companies had a flat network and broad VPN access that granted employees effective access to everything. Google had the engineering talent and budget to rebuild its entire access architecture from scratch. Most companies had a security team of eight people and a Cisco ASA they'd been running since 2012.
BeyondCorp was a proof of concept. It proved that the castle-and-moat model could be replaced, that identity-centric access control worked at enormous scale, and that the network perimeter was not a necessary component of enterprise security. But for the rest of the industry, the perimeter remained the path of least resistance.
Google was not entirely alone in operating without a meaningful perimeter, though most of the others hadn't planned it that way. Universities, by the nature of their constituencies, had been running de facto perimeter-less environments for years. A research university's "users" included undergraduates connecting from dorm rooms, graduate students working from labs, faculty traveling to conferences, international students logging in from home countries during breaks, and visiting researchers arriving from peer institutions. The notion of a "corporate network" with trusted insiders and untrusted outsiders had never quite mapped onto an institution whose population was distributed across continents and whose devices were overwhelmingly personally owned. Federations like InCommon, built on the Shibboleth implementation of SAML, let a student at one university authenticate to resources at another without a VPN tunnel or a shared domain. It wasn't called Zero Trust. It was called the Tuesday morning workload of a campus IT department. But the architectural pattern (identity-based access to resources independent of network location) was substantially in place at thousands of higher-education institutions long before the term gained traction.
The term itself arrived in the same year as Operation Aurora. In 2010, John Kindervag, then a principal analyst at Forrester Research, published a research report introducing the concept of "Zero Trust" as a network security model. Kindervag's argument was direct: the trusted-internal-network assumption was the root cause of the breaches Forrester's clients kept suffering, and the only durable fix was to stop treating any network as inherently trustworthy. The phrase caught on in security circles. The architecture caught on more slowly. For most of the decade that followed, "Zero Trust" was a talking point at conferences, a section heading in vendor marketing, and an aspiration in security strategy documents. Google had built a working implementation. Universities were running an accidental version of it. Kindervag had named it. What was still missing was a forcing function that would push the rest of the industry to follow.
The Pandemic, and the Framework That Met It
In late 2019, a virus emerged that would, within months, shut down offices on every continent. SARS-CoV-2 spread faster than any institution's pandemic plan had anticipated. By mid-March 2020, governments from Italy to California had ordered residents to stay home. Office buildings emptied. Commutes ended. The physical infrastructure that the castle-and-moat model had been built to protect (the building, the network, the badge readers, the cubicles full of domain-joined desktops) became inaccessible to the people who used it.
Suddenly, every organization in the world had the problem that BeyondCorp had been designed to solve. Most of them had to solve it in a fortnight, with whatever they already had.
Into that environment, in August 2020, the National Institute of Standards and Technology published Special Publication 800-207: Zero Trust Architecture. The document had been years in development. The first public draft circulated in September 2019, months before anyone had heard of SARS-CoV-2. But its publication date placed it at exactly the moment when the world was ready to listen.
SP 800-207 was not an identity specification in the way that SAML or OpenID Connect are identity specifications. You couldn't implement it as a library. It described no wire protocol and defined no assertion format. It was an architecture document, a framework for thinking about how security should be organized when the perimeter could no longer be assumed.
But identity ran through every page.
The document codified principles that BeyondCorp had demonstrated in practice: never trust, always verify. Access decisions should be based on the identity of the user, the identity of the device, the state of both, and the sensitivity of the resource being requested, not on the network from which the request originated. Authentication should be continuous, not a one-time event at login. Authorization should follow the principle of least privilege. Every access request should be dynamically evaluated against policy, in real time, using all available data.
These were not new ideas. The principle of least privilege appeared in Multics in the 1960s. Strong authentication had been the project of every system described in this series. Kindervag had given the model its name a decade earlier. But SP 800-207 assembled the principles into a coherent reference architecture, with formal definitions, component diagrams, and deployment patterns that organizations could actually evaluate themselves against. It moved Zero Trust from a concept to a specification.
The publication had teeth. Federal agencies were expected to align their security architectures with the framework. In May 2021, Executive Order 14028, signed by President Biden following the SolarWinds and Colonial Pipeline breaches, mandated that federal agencies adopt Zero Trust architectures. The Office of Management and Budget published a federal Zero Trust strategy in January 2022, with specific milestones and deadlines. Agencies had until the end of fiscal year 2024 to meet defined Zero Trust maturity criteria.
Federal requirements cascade. Agencies require their vendors to meet the same standards. Vendors who sell to the government restructure their products, and then sell those same products to the private sector. Compliance frameworks update to incorporate new requirements. Auditors ask new questions. Insurance underwriters adjust their risk models.
Zero Trust moved from security-conference talking point to procurement requirement in roughly two years. The pandemic didn't create Zero Trust. Google had built a working version of it a decade earlier. Universities had been improvising one for longer than that. Kindervag had named it in 2010. NIST was already documenting it. But the pandemic created the conditions under which the old model was no longer good enough for anyone, and the framework arrived just as the questions did.
The Overnight Inversion
The Two-Week Transformation
In March 2020, governments around the world issued stay-at-home orders. Offices emptied. Campuses closed. Hundreds of millions of knowledge workers were told to go home and keep working.
The instructions sounded simple. The technical reality was not.
Enterprise VPN systems had been designed for a specific usage pattern: the majority of employees work from the office, connected to the corporate network, with a minority (perhaps 10 to 15 percent) connecting remotely on any given day. The VPN infrastructure was sized accordingly. VPN concentrators had a maximum number of concurrent sessions. The bandwidth provisioned for the VPN termination point assumed that most corporate traffic would stay inside the building.
In the span of two weeks, remote usage went from 10 percent to 90 percent, or 100 percent. VPN concentrators buckled. Session limits were hit. Bandwidth saturated. Latency made applications unusable. The drawbridge, designed to admit a few travelers at a time, was asked to carry the entire population of the castle, and it collapsed under the weight.
Some organizations scrambled to buy additional VPN capacity. Others split-tunneled, routing only corporate-application traffic through the VPN and letting everything else go directly to the internet, a decision that solved the bandwidth problem and introduced a security gap wide enough to drive a truck through. Others discovered that their VPN vendor's emergency licensing process took weeks. Others discovered that their VPN vendor had gone bankrupt.
The perimeter, the organizing principle of enterprise security for three decades, didn't erode gradually. It vanished in a fortnight.
The Identity Layer Holds
When the perimeter vanished, what remained?
The firewall was irrelevant. There was no building to put it around. The badge reader was irrelevant. Nobody was walking through doors. The managed network was irrelevant. Every home router was now the network edge, and IT controlled none of them.
What remained was the identity stack.
The SSO portals still worked. Okta, Azure AD, Ping Identity, the Identity-as-a-Service platforms that Article 5 described, were cloud-hosted. They didn't care whether the user was connecting from an office in Chicago or a kitchen table in rural Ohio. The SAML assertions and OIDC tokens they issued were network-agnostic by design. The entire architectural premise of federation, that identity could be asserted across boundaries, turned out to be exactly the capability that a suddenly boundary-less world needed.
Organizations that had invested in the identity stack over the preceding decade found their investments paying off in ways they hadn't anticipated. If you'd already moved your applications to SaaS platforms and fronted them with an IDaaS provider, the transition to remote work was uncomfortable but survivable. Your employees opened their laptops at home, navigated to the same SSO portal they'd used from the office, authenticated with the same credentials, and reached the same applications. The user experience was almost unchanged. The security architecture was fundamentally different, the network was no longer providing any trust, but the identity layer papered over the gap.
Multi-factor authentication deployment accelerated sharply. With the VPN overwhelmed or abandoned, compromised credentials became the highest-value target for attackers. A stolen username and password, which in the old model might have gotten an attacker to the VPN login page but no further (assuming network-level controls inside), could now provide direct access to cloud-hosted applications from anywhere on earth. MFA went from "we'll get to it next quarter" to "deploy it this week" across organizations of every size.
The identity platforms that had been ancillary to the perimeter became, almost overnight, the perimeter itself.
What Broke
But the identity stack of early 2020 had not been designed to serve as the sole security layer. It had been built as one component in a defense-in-depth model that assumed the network, the physical facility, and device management were doing much of the heavy lifting. When those other layers disappeared, the gaps in the identity layer became visible.
Device identity became the first crisis. In the office, employees used company-issued laptops connected to a managed network. IT knew what those devices were, what software they ran, whether they were patched, whether their disks were encrypted. Now employees were logging in from personal laptops. From shared family computers where a teenager's gaming habits had installed questionable browser extensions. From tablets running operating systems two versions behind. From devices that IT had never seen, never inventoried, never approved, and had no ability to inspect.
The identity system could authenticate the user. It couldn't authenticate the device. And in a world without a network perimeter, the device mattered enormously. A valid user on a compromised device was worse than no user at all. It was an authenticated pathway for an attacker.
The context gap compounded the problem. Identity systems of 2020 could tell you who was logging in. They were much less capable of telling you whether the login made sense. Was it suspicious that this employee, who had logged in from Philadelphia every day for three years, was suddenly logging in from Romania at 3 AM? Probably. Was it suspicious that this employee was logging in from a new home IP address? Not anymore. Everyone was logging in from home. The behavioral baselines that had been useful for anomaly detection (login times, locations, devices) were scrambled overnight. Everyone looked anomalous. The context signals that supplemented identity verification became noise.
Identity lifecycle management strained under conditions it had never been designed for. Organizations were onboarding new employees who would never visit an office, who would never sit in an IT department while a technician configured their laptop, never stand in front of an HR representative to verify their identity documents, never receive a badge or a building key. The entire onboarding process had to be virtualized, and the identity verification step (the moment when a person proved they were who they claimed to be, so that a digital identity could be provisioned for them) became a Zoom call and a photograph of a driver's license held up to a webcam.
Offboarding was equally fraught. When employees left, access had to be revoked across every system: every SaaS application, every cloud resource, every collaboration platform. In the office, there were physical signals. The employee returned their badge, turned in their laptop, cleaned out their desk. In a remote world, the departure was entirely digital, and the blast radius of a missed deprovisioning step was larger than ever. A former employee with active credentials and no network perimeter to contain them could access corporate systems from anywhere, indefinitely.
Contractors and consultants, entities who existed entirely as digital identities, who might never meet anyone from the hiring organization in person, became especially challenging. Their access needed to be tightly scoped, time-limited, and promptly revoked. In the chaos of 2020, many fell through the cracks.
The gap between organizations became a survival-level distinction. Companies with mature identity infrastructure (IDaaS platforms, MFA deployed across the board, automated provisioning and deprovisioning, conditional access policies) found the transition to remote work disruptive but manageable. Companies that had relied on the network perimeter as their primary security control, that had deferred MFA deployment, that managed access through manual processes and spreadsheets, found themselves exposed in ways they couldn't quickly remediate.
The pandemic was, among many other things, a stress test for digital identity infrastructure. The results were uneven.
Identity Becomes the Perimeter
The crisis of 2020 didn't just elevate identity in the security stack. It fundamentally changed what identity systems were expected to do.
Before Covid, authentication was largely treated as a binary event. You proved who you were once, at the start of a session, and then operated within whatever trust your credentials afforded. The session token or Kerberos ticket you received was a boarding pass: checked at the gate, then honored for the duration of the flight. This model had deep roots. It was how Kerberos worked in Article 3. It was how cookie-based sessions worked in Article 4. It was how SAML assertions and OIDC tokens worked in Article 5.
In a Zero Trust world, authentication moved toward continuous evaluation. A user who was legitimate at 9 AM might not be legitimate at 9:15 if their device's compliance status changed, if they moved to an unusual location, if their behavior pattern shifted. The boarding pass model gave way to something more like continuous escort: the identity system monitored not just the initial proof of identity but the ongoing context in which that identity was being exercised.
Authorization became more granular. The old question, "Are you allowed in?", became "Are you allowed to do this specific thing, right now, from this specific device, at this specific time, in this specific context?" The coarse-grained access control that had been sufficient when the network provided an additional layer of protection needed to become fine-grained enough to stand on its own.
Device identity became first-class. Not a device certificate stored in a dusty corner of the PKI, but an active, continuously evaluated signal: Is this device encrypted? Is its operating system patched? Is its security software running? Is it registered in the organization's device management system? The identity of the user and the identity of the device became intertwined. Neither sufficient alone, both necessary together.
Identity governance, the administrative work of managing who has access to what and ensuring that access is appropriate and up to date, expanded from an IT compliance exercise to an operational necessity. Access reviews, which had been performed annually to satisfy auditors, needed to happen continuously. Automated provisioning and deprovisioning, which had been a nice-to-have, became required for organizations operating at scale with a fully remote workforce.
Identity, in short, didn't just survive the death of the perimeter. It became the perimeter. Every security decision that had previously been partially handled by the network (trust, access control, anomaly detection, session management) was now the identity system's problem.
The identity stack that Corbató started with a password and a plaintext file had, six decades later, become the load-bearing wall of enterprise security.
Passkeys and the Unfinished Password Revolution
The Cliffhanger
Article 6 told the story of FIDO, the Fast Identity Online Alliance, and its attempt to solve the password problem once and for all. FIDO2 and WebAuthn, finalized in 2019, were cryptographically elegant: public-key authentication, phishing-resistant by design, with the private key locked in hardware and the user verified by biometric or PIN. Every piece of the architecture was sound.
Except one.
The private key lived on the device. If you lost the device, you lost the key. If your phone was stolen, or destroyed, or simply upgraded, the FIDO credentials stored in its secure enclave were gone. Every site, every service, every account where you'd registered a FIDO credential was inaccessible until you went through whatever recovery process each individual service provided. And those recovery processes, in most cases, fell back to the very thing FIDO was trying to replace: a password, a text message, a knowledge-based security question.
It was a recovery problem, and it was the anchor dragging down FIDO2 adoption. A security key was a second factor, fine. But replacing the password entirely required that the replacement be at least as resilient as what it replaced. And the password, for all its flaws, was resilient in one crucial way: you could memorize it, carry it in your head, and type it on any device anywhere. A cryptographic key stored on a single piece of hardware could not compete with that portability.
The pandemic made the problem more acute. Remote workers, relying on their personal devices for all access, were more vulnerable to device loss and more isolated from IT support that could help them recover. A factory employee who lost their security key could walk to the IT desk. A remote employee who lost their phone was locked out of everything, with no desk to walk to.
FIDO had the right architecture. It needed a different threat model for key storage.
The Passkey Bet
In June 2022, Apple, Google, and Microsoft jointly announced support for a new FIDO capability that the alliance had been developing for roughly a year: multi-device FIDO credentials. The marketing name, chosen for consumer legibility, was passkeys.
The core innovation was syncable credentials. Instead of generating a FIDO private key and binding it irrevocably to a single device's secure enclave, the key would be encrypted and synced through the user's platform account. On Apple devices, passkeys synced through iCloud Keychain. On Android devices, through Google Password Manager. On Windows, through the Microsoft account ecosystem.
The recovery problem dissolved. Lose your phone, buy a new phone, sign into your Apple or Google account, and your passkeys were already there, synced from the cloud, decrypted with your platform credentials, ready to authenticate you to every service where you'd registered them. The private key never left the user's encrypted ecosystem, but it was no longer tethered to a single physical device.
The user experience was revelatory. Creating a passkey: navigate to a website, tap "Create passkey," glance at your phone for Face ID or touch the fingerprint sensor, done. Signing in: navigate to the same website, tap "Sign in," glance or touch, done. No username to type. No password to remember. No six-digit code to copy from an authenticator app. The entire authentication flow completed in seconds, with a single biometric gesture.
For the first time in the six-decade history of digital identity, the most secure authentication method was also the easiest to use. Public-key cryptography, phishing-resistant, replay-resistant, server-breach-resistant, wrapped in an experience simpler than typing a password.
The moment should have been triumphal. It was, instead, complicated.
The Passkey Paradox
The cloud sync that solved the recovery problem created a new dependency problem. Passkeys synced through iCloud Keychain lived in Apple's ecosystem. Passkeys synced through Google Password Manager lived in Google's ecosystem. Moving from an iPhone to an Android phone, or vice versa, meant your passkeys didn't follow.
This was the federation wars' concentration problem restated in a new key. Article 5 traced how "Log in with Google" and "Log in with Facebook" concentrated identity assertion in the hands of a few platform giants. Passkeys concentrated something arguably more fundamental: credential custodianship. The private keys that proved your identity to every service you used were now stored by, encrypted by, and managed by your platform provider.
If Apple disabled your iCloud account, for a terms-of-service violation, a billing dispute, a fraud flag, an error, you didn't just lose access to your photos and documents. You lost the cryptographic credentials for every service where you'd registered a passkey through iCloud Keychain. The same was true for Google. The platform provider wasn't merely asserting your identity to relying parties, as in the OIDC model. It was holding the keys.
The FIDO Alliance recognized the problem. A credential portability specification was developed to enable passkeys to be exported from one provider and imported to another, much as you might export passwords from one password manager to a competitor. But the specification arrived after the ecosystem had already formed, and platform incentives didn't naturally align with making it easy for users to leave.
Third-party password managers, 1Password, Bitwarden, Dashlane, added passkey support, offering a cross-platform alternative to the platform-native keystores. If you stored your passkeys in 1Password, they worked on your iPhone, your Android tablet, your Windows laptop, and your Chromebook. But password managers, despite decades of expert recommendation, remained niche. The same usability gravity that made "Log in with Google" dominant over manually configuring OpenID made platform-native passkeys dominant over third-party alternatives. The user refused, as always, to be their own system administrator.
The Backup Credential Problem
There was a more fundamental issue. Virtually every website that added passkey support also kept password login as a fallback.
This was understandable. Not all users had devices that supported passkeys. Not all users would create passkeys immediately. The transition would be gradual, and during the transition, both authentication methods needed to coexist.
But it meant that the system was only as strong as its weakest authentication path. An attacker who couldn't phish a passkey, because passkeys are cryptographically bound to the origin and there is no secret to intercept, could still phish the password that the same account accepted as an alternative login method. The passkey raised the floor of security for users who adopted it. It did not raise the ceiling for the account, because the basement door was still unlocked.
A handful of services began offering passkey-only accounts. Google's Advanced Protection Program, for instance, could be configured to require passkeys without password fallback. But these were exceptions. For the vast majority of the web, passkeys were added alongside passwords, not instead of them. The password remained the universal fallback, the credential of last resort, the authentication method that every service implemented because every service had always implemented it.
The series has seen this pattern before. HTTPS coexisted with HTTP for twenty years. MFA was optional on most services for a decade after it was technically available. Hashing replaced plaintext password storage only after repeated, spectacular breaches made the cost of negligence undeniable. The displacement of an established technology by a superior one is not a moment. It's a geological process.
Corbató's invention was not dead. It was merely, finally, slowly, being supplemented by something better. The password's survival, despite every article in this series documenting its inadequacy, may be the most persistent pattern in the history of digital identity.
The Adoption Gap
By mid-2025, passkey support existed on many of the world's most-visited services. Google, Apple, Amazon, GitHub, Microsoft, PayPal, eBay, Best Buy, Kayak, and dozens of others offered passkey authentication. The FIDO Alliance reported hundreds of millions of passkeys in use globally.
But the long tail of the web, the millions of smaller sites, the legacy enterprise applications, the industry-specific platforms, the government services, was still passwords. A user might sign in to Google with a passkey and then, in the next browser tab, type a password into their dentist's patient portal, their local utility company's bill-pay site, their child's school management system.
This, too, was a pattern the series had documented from the beginning. Innovation in identity starts at the center, the largest services, the best-funded organizations, the most technically sophisticated platforms, and diffuses outward over years, sometimes decades. The web was still living through the diffusion curve that every previous identity technology had traced.
Non-Human Identity — When the Entity Isn't a Person
The Assumption That Receded
Return, for a moment, to the beginning.
In 1961, Fernando Corbató needed to give each user a private set of files on a shared computer. He created a password. The user was a human, a researcher at MIT. In Article 3, Kerberos authenticated students and staff. In Article 4, the web authenticated shoppers and email users. In Article 5, federation protocols authenticated employees and consumers. In Article 6, biometrics authenticated device owners.
Non-human identities were present throughout this history. Unix had daemon accounts from its earliest versions. Kerberos defined service principals alongside user principals. Active Directory treated computer accounts and service accounts as first-class objects. Cron jobs, batch processes, and inter-system integrations had been authenticating to systems for as long as systems existed. The identity stack was not blind to non-human entities.
But non-human identities were a secondary concern. They were a minority of the identity population, perhaps a few hundred service accounts in an organization with thousands of human users. They were statically configured: created once, rarely changed, often outliving the projects that spawned them. Their credentials were typically long-lived shared secrets, managed (when they were managed at all) through manual processes that had not evolved much since the 1990s. The governance frameworks, the compliance requirements, the security tooling, the user experience considerations, all were built around the human user as the primary subject.
In a modern cloud-native organization, that ordering has inverted.
The LLM Inflection Point
The microservices shift described in Part I started the inversion. Containers and orchestration accelerated it. Cloud-native automation, where Terraform scripts, Kubernetes manifests, and CI/CD pipelines spin resources up and down on demand, pushed the non-human identity count past the human one in most cloud-forward organizations by the late 2010s. Every workload needed credentials. Every pipeline needed credentials. The service account population, once a quiet sidecar, became the majority population.
Then ChatGPT shipped.
The release of ChatGPT in November 2022 marked the moment that large language models crossed from research curiosity to mass-market product. Within eighteen months, every major cloud provider had a frontier-model offering. Every enterprise software vendor was racing to embed generative AI into its product. Every Fortune 500 company had an "AI strategy," and most of them were spending real money to execute it.
The identity consequences of this shift were not initially obvious. The early conversation about LLMs focused on the models themselves: their capabilities, their hallucinations, their training data, their alignment. The infrastructure question, who or what was actually authenticating to whom inside an AI-enabled system, was a footnote in those early discussions. It did not stay a footnote for long.
A modern LLM-powered application is not a single service calling a single API. It is a sprawling graph of authenticated interactions. The user's request hits an application backend. The backend authenticates to a model provider (OpenAI, Anthropic, Google, AWS Bedrock) using an API key. The model, mid-generation, decides it needs to call a tool: a search API, a database query service, an internal knowledge base. Each tool invocation is a separate authentication event, often using credentials scoped to the application but exercised on behalf of the user. Retrieval-augmented generation pipelines authenticate to vector databases. Agent frameworks chain multiple model calls together, each one a billable, authenticated request. Tool-brokering protocols like LangChain's tool interface and Anthropic's Model Context Protocol add yet another layer, where an LLM at runtime is handed a portfolio of tools, each with its own credentials, scopes, and lifetimes.
A single user query, "summarize this document and email me the highlights," might trigger fifteen authenticated calls between non-human entities before the email is sent. None of those calls involve a human pressing a button. All of them require credentials. Most of those credentials are API keys, the same shared-secret model this series has been documenting (and lamenting) since the CTSS password file.
The result is an identity population whose growth curve looks less like an organization chart and more like an infrastructure invoice. A mid-size technology company with 2,000 employees might have 50,000 service accounts, 10,000 API keys, 100,000 short-lived cloud workload identities, and several million certificates. Add an AI-heavy product line and the API key count alone can grow by another order of magnitude. Google has disclosed that its internal systems process billions of remote procedure calls per second, each one authenticated.
The identity systems this series has spent six articles describing, designed for humans, evolved for humans, optimized for the human experience of proving who you are, were not built for this. The service principal in 1990s Kerberos was a real concept. It was also a footnote. The footnote has become the document.
Two Kinds of Non-Human
The term "non-human identity" is becoming an umbrella over two populations that share a label but very little else.
The first is the service identity: a workload, a script, a container, a CI/CD pipeline, a cron job. Service identities do deterministic things. A payment processing service authenticates to a database and runs known queries. A backup job authenticates to a storage bucket and writes files on a schedule. The service's behavior is defined by the code its developers wrote, and that behavior, while it may have bugs, does not improvise. The credential a service uses can be scoped tightly, because the operations the service will perform are knowable in advance. ALTS, Metatron, and SPIFFE, the systems described in this section, were all designed for service identities. They work because the entity being authenticated is, in effect, a function: predictable input produces predictable output, and the authorization model can be defined accordingly.
The second is the agent identity: an LLM-powered entity that reasons about a task, decides what tools to call, and chains together actions whose specific sequence was not predetermined when the agent was deployed. Agent identities do not do deterministic things. The same agent, given the same instruction on two different days, may take different paths to the answer, call different tools, request different permissions, and reach different conclusions. The credential an agent uses cannot be scoped tightly in the traditional sense, because the operations the agent will perform are not knowable in advance. They are decided at runtime, by the model, in response to whatever the agent encounters along the way.
The two populations share authentication mechanisms. They both present API keys, request tokens, hold certificates. But the governance models that work for one fail for the other. Audit logs that satisfy a SOX auditor for a service account ("here is the list of operations this account performed, all of which match the documented behavior of the service") become incoherent for an agent account, where the operations performed reflect not the documented behavior of the entity but the in-context reasoning of a language model on a given Tuesday.
The bulk of this section is about service identities, because that is where the existing tooling, standards, and governance frameworks live. Agent identities are the subject of Part V, where the questions get harder and the answers get sparser.
Google ALTS: Kerberos for the Data Center
Google's approach to service identity, called ALTS (Application Layer Transport Security), illustrates both the scale of the problem and the architectural pattern emerging to solve it.
ALTS is a mutual authentication and transport encryption system designed for service-to-service communication within Google's data centers. Every workload (every container, every virtual machine, every service) receives a cryptographic identity. When one service calls another, both sides present their credentials and verify each other's identity before any data is exchanged. This is mutual TLS at enormous scale, with a custom protocol optimized for Google's infrastructure.
The conceptual model is familiar. In Article 3, Kerberos used a trusted authority, the Key Distribution Center, to issue tickets that services could present to each other. ALTS follows the same pattern: a trusted authority issues cryptographic identities, and services use those identities to prove themselves to each other. The KDC operated within a campus network, issuing tickets to hundreds or thousands of users. ALTS operates across a global data center fleet, issuing identities to millions of workloads.
The difference is not just scale. It's dynamism. A Kerberos principal was provisioned when a student enrolled or an employee was hired, and it persisted for months or years. An ALTS identity might be issued to a container that exists for thirty seconds, serves a burst of traffic, and is destroyed. The identity lifecycle for service entities operates on a fundamentally different timescale than for humans. Provisioning and deprovisioning happen not through HR workflows but through orchestration systems that create and destroy workloads continuously, automatically, without human intervention.
ALTS also illustrates a principle that the Zero Trust architecture formalized but that Google implemented years earlier: network location confers no trust. Even within Google's own data centers, behind Google's own physical security, on Google's own network hardware, services authenticate to each other cryptographically. A compromised service on the same rack as a database server gets no implicit access to that database. It must present a valid identity, and that identity must be authorized for the specific access it's requesting.
The principle of least privilege, articulated in Multics in the 1960s and implemented imperfectly in every system since, is, in ALTS, enforced at the level of individual RPCs between individual services, billions of times per second.
Netflix Metatron: Identity at the Application Layer
Netflix faced a similar problem with a different architectural philosophy. Where Google built a custom protocol tightly integrated with its proprietary infrastructure, Netflix, which runs almost entirely on Amazon Web Services, needed a workload identity system that operated at the application layer, on top of infrastructure it didn't own.
Metatron, Netflix's workload identity system, assigns a cryptographic identity to every application and service in Netflix's infrastructure. When a Netflix microservice starts up, it receives a short-lived certificate that identifies it, not just as "a Netflix service" but as a specific application, running a specific version, in a specific environment. That identity follows the service through its interactions with other services, data stores, and external APIs.
The power of Metatron lies in what it enables downstream: fine-grained authorization. Not "this service is a Netflix service, so it can access Netflix things," but "this specific service, the recommendation engine running version 4.7 in the production environment, can read from this specific data store, using these specific query patterns, and nothing more." The blast radius of a compromised service is contained. If an attacker compromises the A/B testing service, they get the A/B testing service's permissions, not the permissions of the payment processing service or the subscriber database.
This is the Multics access control model, reimagined for a world where the "users" are software components and the "resources" are APIs and data stores rather than files and directories. It is also, in a sense, the completion of an arc that began in Article 2: the cryptographic tools developed for human authentication (public keys, certificates, digital signatures) turned out to be equally essential for authenticating entities that have no fingerprints, no faces, and no ability to remember a password.
SPIFFE/SPIRE: The Open Standard Emerging
Google built ALTS for Google. Netflix built Metatron for Netflix. The question that naturally followed was: could a standard be established that worked across organizations, across cloud providers, across the heterogeneous infrastructure that most companies actually operated?
SPIFFE, the Secure Production Identity Framework for Everyone, is the attempt at an answer. Originally developed at a startup called Scytale (founded by engineers who had worked on Google's identity infrastructure) and now a graduated project of the Cloud Native Computing Foundation, SPIFFE defines a standard way for workloads to identify themselves. A SPIFFE identity is a structured URI, a name like spiffe://example.com/payment-service/production, backed by a short-lived X.509 certificate or JWT token issued by a trusted authority.
SPIRE, the SPIFFE Runtime Environment, is the reference implementation: the software that actually runs on your infrastructure, verifies workloads, and issues them SPIFFE identities. It performs attestation, verifying that a workload is what it claims to be by checking properties of the environment it's running in (the Kubernetes pod it's deployed to, the AWS instance it's running on, the binary hash of its code). Only after attestation succeeds does SPIRE issue an identity.
The federation problem from Article 5 reappears here, restated for machines. When a service at Company A needs to call an API at Company B, how does Company B verify the identity asserted by Company A's infrastructure? SPIFFE federation allows trust domains to be established between organizations, analogous to the SAML trust relationships between identity providers and service providers, but operating at the machine-to-machine layer. Company B's SPIRE server can be configured to trust identities issued by Company A's SPIRE server, enabling cross-organizational workload authentication without shared secrets.
The parallel to the human identity federation story is almost exact. SAML solved "how does an employee at Organization A prove their identity to a service at Organization B?" SPIFFE solves the same problem for workloads. The technical mechanisms differ (certificates instead of XML assertions, attestation instead of user login), but the fundamental challenge is identical: establishing trust across organizational boundaries without requiring every entity to have a direct relationship with every service.
SPIFFE and SPIRE are gaining adoption. Uber, Bloomberg, ByteDance, and several major financial institutions have deployed them. But they remain early in the adoption curve. Most organizations in 2025 still manage service identities the way most organizations managed human identities in the early 2000s: inconsistently, manually, and with varying degrees of rigor.
The Secret Sprawl Problem
If SPIFFE represents the future of service identity, the present is considerably messier.
The dominant form of non-human authentication in most organizations remains the shared secret: an API key, a database password, a service account credential, an OAuth client secret. These secrets are stored in configuration files, embedded in environment variables, committed to source code repositories, pasted into CI/CD pipeline configurations, and shared in Slack messages between engineers who need to get something working by Friday.
The resemblance to the CTSS password file is not metaphorical. It is structural. In 1966, a software bug printed the contents of CTSS's master password file to every user who logged in. The file existed because passwords had to be stored somewhere, and the system's designers hadn't yet developed the tools to protect them. In 2025, API keys exist in Git repositories because secrets have to be stored somewhere, and many organizations haven't yet deployed the tools to manage them.
The consequences are predictable because they are the same consequences the series has documented for six decades: when credentials are stored insecurely, they are eventually compromised.
In April 2021, Codecov, a company that provides code coverage analysis tools, disclosed that an attacker had modified its Bash Uploader script to export environment variables from customers' CI/CD environments. Those environment variables contained secrets: API keys, tokens, credentials for cloud services, database passwords. The attacker harvested these secrets for two months before the breach was discovered. The compromised credentials provided access not to Codecov's systems but to the systems of Codecov's customers, including, reportedly, Twilio, HashiCorp, and other technology companies.
The pattern was familiar. The 2020 SolarWinds attack, one of the most consequential breaches in history, exploited the software supply chain to compromise the Orion network management platform, which was deployed inside thousands of government agencies and corporations. Once inside, the attackers moved laterally through networks using, among other techniques, stolen service account credentials and forged SAML tokens. The breach demonstrated that non-human identity, the service accounts, the trust relationships between automated systems, the machine-to-machine authentication that operates invisibly beneath the surface, was not a secondary concern. It was the primary attack surface.
These are not exotic attack vectors. They exploit the most basic failure mode in identity management: credentials that are too powerful, too long-lived, and too poorly tracked. A service account created three years ago for a project that no longer exists, with administrator-level access to a production database, its credentials stored in a configuration file that twelve people can read: this is the norm, not the exception, in most organizations.
Identity Governance for Machines
Human identity has lifecycle management. An employee is onboarded: an account is created, access is provisioned based on their role, a badge is issued, a laptop is configured. The employee changes roles: access is reviewed and adjusted. The employee leaves: the account is disabled, access is revoked, the badge is deactivated.
The process is imperfect. Article 5 documented how identity governance products emerged specifically because organizations struggled with access creep, orphaned accounts, and excessive permissions even for human identities. But the framework exists. HR events trigger identity events. Auditors ask questions. Compliance frameworks require periodic access reviews.
Service identities, in most organizations, have no lifecycle at all.
A service account is created by a developer who needs one application to talk to another. The developer creates the account with broad permissions, because it's faster, because the exact permissions needed aren't clear yet, because the project is due tomorrow. The project launches. The developer moves to a different team. The service account persists. Its credentials are never rotated. Its permissions are never reviewed. Nobody remembers why it exists, but nobody dares delete it because it might break something.
These are "zombie" service accounts: non-human identities with active credentials and broad permissions, owned by no one, reviewed by no one, waiting to be discovered by an attacker or an auditor. They are the digital equivalent of giving a contractor the building keys, watching the contractor leave, and never changing the locks.
The scale makes manual governance impossible. An organization with 100,000 service identities cannot review each one quarterly with a human reviewer the way it might review human access certifications. The governance tooling that emerged for human identity, the identity governance and administration (IGA) platforms described in Article 5, is being extended to cover service identities. Workload identity standards like SPIFFE replace the long-lived shared secret with short-lived attested credentials, eliminating the rotation problem by making rotation continuous. The tooling is immature relative to the scale of the problem, but the path forward is at least visible.
Agent identities are a different matter. The lifecycle of a service identity, however poorly managed, is bounded by the lifecycle of the workload: when the service is decommissioned, the credential should be revoked. The lifecycle of an agent identity is not bounded by anything comparable. An agent might be instantiated for a single task, run for thirty seconds, exercise permissions across half a dozen systems, and terminate. The next invocation of "the same agent," conceptually, might use different tools, request different scopes, and produce different audit trails. The governance question is not "is this account still needed?" but "is this behavior still authorized?", and the second question is one no current IGA platform knows how to ask.
The compliance frameworks are catching up to service identity. SOX auditors now ask about service account management. PCI-DSS 4.0 includes requirements for managing application and system accounts. Cloud security benchmarks from CIS and CSA include controls for workload identity. The frameworks are mostly silent on agent identity, because the regulators are still figuring out what an agent is.
Non-human identity in 2025 is, in this respect, two stories at different stages. Service identity governance is where human identity governance was in the early 2000s: recognized as important, poorly managed in practice, governed by frameworks that are still being written, but with a coherent model of what "good" looks like. Agent identity governance has no such model yet. Part V is about why.
AI Agents — "What Are You?"
The Question Changes
The identity stack was built over six decades to answer a single question: Who are you?
The question has been asked at terminal prompts, login pages, SSO portals, and biometric sensors. It has been answered with passwords, cryptographic keys, SAML assertions, OIDC tokens, fingerprints, and face geometry. The answers have grown more sophisticated, more secure, and more convenient. But the question has remained fundamentally the same.
It is now being asked a question it has never faced: What are you?
AI agents are not humans. They don't have fingerprints. They don't have faces. They don't have memories of their first pet's name. But they are also not service identities in the sense Part IV described. A service account for a payment processing microservice has a defined purpose, a fixed set of operations it performs, and permissions that can be scoped precisely. It authenticates to specific endpoints to perform specific tasks. It doesn't reason. It doesn't improvise. It doesn't encounter unexpected situations and decide how to handle them.
An AI agent does all of those things.
An AI agent is an autonomous or semi-autonomous entity that reasons, makes decisions, and takes actions, often on behalf of a human, sometimes on behalf of another system, occasionally on its own initiative. It might browse the web, call APIs, compose and send emails, book travel, negotiate with other agents, write and execute code, or interact with humans in ways indistinguishable from another human. It occupies a category that the identity stack was never designed to accommodate: an entity that acts with the autonomy of a human but the scalability of a machine, and whose specific actions in any given session reflect the runtime reasoning of a model rather than the documented behavior of a service.
The identity systems described in every article of this series, from Corbató's password to SPIFFE's workload attestation, were designed for entities whose behavior could be anticipated and whose authority could be defined in advance. A human user might need read access to a database; grant it. A service account might need to write to a message queue; scope it. The permissions are defined, static, and auditable.
An AI agent might start a session needing to read your calendar, discover that the meeting it's scheduling conflicts with a flight, pivot to searching for alternative flights, find that your corporate travel policy requires manager approval for itinerary changes above a certain cost, and initiate an approval workflow, all within a single task, all requiring different permissions, none of which were individually anticipated when the agent was authorized.
This is not a theoretical scenario. It is the immediate practical reality of deploying AI agents in enterprise environments in 2026.
The Agent Authentication Problem
When an AI agent calls an API, whose identity is it using?
The question sounds simple. The answer is anything but.
Consider three models, each with different implications:
Delegated authority. The agent authenticates as you. It uses your credentials, or more precisely, tokens derived from your credentials through an OAuth-style delegation flow. The API sees your identity and grants the agent whatever access you have. This is the most natural extension of existing identity infrastructure. OAuth's delegation model was designed for exactly this pattern: "This application wants to access your resources on your behalf."
But OAuth delegation was designed for applications with predictable behavior. When you authorize a photo-printing service to access your Google Photos, the scope is clear: read access to your photos. The service won't suddenly decide to also read your email, edit your calendar, and post to your social media. An AI agent, by nature, might do any of those things depending on what it encounters during execution. The static scope model, defined at authorization time and fixed for the duration of the token, fits poorly with an entity whose needed permissions can't be predicted in advance.
Agent identity. The agent authenticates as itself, a distinct entity with its own credentials, its own permissions, its own audit trail. This model treats agents like the service identities described in Part IV: workloads with cryptographic identities, scoped access, and lifecycle management.
The problem is authorization. What permissions should the agent have? If it's acting on your behalf, it needs access to your resources, but granting your full permissions to an autonomous entity that might make decisions you haven't explicitly authorized is a profound expansion of trust. If it has its own restricted permissions, it might not be able to complete the tasks you need it to do. The principle of least privilege requires knowing what access will be necessary, and with an AI agent, that's often unknowable until the agent is mid-task.
Organizational identity. The agent authenticates as a representative of the organization that deployed it, a corporate agent acting within corporate authority. This is analogous to how a company's service account might access a partner's API: the credentials identify the organization, and the specific actions are governed by agreements between organizations.
This model works for business-to-business interactions but breaks down for consumer use cases. When an AI agent books a flight on a consumer travel site, it's acting on behalf of a specific person, not an organization. The site needs to know whose flight is being booked, not which AI provider built the agent.
In practice, the industry in 2026 is using all three models in different contexts, and sometimes all three simultaneously. An agent might authenticate to your calendar as you (delegated authority), authenticate to an external API as itself (agent identity), and authenticate to a partner service as the company that deployed it (organizational identity), all within a single task execution. The resulting tangle of credentials, tokens, and trust relationships is, to put it gently, not well standardized.
The Scope Problem
OAuth scopes (read:email, write:calendar, access:photos) are static. They are defined at authorization time, granted or denied by the user, encoded in the access token, and fixed for the token's lifetime. This model served the web well for fifteen years because the applications using OAuth had predictable, bounded behavior. A photo-printing app needs to read photos. A calendar widget needs to read calendar events. The scope of access can be defined in advance because the application's functionality is known in advance.
AI agents break this model.
An agent assisting with travel planning needs calendar access (to check availability), email access (to forward confirmation emails), payment access (to book flights and hotels), and potentially communication access (to contact travel providers). These aren't separate agents with separate scopes. They're different capabilities of a single agent pursuing a single task.
Worse, the needed permissions change dynamically based on what the agent encounters. If the preferred hotel is sold out, the agent might need to search alternative booking platforms it wasn't originally authorized to access. If a flight requires a visa that the user doesn't have, the agent might need to access government services to check visa requirements. Each new step in the reasoning chain might require permissions that weren't anticipated when the agent started.
The authorization models from the entire series, access control lists from Article 2, role-based access control from Article 5, attribute-based access control from the Zero Trust architecture, share a common assumption: the set of needed permissions can be defined, or at least bounded, in advance. An ACL says "these entities can access this resource." An RBAC policy says "entities in this role can perform these operations." ABAC extends the model with contextual attributes but still evaluates access against predefined policies.
What's needed for AI agents is something closer to supervised autonomy: the ability for an agent to request new permissions dynamically, with some combination of automated policy evaluation and human approval. Some early frameworks implement this as a "permission escalation" pattern. The agent operates within a baseline set of permissions and, when it encounters a task requiring additional access, pauses and requests authorization from the user or from an automated policy engine.
This is workable but introduces latency into agent operations and reintroduces the human-in-the-loop bottleneck that agents were supposed to eliminate. The tension between security and usability, the oldest recurring pattern in this series, appears once more, in a new form.
The Accountability Problem
Identity systems have always struggled with the gap between "an action was taken by this account" and "this person authorized this action." Service accounts in particular have long been a weak point: a credential shared among engineers, used by a script that nobody owns, performing operations that no individual person can be said to have intended. Audit trails record what the account did. They are often vague about who, in any meaningful sense, did it.
AI agents take this gap and turn it into a chasm.
When a human employee accesses a customer record, the audit log records: who (the employee's identity), when (timestamp), what (the specific record), and from where (the device and network). The mapping from log entry to responsible party is direct. When a deterministic service account modifies a database, the mapping is indirect but recoverable: someone wrote the code, someone deployed the code, the code did exactly what it was written to do.
When an AI agent takes an action, who is responsible?
The user who deployed the agent? They may not have known what specific actions the agent would take. The developer who built the agent? They defined the agent's capabilities but not its runtime decisions. The organization that hosted the agent? They provided the infrastructure but not the instructions. The model provider, OpenAI, Anthropic, Google, whose language model powers the agent's reasoning? They provided the cognitive engine but not the specific task. The data the agent encountered mid-task, which influenced its decisions through prompt injection, retrieval-augmented generation, or simple context-window contents? That data shaped the action without authorizing it.
The accountability question is not merely philosophical. It has immediate practical consequences. When an AI agent, acting on delegated authority, makes a purchase that the user didn't specifically authorize, who bears the financial liability? When an agent accesses medical records in the course of helping a user manage their healthcare, does that access comply with HIPAA, and whose compliance obligation is it? When an agent sends an email that creates a contractual obligation, is the user bound by the contract?
The audit trail needs to capture not just what happened but a richer set of metadata: what entity initiated the action, on whose authority, using what model, with what version of what system prompt, in pursuit of what goal, having taken what prior reasoning steps, in response to what intermediate inputs. The identity event becomes not a single record but a chain, a provenance trail that links the action back through the agent's reasoning process to the human or system that authorized it.
No standard format for this extended audit trail exists in 2026. Organizations deploying AI agents are building bespoke logging and accountability systems. The compliance frameworks have not yet caught up. This is familiar territory: the regulations always lag the technology, and the gap between what's deployed and what's governed is filled, eventually, by a breach or a lawsuit dramatic enough to force the issue.
The Liveness Problem Returns
Part II of Article 6 discussed the liveness problem in biometric authentication: how does the system know it's dealing with a real finger rather than a silicone replica? A real face rather than a photograph held up to the camera? The answer, liveness detection, challenge-response protocols, depth sensing, was an ongoing arms race between authenticators and attackers.
AI agents create a new liveness problem, but inverted.
The old liveness problem asked: Is this biometric sample from a living person? The new liveness problem asks: Is this entity a person at all?
When a customer calls a bank's support line, is the voice on the line a human customer or an AI agent impersonating one? When someone joins a video call for a remote identity verification, is the face on the screen a real person or a deepfake? When an email arrives requesting a wire transfer and it sounds exactly like the CEO's writing style, is it the CEO, or is it a language model that was fine-tuned on the CEO's previous communications?
CAPTCHAs (Completely Automated Public Turing tests to tell Computers and Humans Apart) were the original answer to the machine-detection problem. They were invented in 2003, and for roughly fifteen years, they worked well enough. Distorted text, image recognition tasks, behavioral analysis: each generation of CAPTCHA exploited cognitive abilities that humans had and machines lacked.
By 2026, that gap had largely closed. Language models could solve text-based CAPTCHAs. Vision models could identify traffic lights and crosswalks. AI systems could mimic human mouse movements and browsing patterns closely enough to fool behavioral analysis. The CAPTCHA was not yet entirely dead. reCAPTCHA v3's risk scoring still provided some signal. But the fundamental premise that there existed cognitive tasks humans could perform and machines couldn't was eroding rapidly.
The identity question was no longer just "Are you who you claim to be?", the authentication question the series had traced for six decades. It was "Are you what you claim to be?", a question the identity stack had never been designed to answer.
The Impersonation Problem
Voice cloning had crossed the uncanny valley. Given a few minutes of sample audio, easily obtained from a public talk, a podcast appearance, a YouTube video, or a voicemail greeting, commercial and open-source tools could generate synthetic speech that was, to the human ear, indistinguishable from the original speaker. Not approximately similar. Not close enough to fool a casual listener. Indistinguishable.
This demolished authentication systems that had relied on voice as an identity signal. Banks that verified callers by voice pattern. Corporate phone trees that used voiceprint as a second factor. Elder-care systems that authenticated family members before releasing information. These systems were designed against the threat model of a human impersonator: someone who could mimic a voice imperfectly, who would falter under questioning, whose impersonation had limits. A synthetic voice has no limits. It doesn't falter. It can sustain the impersonation indefinitely, responding to any prompt, in the exact vocal timbre of the target.
Deepfake video followed the same trajectory. Real-time face synthesis, generating a video stream that mapped one person's expressions onto another person's face, was available as a consumer application. The remote identity verification industry, which had grown during the pandemic to handle identity proofing over video calls, suddenly faced an existential challenge to its core process: how do you verify that the face on the screen is real when the technology to synthesize a convincing face is freely available?
The biometric liveness problem from Article 6 had escalated. It was no longer about fake fingerprints and silicone masks, niche attacks that required physical artifacts and close proximity. It was about synthetic humans that could pass Turing tests through digital channels, the channels that the pandemic had made the primary medium for identity verification.
AI-generated text (emails, chat messages, documents) posed a subtler but equally fundamental challenge. Knowledge-based authentication ("What was your mother's maiden name?") was already weakened by data breaches and social media oversharing. AI agents could now synthesize convincing answers to challenge questions, compose emails in the writing style of specific individuals, and engage in real-time chat interactions that were indistinguishable from human conversation.
The identity stack was built on an implicit assumption so fundamental it was never stated: that the entity on the other end of an authentication transaction was a kind of entity (human) whose characteristics (voice, face, knowledge, behavior) could serve as identity signals because they were difficult to forge. That assumption was no longer safe.
A Word That May Not Fit
The series has, until this point, used the word identity without much pause. Identity meant the row in the password file, the Kerberos principal, the SAML assertion, the biometric template, the cryptographic credential held by a workload. The word stretched to cover each new case, and each new case felt like a legitimate extension of the old.
AI agents may be the case where the word stops fitting.
In earlier articles, this series borrowed Danah Zohar's quantum self to describe what authentication actually does. A person is not a single fixed identity. A person is a superposition of possible contextual selves: the employee, the consumer, the patient, the citizen, the parent, the friend. Authentication is the act that collapses the wave. When you log into your employer's systems, the instantiation that emerges is employee-you: the version of yourself the system needs to see, with the permissions and obligations of that role. When you log into Amazon, the instantiation is consumer-you, with your purchase history, your saved addresses, your preferences. The same person stands behind both. The collapsed states differ. The underlying wave is shared.
This is what made identity coherent across six decades of systems. The protocols changed. The credentials changed. The technology changed. But the structure underneath was constant: there was a person, distributed across roles and contexts, and each authentication event produced a contextual instantiation of that person, legible to a particular system at a particular moment. The audit trail was meaningful because the trail led back to the wave. The accountability was real because the person whose contextual collapse produced the action was capable of being called to account.
AI agents have no wave to collapse.
There is no person standing behind the agent's authentication event. The agent does not have an employee-self and a consumer-self and a patient-self that get instantiated as context demands. It does not have selves at all. When the agent is invoked, it is instantiated from nothing, runs for a few seconds or a few minutes, takes actions, and terminates. The next invocation of "the same agent" is not the same wave collapsed differently. It is a different process, with a different context window, with no continuity of self to the previous one. There is no superposition. There is only execution.
What identity has presupposed, beneath all the protocols and assertions and collapsed states, is agency. To have an identity is to be the kind of thing that can choose, intend, commit, and answer for what one has done. The wave that collapses is the wave of an agent: someone whose contextual instantiations are different facets of a coherent self that wants things, decides things, and bears the consequences. Even service accounts, the limit case from Part IV, inherit agency by proxy: the code was written by someone, deployed by someone, given permissions by someone, and the chain of agency leads back, eventually, to a person whose collapsed state authorized the service's existence.
AI agents look like they have agency. They appear to choose. They appear to reason. They produce outputs that, examined in isolation, seem indistinguishable from the products of an agent making decisions. But the appearance is doing work the underlying mechanism does not support. A language model does not want anything. It does not prefer one outcome over another. It does not have a stake in what it does. It generates the next token, and the next, and the next, conditioned on its training and its context, and the resulting trajectory, when it succeeds, looks like the trajectory an agent would have taken. The likeness is not the thing.
If identity presupposes agency, and presupposes a wave to collapse, and the entity in question has neither, then calling it an identity may be a category error. Not a small one. The kind of category error that builds infrastructure on a foundation that won't hold the weight.
This matters because the identity stack is not just a set of protocols. It is a set of assumptions about what the protocols are for. Audit trails exist because there is someone to be held responsible. Authorization decisions exist because there is a self whose intent the system is honoring. Authentication itself exists because there is a person whose claim to be a particular instantiation needs to be verified against the wave from which that instantiation was drawn. Each of these assumptions weakens when the entity in question is doing something that resembles intent without having intent, exercising something that resembles authority without being capable of bearing responsibility, claiming to be a particular agent without there being a wave behind the claim.
The series has documented before how language outlives the conditions it was designed for. The word password once referred to a spoken phrase exchanged between a human and a human guard. We carried it forward into a world where the guard is a function and the phrase is a hash, and the word survived because the underlying logic (a shared secret used to gate access) remained coherent. Identity is being asked to make a similar leap, but without the same continuity. The shared secret persisted across the password transition. The wave, and the agency that gave identity its meaning, may not persist across the AI transition.
It is possible that we are using the word identity for AI agents not because it fits but because we have nothing better. The infrastructure was built around the word. The protocols are named for it. The compliance frameworks invoke it. We extend the word to a new case because the alternative is to admit that we do not yet know what we are dealing with, and admitting that would slow the deployment of systems that are being deployed regardless.
The honest answer, in 2026, is that we do not yet know what to call what an AI agent has. Whatever it is, it is not nothing. The agent does take actions. The actions do have consequences. Some account of what authorized those actions, traceable to something or someone, has to exist for the resulting world to be governable. But naming that account identity may be the same kind of provisional move that early web designers made when they reached for the word cookie to describe a new and strange thing, knowing the word didn't fit but having no better one ready.
The identity stack is being extended into territory where the central word may itself be the wrong tool. Whether a better word emerges, or whether identity simply absorbs the new meaning the way password absorbed hashing, is an open question. What is not open is the fact that something is being built, deployed, and depended on in the meantime, under a name that may not deserve it.
Emerging Frameworks
No standard exists in 2026 for AI agent identity. The space is pre-standardization, analogous to web identity in the mid-1990s, when every site implemented its own account system and the federation protocols that would eventually bring order were still years away.
Early approaches are emerging. Some frameworks issue agent identity tokens that encode multiple layers of information: the agent itself (its model, version, and provider), the delegating user (whose authority the agent exercises), the scope of delegation (what the user authorized the agent to do), and constraints (time limits, resource limits, escalation policies). These tokens are, in effect, a composite identity, not a single answer to "who are you?" but a structured answer to a more complex question: "What are you, who authorized you, what can you do, and what are your limits?"
The concept of a "chain of authority" is developing: a cryptographically verifiable trail from the user's authorization through the agent's instantiation to the specific action being taken. If the agent books a flight, the chain records: the user authorized travel booking, with a spending limit, through a specific agent platform, using a specific model, and the agent selected this specific flight based on these specific criteria. The chain doesn't just establish identity. It establishes provenance, the full context in which an action was taken.
Industry groups are beginning to work on standards. The OpenID Foundation has chartered working groups exploring agent authentication patterns. Anthropic's Model Context Protocol, introduced in 2024, defines a structured way for models to access tools and data sources, with an identity and authorization layer that is still evolving. Cloud providers are building agent identity primitives into their platforms. But these efforts are early, drafts and proposals and proof-of-concept implementations, not deployed standards.
The parallels to earlier moments in this series are exact. In the mid-1990s, the web had a stateless protocol, a billion users arriving, and no agreed-upon way to identify them. The result was a chaotic period of improvisation (cookies, session tokens, proprietary login systems) that eventually resolved into standards (SAML, OAuth, OIDC) through years of competing proposals, failed specifications, and hard-won consensus. The AI agent identity space is in the equivalent of 1996. The standards will come. They will take longer than the optimists predict and arrive sooner than the pessimists fear. And they will, inevitably, be shaped by the expedient solutions that fill the gap in the meantime.
The pattern holds: the expedient solution beats the correct one. Every time.
The State of Digital Identity (2026)
Taking Stock
Six and a half decades from CTSS to AI agents.
In Article 4, the series identified three forms of digital identity that the web had produced: institutional credentials (government-issued, employer-issued, the identity assigned to you by an authority), user-created accounts (the email-and-password pairs you create yourself, the identity you construct), and behavioral shadow profiles (the identity inferred from your data trails, constructed about you without your explicit participation). Those three forms remain the organizing framework. Each has evolved.
Institutional credentials are, for the first time, going meaningfully digital. The European Union's eIDAS 2.0 regulation, adopted in 2024, mandates that every EU member state offer a Digital Identity Wallet to its citizens by the end of 2026: a smartphone application that holds government-issued identity credentials (national ID, driver's license, health insurance, educational qualifications) in a format that can be verified digitally. The first national wallets are rolling out as this article is being written, with varying degrees of feature completeness and varying levels of citizen adoption. The United States is further behind but moving. Mobile driver's licenses (mDLs) conforming to the ISO 18013-5 standard are available in a growing number of states, accepted at TSA checkpoints and, increasingly, by private-sector verifiers.
The vision of a government-issued digital credential, as portable and universally accepted as the physical ID card in your wallet but verifiable cryptographically rather than visually, is closer to reality than at any previous point in the series. But adoption remains uneven. The EU wallet is launching unevenly across member states. US mDLs are available in some states and accepted by some verifiers. The gap between the specification and the lived experience of an average citizen is narrowing but still real. The user who can present a verifiable digital credential to a bank, an airline, a telecom provider, and a government agency without friction, without fallback to physical documents, without confusion, exists in pilot programs and early-adopter cohorts but not yet at population scale. Institutional digital identity is no longer a construction site. It is a building with the framing complete and the interior under active fit-out.
User-created accounts, the billion-account problem from Article 4, are better managed than they were a decade ago, but far from solved. Password managers have grown from niche tools to mainstream products, but a majority of users still don't use them. Passkeys offer a path beyond passwords, but adoption is early and uneven. "Log in with Google" and "Sign in with Apple" reduce the number of accounts a user must manage, but at the cost of platform dependency. The average internet user in 2026 still has dozens of accounts, still reuses passwords across some of them, and still occasionally gets locked out of something important because they can't remember which email address they used to sign up.
Behavioral shadow profiles, the third form of identity, the one constructed without your participation, have been reshaped by regulation. The GDPR, the CCPA, and their progeny have not eliminated behavioral tracking, but they have constrained it. Cookie consent banners, opt-out rights, data deletion requests, and the threat of substantial fines have altered the calculus for data collectors. Apple's App Tracking Transparency framework, requiring explicit user opt-in before cross-app tracking, reduced the data available to advertisers significantly. Google's halting, on-again-off-again deprecation of third-party cookies in Chrome reshaped the advertising technology ecosystem even before full implementation.
But the behavioral shadow has not disappeared. It has concentrated. The entities best positioned to build comprehensive behavioral profiles are the platforms that don't need third-party cookies because they have first-party data at scale: Google, Apple, Amazon, Meta. The regulation that constrained the ecosystem of small trackers and data brokers strengthened the position of the platforms whose relationship with users was direct. Concentration follows convenience, and it follows regulation, too, when the cost of compliance is easier to bear at scale.
The arrival of generative AI has added a new dimension to the behavioral shadow. The prompts a user sends to a language model, the documents they paste in for summarization, the questions they ask, the topics they explore, are all behavioral data of a kind the previous generation of trackers could only have dreamed of. A search query is a fragment of intent. A multi-turn conversation with an AI assistant is a transcript of reasoning. The model providers who hold those transcripts hold a form of behavioral profile more intimate than anything cookie-based advertising ever produced. The regulatory frameworks built for the cookie era are being asked to govern data that is qualitatively different in kind, and the asking is going slowly.
The Recurring Patterns
Looking back across the full arc of the series, the patterns that emerged in earlier articles have not just persisted. They have intensified.
The expedient solution beats the correct one. BeyondCorp was the correct architecture. The VPN was the expedient one. Passkeys are the correct authentication method. Passwords are the expedient one. SPIFFE is the correct approach to service identity. API keys stored in environment variables are the expedient one. At every layer of the identity stack, the technically superior solution is available, documented, and demonstrably better. At every layer, the faster, cheaper, easier approach dominates in practice. The gap between best practice and common practice has been a constant of this series, from plaintext password files in 1961 to unrotated service account credentials in 2026.
Concentration follows convenience. Passkey custodianship concentrates in Apple, Google, and Microsoft, not because of a conspiracy but because users store their credentials where it's easiest, and the platform-native keychain is easiest. AI agent platforms concentrate in a handful of providers, not because alternatives don't exist but because the most capable models are offered by the largest companies. The identity stack at every layer gravitates toward concentration, driven by the same force that made "Log in with Google" the default: the user will always choose the path of least resistance, and the provider with the most users can offer the least friction.
The user refuses to be their own system administrator. Decentralized identity (Self-Sovereign Identity, Verifiable Credentials, blockchain-based DIDs) offered a technically beautiful alternative to the concentration problem: identity credentials held by the user, in a wallet the user controls, shared selectively with verifiers, with no central authority to depend on or be compromised. The architecture was elegant. The user experience was not. Managing cryptographic keys, understanding credential schemas, evaluating trust frameworks: these are system administration tasks, and the average user will not perform them. The same usability gravity that killed OpenID 1.0, which also put the user in control and asked them to manage their own identity, works against decentralized identity. The EU Digital Identity Wallet may succeed where earlier efforts failed, precisely because it is not purely decentralized. It is government-issued, platform-managed, and backed by regulatory mandate rather than user initiative.
Security and usability remain in tension. Passkeys may be the first technology in this series' timeline that genuinely resolves the tension for a specific use case (login authentication) by making the most secure option also the most convenient. But the tension persists everywhere else. Zero Trust architectures impose friction: continuous authentication, step-up challenges, device compliance checks, each adding security at the cost of user experience. Service identity governance requires developers to manage secrets, rotate credentials, and scope permissions, tasks that slow down deployment. AI agent authorization models that require human approval for permission escalation reintroduce the bottleneck that agents were supposed to eliminate. The tension is not resolved. It is relocated, again and again, to each new layer of the stack.
The question "who authenticates the authenticator?" never gets a final answer. In Article 1, the operating system authenticated the user. But who ensured the operating system was trustworthy? In Article 3, the KDC issued tickets. But who authenticated the KDC? In Article 5, the identity provider asserted identity to relying parties. But who verified the identity provider? In Article 6, the biometric sensor verified the user. But who verified the sensor's integrity? In Article 7, the platform syncs your passkeys. But who governs the platform? The AI agent acts on your behalf. But who verifies that the agent is faithfully representing your intent, when the agent has no intent of its own to be faithful to? The trust regression problem, the infinite regress of "but who authenticates that?", has been present since the first article and has no terminus. Every identity system rests on a foundation of trust that is itself unverified, or verified by another system that is itself unverified. The chain has to end somewhere, and where it ends, there is an assumption, an act of faith dressed up as architecture.
What's Actually Different
The patterns recur. But not everything is repetition. Several things about the identity landscape of 2026 are genuinely new, structural changes without precedent in the series.
Identity is the security perimeter. This is not a metaphor. It is the literal architecture of enterprise security in 2026. For sixty years, identity was one layer in a defense-in-depth model: the network provided one layer, the physical facility another, device management another, identity another. The loss of any single layer was survivable because the others compensated. In a Zero Trust, cloud-native, remote-work world, identity is no longer one layer among many. It is the load-bearing wall. If the identity layer fails, if authentication is bypassed, if authorization is misconfigured, if credentials are compromised, there is no secondary layer to catch the failure. The network won't save you because the network doesn't enforce trust. The building won't save you because nobody's in the building. Identity systems now carry a weight they were not originally engineered to bear, and the consequences of their failure are correspondingly larger.
Non-human identities outnumber human identities by orders of magnitude. This is not a future prediction. It is the current state. The identity systems, governance frameworks, compliance requirements, and security tools that the industry built over decades were designed for a world where the entities being managed were humans, thousands or tens of thousands per organization. The entities being managed now are workloads, services, functions, containers, IoT devices, and automation pipelines, hundreds of thousands or millions per organization. The identity problem has changed not just in degree but in kind. The governance model built for HR-driven lifecycle events (hiring, role change, termination) does not map onto orchestration-driven lifecycle events (container spin-up, autoscale, deployment, teardown) that happen thousands of times per hour.
AI agents have introduced entities that don't fit existing identity categories. A human is authenticated as a human. A service is authenticated as a service. An AI agent is what? It reasons like a human but scales like a service. It acts with apparent autonomy but on delegated authority. It makes decisions but lacks the agency that would let it bear responsibility for them. It is neither the user nor the application. It is a new kind of entity, occupying a space between the two that the identity stack has no category for, and as Part V argued, may not even have the vocabulary for. The protocols, the token formats, the authorization models, the audit frameworks were all designed for a world that contained two kinds of entities: people and programs. The third kind has arrived, and the infrastructure is improvising.
The body is part of the identity stack in ways that are irreversible. Article 6 traced this in detail: fingerprints, faces, irises, voice patterns, biometric data woven into authentication at the hardware level, stored in secure enclaves, used billions of times daily. This cannot be unwound. The smartphone has made biometric authentication the default for billions of people, and no plausible future involves returning to a world where the body is not part of how identity is verified. The irreversibility creates unique risks (a compromised password can be changed, a compromised biometric cannot) and unique governance challenges that will persist for as long as digital identity exists.
Regulation has arrived. For the first three decades of digital identity's history, from CTSS through the early web, identity operated in a near-regulatory vacuum. The systems were built by engineers, adopted by organizations, and used by individuals without much legal oversight of how identity data was collected, stored, shared, or used. Sectoral regulations emerged in the late 1990s and early 2000s (HIPAA in 1996, GLBA in 1999, SOX in 2002), each imposing identity requirements on specific industries, but the broader landscape remained largely ungoverned. That era is over. GDPR, CCPA, eIDAS 2.0, Executive Order 14028, and dozens of sector-specific and jurisdiction-specific regulations now constrain how identity systems operate in the general case, not just in regulated industries. Identity is no longer a purely technical problem solved by engineers. It is a legal, political, and social problem in which technical architecture is one input among many. The answer to "how should identity work?" is determined as much by legislators and regulators as by protocol designers and engineers.
The Open Questions
This series has traced six and a half decades of digital identity history without pretending that the story has an ending. It doesn't. The questions that remain open in 2026 are not loose threads to be tidied. They are the defining challenges of the next era.
Can passkeys actually kill the password? The technology works. The user experience is superior. The security properties are transformative. But the password survived the introduction of Kerberos, the invention of public-key cryptography, the deployment of biometrics, and the creation of federation protocols. It survived because it is universal, because it requires no special hardware, because it works everywhere, and because the cost of supporting it is low. Passkeys must displace not just the password's function but its ecosystem: the password reset flows, the account recovery processes, the compliance frameworks, the user expectations built up over six decades. The password may die. But this series has documented enough failed password replacements to counsel humility about predictions.
Who governs non-human identity at internet scale? The compliance frameworks are extending to cover service accounts and workload identities, but the tooling and practices are immature. The gap between the number of non-human identities and the organization's ability to manage them is growing, not shrinking, as cloud-native and AI-native architectures proliferate. The breach that finally forces industry-wide action on non-human identity governance, the way the ChoicePoint breach forced action on consumer data protection, the way SolarWinds forced action on supply-chain security, may not have happened yet. Or it may have happened and not yet been discovered.
How do you authenticate an entity that can impersonate a human convincingly? Voice cloning, deepfakes, AI-generated text: the tools of synthetic impersonation are improving faster than the tools of detection. The identity stack's implicit assumption that human characteristics (voice, face, knowledge, behavior) are reliable identity signals is being undermined. The arms race between synthesis and detection resembles the arms race between password cracking and hashing, but with higher stakes and fewer clear defensive advantages.
Can decentralized identity overcome the usability barrier? Self-Sovereign Identity, Decentralized Identifiers, Verifiable Credentials: the technical standards exist. The vision of user-controlled identity, free from platform dependency, is compelling. But OpenID 1.0 had a compelling vision too, and it failed because it asked too much of users. The EU Digital Identity Wallet, backed by regulatory mandate and government issuance, may thread the needle by providing the user-empowerment benefits of decentralized identity within a managed, institutional framework that doesn't require users to become their own system administrators. Or it may join the long list of technically sound identity systems that couldn't overcome the gravity of convenience.
What does identity mean when the entity isn't human? This is not a question about protocols or token formats. As Part V argued, it is a question about whether the word identity still names the right thing when applied to entities without agency, without continuity of self, without anything to be a stake in their own actions. The arrival of AI agents has forced the question into the open. The answer has implications not just for authentication architecture but for legal liability, regulatory compliance, and the social contract that identity systems embody. Whether the word survives the transition, or whether something new is needed to describe what AI agents have, is a question this series cannot answer because the answer has not yet been decided. It is being negotiated, in real time, by engineers shipping code, regulators drafting rules, and lawyers arguing cases that will set the precedents for everything that comes next.
Crossroads
In 1961, Fernando Corbató needed to give each researcher a private set of files on a shared computer. The solution was a password: a secret string, typed at a prompt, compared against a stored copy. It was the simplest possible answer to the simplest possible question.
Who are you?
The question echoed forward through six decades. It was asked by mainframes and minicomputers, by Kerberos KDCs and LDAP directories, by web servers and browsers, by SAML identity providers and OAuth authorization servers, by fingerprint sensors and facial recognition cameras. Each generation of technology answered the question with greater sophistication: hashed secrets, cryptographic tickets, signed assertions, federated tokens, biometric templates locked in silicon. The answers grew more secure, more convenient, more mathematically elegant. But the question never changed.
Neither did the relationship behind it. The machine asked, and the human answered. The entire identity stack this series has traced was built around that exchange, and assumed it would hold indefinitely.
Now something has shifted. Not in the machines. In us.
We have begun delegating. Email triage to an AI assistant because the inbox is overwhelming. Scheduling because the calendar logistics are tedious. Booking, research, comparison shopping, customer service interactions, the long tail of digital errands that fill the modern day. Each delegation feels like a convenience. Each is justified by the same logic that has justified every prior identity convenience this series has documented. It is easier, and people will always choose the path of least resistance. The machine still asks who you are, but increasingly the entity answering is not the person. It is something acting in the person's name.
The standards bodies and regulatory frameworks have responded by focusing on the agent. What is it? How do we credential it? How do we fit it into an infrastructure built for people? These are reasonable operational questions. But they are not the first question, and treating them as the first question leads us somewhere false.
The agents have no intent. They have no agency in any morally meaningful sense. They are not emerging presences developing an independent claim on the digital world. They are mirrors, extraordinarily powerful ones, reflecting back what we have put into them. Our text, our preferences, our accumulated decisions about what the digital world should optimize for. The question of what the agents are is, underneath everything, a question about us. What did we build? What did we encode? What version of ourselves are we sending out to act in our name?
That reframing changes what is actually at stake. The concern is not that we will have to reckon with a new kind of entity challenging our understanding of identity. The concern is that we will not reckon with ourselves, and the mirror will keep getting larger, and what it reflects will be the flattened, credentialed version of human identity that the infrastructure has been quietly constructing for sixty years.
Because that is what the infrastructure actually did. It answered who are you with increasing technical sophistication, but the sophistication was always reductive. You are your attributes. You are your verified claims. You are the sum of your authenticated sessions and your role assignments and your persistent identifiers. The identity stack was built to process identity, not to understand it. And somewhere along the way, through the convenience and the friction reduction and the small delegations accumulating into large ones, we started accepting the processed version as adequate. The profile became a stand-in for the person. The credential became a stand-in for the self.
CAPTCHA saw this coming before most of us did. Since the late 1990s, every challenge asking are you human? was already an admission that the infrastructure could not tell. Not because the bots were sophisticated, but because the signals the infrastructure used to identify people were always imitable by anything patient enough to imitate them. The infrastructure was never measuring humanness. It was measuring compliance with a protocol. We called it identity and moved on.
What AI makes visible is how much was always missing from that account.
The agents can hold credentials, maintain sessions, execute the authenticated actions that constitute a digital presence. They can do this continuously and at scale. And so the systems on the other side of those transactions are beginning to optimize for them rather than for us. The web designed for a person to navigate becomes scaffolding around a machine-to-machine substrate where the actual work gets done. The infrastructure built to give humans a digital presence becomes the infrastructure through which humans deploy digital proxies.
There is no them in this story. There is only us, reflected back.
The fork ahead is not between humans and machines, coexisting or clashing. It is a quieter choice, and it belongs entirely to us. We can accept what the infrastructure has built and keep moving forward inside it, letting the agents multiply, letting the delegations deepen, treating the processed and credentialed version of ourselves as close enough to the real thing. Or we can treat this moment as a reason to stop and ask what we actually think identity is, before the new infrastructure locks in around whatever answer we happen to be living by default.
The second response requires something no standards process can provide. It requires the interior work to happen before the exterior architecture is set. To ask not just how we credential an agent but what we think we are delegating, and why, and what it would mean to get that back. To notice that reducing identity to attributes and sessions and role assignments was a choice the infrastructure made, not a truth it discovered. To remember that the word friend had a richer meaning before a platform reduced it to a count and a button, and that identity has a richer meaning than anything a certificate can bind.
The hopeful reading is that the delegation creates space for that work. Handing the digital errands to agents returns to us the time and attention we have been spending there. It opens the possibility of reconnecting with what the digital was always a poor substitute for. The physical world. The people we share rooms and meals and years with. The experience of being a person among people in a world that does not require you to log in.
But that reclamation is not automatic. You can give people back their time and they fill it with a different kind of distraction. The question is not whether the agents take on the work. It is whether we, holding the time the work once consumed, remember what to do with it.
The protocols will be drafted. The standards will emerge. The people doing that work will mostly be thinking about the next deployment and the next compliance deadline, which is how infrastructure has always been built.
The deeper question belongs to the rest of us, and it is not a new one. It was deferred in 1961 when the password answered who are you and everyone accepted that and moved on. It has been deferred at every step since. The question is what identity actually is, not how to encode it or delegate it or credential the things that act in its name, but what it consists of before any infrastructure touches it.
We are being asked that question again, more urgently than before, by a mirror that has gotten very large.
The machine still asks: Who are you?
For the first time in sixty years, that might be worth sitting with.
