AI Authentication: Verifying People, Agents, and Content

For most of my career, authentication answered one question: is this the right human? Get the password, the code, or the face right, and you were in. AI broke that model in three directions at once. Now I have to prove a person is real when a convincing fake of them costs a few dollars. I have to prove that the software agent making requests is the one I authorized, not a hijacked copy. And I have to prove that a photo, a voice note, or a document was actually made by who it claims, in a world where any of them can be generated on demand.

Those are three separate problems that share one word. This is my working map of all three as they stand in mid-2026: verifying people, verifying agents and systems, and verifying content. Each has real tools shipping today, and each has a gap I would not paper over.

One word, three problems

Keep these three questions apart, because the tools do not transfer between them.

• Is this person who they claim to be? The classic login problem, now under attack from synthetic faces and voices.
• Is this system or agent the one I trust? The machine identity problem, made urgent by autonomous AI agents that act on their own.
• Is this content what it claims to be? The provenance problem, made urgent because generated media is now indistinguishable from real media to the human eye.

Most confusion I see comes from treating these as one thing. A passkey proves a person controls a device. It says nothing about whether a video of that person is real. Content Credentials prove where a file came from. They say nothing about whether the AI agent uploading it is trustworthy. Solve them separately.

Verifying people when fakes are cheap

The honest starting point is that humans can no longer tell real from fake. When iProov tested 2,000 people in the US and UK in 2025, only 0.1 percent correctly flagged every real and fake sample, and people spotted high-quality deepfake video just 24.5 percent of the time. That is worse than a coin flip. So the answer is not "train users to look for glitches." The answer is to stop relying on what a screen shows and start relying on cryptography and hardware.

That is why passkeys matter more than any anti-deepfake gadget. A passkey is a private key bound to your device and unlocked by your face or fingerprint locally. There is no shared secret to phish and no code to intercept. The FIDO Alliance reported around 5 billion passkeys in active use by World Passkey Day 2026, with more than 15 billion accounts now capable of passwordless sign-in. Three quarters of consumers have turned them on somewhere. This is the one authentication shift I tell every team to prioritize, because it removes the attack that deepfakes are best at: tricking a person into handing over a credential.

Biometrics still have a place, but only with liveness detection that proves a live person is present, not a photo, a screen replay, or a generated video fed straight into the camera stream. That last case, the injection attack, is the fast-moving threat. Attackers skip the camera entirely and inject synthetic video into the verification pipeline. Entrust reported roughly a 40 percent year-over-year rise in injection attacks, and industry trackers now put deepfakes at close to one in five biometric fraud attempts. Deepfake-driven identity fraud is projected to rise several hundred percent in 2026 over 2025. My rule: treat any biometric check that runs on unverified client input as advisory, not proof. Bind identity to hardware you can attest, and keep a fallback that does not depend on the user's eyes.

Passwords have not disappeared, and that is part of the risk. Even in the FIDO 2026 numbers, one in three people still reported an account compromise or breach notice in the past year, because most accounts still allow a password fallback that phishing and deepfake social engineering can target. The move that matters is not adding another factor on top of the password. It is removing the password as an option once a passkey exists. A deepfake voice call to a help desk asking for a "reset" only works when there is a resettable secret behind the account.

Behavioral and continuous signals fill the gap between logins. Typing rhythm, how a phone is held, session and device patterns: none of these is strong enough to authenticate on its own, and I would never gate access on them alone. But as a background layer they catch the case where a valid session is hijacked mid-stream, which is exactly what an agent-driven attack looks like. Use them to raise friction and demand a fresh passkey check, not to make the call by themselves.

Verifying agents and the systems behind them

The newest problem is that a growing share of requests no longer come from humans at all. AI agents book travel, file tickets, move money, and call other services on someone's behalf. Analysts expect that by the end of 2026 roughly a third of enterprises will run agents that act independently. Every one of them needs an identity, and the human login model does not fit. You cannot give an agent a face to scan.

The mistake I see teams about to make is handing an agent a human's credential so it can "act as" that person. Do not do this. The right pattern is delegation: the human uses their passkey to grant the agent a separate, scoped, short-lived credential for one task, with a human in the loop for anything sensitive. The agent gets its own identity, never yours, and that identity can be revoked and audited on its own. No anonymous agents running in production.

The concrete version of this is playing out around MCP, the protocol agents use to call tools and data sources. An MCP server sits between an agent and real systems, which means it needs its own identity, its own scopes, and its own audit trail. When I look at an agent deployment now, the first questions are the same three every time: what is this agent's identity, what exactly is it allowed to do, and how do I revoke it in one place. If any of those answers is "it borrows a person's account," the design is wrong. Scoped and short-lived beats broad and permanent, because a leaked agent credential should expire on its own and should never unlock more than the one task it was minted for.

Underneath the agent layer, the machine-identity problem is older and better solved. SPIFFE and its SPIRE implementation give every workload a cryptographic identity (an SVID) grounded in platform attestation rather than a shared secret. The workload does not present a password. The fact that a specific process is running on a specific attested node is itself the proof, and the platform hands it a short-lived certificate. Newer work ties this to the software supply chain: a Sigstore-based attestor can require that only a container image signed by a trusted build system receives a given SPIFFE ID. That is the model I want for agents too. Identity should follow from verifiable properties of the code and its environment, not from a secret someone can copy. Confidential computing pushes the same idea into hardware, running workloads in enclaves that can attest what code is executing before you trust them with data.

Verifying content and its origin

The third problem is the one the public feels most: you can no longer trust that a photo, clip, or voice is real. Detection tools that scan a finished file for "fakeness" are a losing game, because every improvement in detection trains the next generation of generators. The durable approach is provenance: sign content at the moment of creation and carry that signature forward, so the question becomes "where did this come from" instead of "does this look fake."

The standard here is C2PA, surfaced to users as Content Credentials. It attaches a signed manifest to a file recording its origin, edits, and whether AI was involved. In 2026 this moved from demo to default in real places. OpenAI attaches C2PA metadata to generated media and is layering it with SynthID watermarking. Google verifies both C2PA credentials and SynthID across Gemini, Search, and Chrome. Most importantly, capture is going native: the Samsung Galaxy S25 and Google Pixel 10 can sign photos at the point of capture, which is where provenance has to start to be worth anything.

Regulation is pushing the same way. The EU AI Act's Article 50 disclosure rules for AI-generated content come into force in August 2026, and California's SB 942 transparency requirements took effect at the start of the year. Both assume machine-readable provenance, which is exactly what C2PA provides.

Here is where I stay honest: provenance proves origin, not truth. A signed manifest confirms who made a file and how, not that the claim inside it is accurate. And the metadata is fragile. A screenshot, a re-upload, or a platform that strips metadata on export breaks the chain, and most of the internet does exactly that. Watermarking (SynthID and its peers) survives some of that stripping but can be weakened by heavy editing. So Content Credentials are a strong signal, not a verdict. Treat a present, valid credential as evidence, and treat its absence as unknown rather than proof of fakery.

Detection tools still have a role, just a narrower one than vendors imply. Voice and video analyzers from firms working on deepfake defense can flag likely synthetics at scale, which is useful for triage in fraud and trust-and-safety pipelines. But their accuracy drops as generators improve, and a confident "this is fake" score is not something I would hang a legal or moderation decision on by itself. I treat detection as a filter that surfaces things for review, and provenance as the thing that actually establishes origin.

What I would actually do now

Strip away the taxonomy and this is the short list I give teams in 2026.

• Ship passkeys. It is the highest-leverage move against phishing and deepfake-driven credential theft, and the ecosystem is finally ready.
• Assume biometrics can be injected. Require liveness, bind to attested hardware, and never treat a client-side biometric result as proof on its own.
• Give every agent its own scoped identity. Delegate authority, do not share credentials, and keep a human in the loop for anything that moves money or data.
• Ground machine identity in attestation. SPIFFE-style identities and signed supply chains beat long-lived secrets for both services and agents.
• Adopt Content Credentials, but read them as signals. Sign what you publish, verify what you can, and design for the common case where provenance data has been stripped.

The pattern across all three problems is the same. When AI makes appearances cheap to fake, stop trusting appearances. Trust cryptography, trust hardware you can attest, and trust signed origin. Everything else is a signal, not a verdict, and the teams that keep those two categories straight are the ones I would bet on.

Common questions

Can AI detect deepfakes reliably? Not reliably enough to be the last word. Detection tools help triage suspicious media, but their accuracy falls as generators improve, so I pair them with provenance rather than trusting a fakeness score on its own.

Do passkeys stop deepfake fraud? They stop the most common path. Passkeys remove the phishable secret a deepfake voice or video is usually trying to extract. They do not verify that a video of you is real, which is a separate content problem.

What is the difference between C2PA and watermarking? C2PA attaches a signed record of a file's origin and edits, which is precise but can be stripped on upload or screenshot. Watermarking hides a signal inside the pixels or audio that survives more transformations but carries less detail. Strong systems use both.

How do I give an AI agent an identity? Mint it a scoped, short-lived credential of its own through delegation, keep a human in the loop for sensitive actions, and never let it borrow a person's account. Under the hood, attestation-based identity like SPIFFE beats long-lived secrets.