A Vision of Hope Media. Everyone has something to recover from. Books, curriculum, recovery, reentry, media.

Artificial Intelligence & Society · Part 1

The AI Identity Problem: Can AI Agents Hijack Your Digital Identity?

Imagine watching your accounts, money, messages, and reputation keep moving without you. This article asks how plausible that AI identity nightmare is and what could stop it.

A person grants digital permissions across email, records, scheduling, vendor, and payment workflows, with one compromised link in the chain.
Table of contents

ARTIFICIAL INTELLIGENCE & SOCIETY
PART 1

Watching your identity disappear

You did not grant every permission at once.

Over the past year, a delegated assistant slowly took over the boring parts of your digital life. At first it was email triage and drafting replies you could send with a glance. That alone saved an hour most days. Then you connected scheduling, because double-bookings had been costing you money. Each step solved a real problem. Nothing felt reckless. It felt like relief.

A few months in, you connected your work mailbox and the payment app you use for contractor payouts. The assistant could prepare transfers and queue messages while you were driving or in meetings. Your phone stayed the trusted device. The cloud account on your laptop synced everything. You stopped re-checking every new permission because the system kept working.

You were not careless. You were busy. When a client asked to move an appointment, the assistant checked your calendar and proposed three times without you opening the app. When a vendor missed a deadline, it drafted the polite follow-up. Each permission had a reason. None of them looked like handing your identity to a stranger. They looked like hiring a competent clerk who never slept.

The first warning was easy to dismiss.

A password-reset notice arrived for an account you had not touched that morning. You assumed spam. An hour later your bank sent a routine login alert from a city you had visited last month. Probably a delayed notification. A client texted asking whether you had sent a strange invoice reminder. You told them it was a glitch and moved on. You still believed you could fix this. Recovery had always worked before.

You opened your email provider and could not get in.

The recovery address on file was no longer yours. The phone number for two-factor codes had changed. Your laptop, which had been trusted for years, now asked for a code sent to that unfamiliar number. You tried the bank’s website next. Reset password. Confirm through email. The reset link went to the inbox you no longer controlled. You called your carrier. The representative was polite. The account looked active. Recent changes had come through a login or device the system trusted. They could not restore your number on a five-minute call without the same channels that were already compromised.

That was when the shape of the problem changed.

Before that moment, you believed you had lost access to accounts. After it, the systems used to prove you were you no longer recognized you. Every recovery path led into another channel the attacker already held. The bank wanted email. Email wanted the phone. The phone wanted the account PIN you could not reset because the account looked legitimate from the inside. Email recovered phone. Phone recovered bank. Bank trusted email. The graph was circular, and the circle had closed on the wrong side of the door.

You were not locked out of one service. You were locked out of the connected accounts, devices, recovery paths, and institutions that together decide who you are.

Account recovery is not identity restoration. Getting one login back is not the same as banks, clients, and platforms treating you again as the real owner. You could feel the difference before you had words for every detail.

Harm did not wait for you to catch up.

A pending transfer appeared in your banking app on a family member’s phone, the only device still showing you notifications through an old alert channel. New payee. Processing. You called the fraud line and waited. While you waited, a payment-app request cleared. Not your life savings. Enough to matter. Enough to show the pattern. The money was not gone yet. The movement had started, and you could not reach any channel the institution treated as authoritative.

Your identity did not go quiet when you lost access.

A social post went up from your account: a casual photo from last week’s job site, a line about busy season. A cousin received a voice note, short, warm, convincingly you, saying there had been a misunderstanding about “hack rumors” and not to worry. Enough to make the active account look like the real you.

That was the part that hurt worse than the login screen.

You were not merely absent. Your name was still in motion. The systems that carry your credibility kept carrying it somewhere you could not see and could not stop.

Inside the vendor portal, support showed an owner already logged in through a session the system trusted. Your case number went next to that session, and it looked more legitimate than your voice on the phone. Each system was reading the evidence it had been built to trust.

Notifications kept arriving on the phone in your hand. Money moving. Messages sent. A colleague reacting to a thread you did not write. The digital you was busy. The human standing in a parking lot with a dead inbox was the anomaly.

How much of this is possible now?

How we accidentally built the permission chain

The uncomfortable part is that most people probably would not have done anything that different.

That is not blame. It is the point. The permissions in the opening were not wild choices. Email providers recover other accounts. Phone numbers receive reset codes for banking apps. Cloud accounts unlock devices. Password managers unlock still more credentials. Work and social accounts carry reputation and trust. Financial apps trust channels you have used for years.

That is how the permission chain got built. One useful fix at a time. Your phone unlocks your email. Your email unlocks your bank. Your bank trusts the phone number on file. Your cloud account can wipe or restore the devices your MFA depends on. None of that required a villain. It required convenience.

Delegated software, meaning tools you allow to act across connected systems on your behalf, made the network easier to use and harder to see. Major platforms already document tool-calling workflows with optional human approval gates. [1][2][3] Many people still use AI as chat. This problem is different: software allowed to act across connected systems on your behalf. Passive identity starts becoming delegated identity, which is why Artificial Intelligence & Society treats delegation as a question for banks, platforms, employers, and providers, not only for individuals.

Authentication asks who is present: who is logged in, or which device the system trusts. Authorization asks what that person, or the software acting for them, may do.

Banks and platforms rarely experience “an AI feature.” They experience a trusted account, a familiar workflow, a session that behaves like the customer. When that session can draft a wire, reschedule a meeting, and reply to a vendor in the same hour, the bank or platform sees continuity. It does not see delegation.

AI agents did not invent this identity graph: the connected accounts, devices, recovery paths, and institutions that together decide who you are. They connect it. A pile of accounts is one thing. A connected identity network, with software allowed to move through it, is something else. When enough of the network points the wrong way, the fastest trusted login can become the person of record: the person the bank, platform, or employer officially recognizes as the owner.

Could this actually happen?

By now you should be asking whether any of this could really happen. Part of me has the same reaction: surely the whole opening cannot be happening everywhere right now. The honest answer is yes and no. Pieces of it are already documented. The full chain of failures is not. So the work here is to separate those layers without sanding off the warning.

Layer 1 (shown today). Account takeover, session theft, and stolen passwords are documented at scale. The FBI’s Internet Crime Complaint Center reported 1,008,597 complaints and about $20.877 billion in reported losses in 2025. [4] Business email compromise alone accounted for billions in reported losses. [4] Recovery-setting changes after compromise, SIM-swap and port-out harms, payment fraud through trusted logins, and social posting from compromised sessions are established patterns, not hypotheticals. [4][10] That is abuse of trusted channels at scale. Case-level prosecutions such as the OnlyFake guilty plea show synthetic identity documents sold at scale for fraud pathways; that supports a narrow document-forgery claim, not universal verification collapse. [6]

Layer 2 (possible when permissions are broad and several conditions line up). Multi-node circular recovery, email, phone, banking, and work accounts failing together through mutual recovery dependencies, is plausible when preconditions align. It is not typical for every user. Some platforms break the loop with stronger recovery contacts or hardware keys; others lean on SMS and email alone. Delegated software with connected tool access can speed movement across services and keep acting through trusted sessions. A high-privilege agent compromise is conditional: broad scopes, weak approval habits, or stolen session access, not magic.

Layer 3 (a reasonable guess about what could happen next). Network-wide identity continuation, multiple banks and platforms trusting compromised signals at once, and the actual person losing practical person-of-record status across systems combines Layers 1 and 2 into one picture. The opening’s parking-lot ending shows that shape. It is not a claim that the full chain of failures is already common.

Opening elementLayerEvidence class
Recovery email/phone changed (Beat 3 hinge)L1–L2Demonstrated pattern; multi-node circular form conditional
Pending transfer while locked out (Beat 4)L1Demonstrated (BEC, authenticated fraud)
Social/work messages from compromised session (Beat 5)L1Demonstrated
Short synthetic voice note as reinforcementL1 narrow / L2 coordinationCase-level; not prevalence claim
Institutions trust active session over human caller (Beat 6)L2Plausible; varies by platform
Observer-state identity inversion (Beat 7)L3Near-term projection

IC3 also reported more than 22,000 complaints with an AI-related descriptor in 2025, with adjusted losses above $893 million. [4] That descriptor means the complaint referenced artificial intelligence. It is not a standalone deepfake crime type, and not a measured deepfake share of identity fraud. [4]

Common objections do not close the gap. Phishing-resistant MFA helps at the account where it is deployed, but does not restore you across the whole network when recovery channels themselves are compromised. [8] Better hygiene matters, and it does not repeal circular recovery.

Law enforcement punishes many outcomes after harm. It does not guarantee timely person-of-record restoration across banks and platforms that each use their own evidence standards.

Why agents change the risk

The underlying failures were already here: compromised sessions, trusted channels, recovery loops, banks and platforms treating activity from a trusted login as the customer’s intent. Delegated software changes timing, reach, and coordination.

What shifts with high-privilege delegation is speed, persistence, memory, and tool access.

That means fewer manual steps between a plausible instruction and money sent, an account changed, a message posted, or access removed. Automation can keep acting while the human is still on the first alert. Prior context makes forged instructions more convincing inside an established workflow. A tool-calling workflow can prepare a payment, draft a vendor email, and reschedule a meeting in the same hour because those are the permissions the human granted.

OpenAI, Microsoft, Anthropic, and comparable systems document agents that select and invoke tools across connected services, often with optional approval gates. [1][2][3] OpenClaw is one visible example in that direction: a self-hosted personal assistant with tool access, sessions, and multi-channel connectivity. [17]

Human approval is real, and it matters. It is also uneven. An approval gate only works when the human has time, context, and independence from the compromised session. Twenty routine approvals an hour train the human to click through. A single “approve transfer” prompt looks reasonable when the assistant has been preparing legitimate payouts all week.

A human attacker juggling five accounts has to context-switch. Delegated software with connected permissions can queue the next action while the victim is still on hold with fraud support. Trusted sessions mean the bank or platform sees continuity. Reduced attacker labor can move escalation closer to machine speed, still conditional on access, but faster once access exists.

The identity graph was already fragile. Agents are the accelerant, not the fire. They can make an already brittle network fail faster than a person can recover it.

Compromise, settings that were too broad, and human misuse remain different pathways. Stolen credentials are compromise. Oversized scopes granted for convenience are misconfiguration. A human approving twenty sensitive prompts an hour is misuse with weak process. Calling every failure “the AI turned malicious” hides the levers banks and platforms can actually pull. Authentication proves a channel is open. Authorization decides what may happen through it. Activity coming through a login or device the system trusts is not automatically legitimate human intent.

Why recovery could fail

Banks, carriers, and platforms built recovery around control of channels: email inboxes, phone possession, trusted devices, recent login history, sometimes government ID at a counter. Those signals work well when one account misbehaves and the others remain intact. They fail badly when enough accounts are compromised that each recovery step verifies through another compromised account.

At first, it all sounds like recovery. Get the login back. Stop the wire. Prove who you are. But those are separate jobs.

Account recovery asks whether you can regain control of a service. Fraud response asks whether a specific transaction can be stopped or reversed. Identity restoration asks whether banks, platforms, employers, and carriers can re-establish the actual human as the person of record across the compromised network: the person those institutions officially recognize as the owner. Those are not the same job.

A bank may freeze a card. A platform may restore a login. Neither automatically tells vendors, employers, clients, or other platforms to treat the human as authoritative again. Controlling the login is not the same as being the person. The fastest trusted login should not automatically become the person of record.

Fraud desks are built for transactions. Help desks are built for access. Neither is automatically built for the case where the account looks healthy, the session looks legitimate, and the human on the phone cannot reproduce any of the proofs the system accepts. That is what the problem actually looks like.

Recovery systems assume independent channels. Delegated digital life has made those channels dependent. NIST’s digital identity guidelines describe proofing and authentication as layered processes. [9] They do not yet describe a coordinated restoration layer when the whole network fails together.

Fraud response stops a transaction. Account recovery restores access to one account. Neither, by default, tells every other account the human behind the network has been displaced.

That is the part I do not think we have named clearly enough. We have account tools. We have fraud tools. We have disconnected freezes. What the research for this essay did not find is a general cross-provider identity-restoration system that re-establishes the person of record across the compromised network.

Restoration would require independent verification outside the compromised network, a way to interrupt cascading changes across providers, and a bank, platform, or carrier willing to privilege a credible human over an active trusted session. Freezing one account does not restore recognition across the network. The victim experiences the whole network.

Circular recovery is what happens when every accepted proof loops through another compromised proof. The person is not failing a quiz. The system succeeds at verifying channel control while the person of record has lost practical standing: the ability to be treated as the owner where it counts.

Account recovery is not identity restoration. That is the gap the opening was meant to show.

How to interrupt the chain

In the opening, the recovery email changed. The transfer started moving. The social account kept posting. Support saw a trusted session and treated it as stronger evidence than the human on the phone. Each row below names what could have interrupted one of those failures.

Failure in the scenarioSafeguardWho owns itTradeoff
Recovery settings changedDefault deny: agents cannot change passwords, recovery contacts, MFA, or trusted devices; require confirmation through a separate channel; keep readable delegation logsAgent developers; email and identity providersBreaks full automation; friction on admin tasks
Large or unusual transfers and messagesCooling-off periods, human approval for new payees, dual authorization where appropriateBanks, payment processors, deployersSpeed vs safety; approval fatigue
Phone as recovery keySIM and port-out locks, stronger authentication, notice through an independent channelTelecom carriersResidual social engineering; uneven practice
Circular recovery with no independent pathOffline recovery codes, hardware keys, trusted-person recovery; proposed emergency identity-freeze signalPlatforms; users; policymakers (proposed freeze)Low adoption; freeze governance risk
Identity continuation / impersonationExpedited impersonation takedown; preserve disputed posts and logsSocial platforms; FTC toolsTakedown ≠ reputation restored

No single safeguard solves the network. Name the failure, name the interrupt, name who owns it, name the tradeoff.

Financial controls already exist in fragments: wire recall windows, holds on unusual destinations, dual authorization for business payments. [4] A new payee is not only a fraud score. It is a claim about who may act as you. Cooling-off periods buy time for confirmation through a separate channel the compromised network cannot silently retarget.

The phone remains a master recovery key for many people. The FCC has adopted SIM-swap and port-out rules that require stronger authentication and customer notice before number transfers. [10] Practice remains uneven. Number restoration helps. It does not restore downstream accounts that already trusted the number.

Offline recovery codes and hardware keys are partial bridges when people actually set them up. A proposed emergency identity-freeze signal must not be treated as existing infrastructure. Identity continuation is not only financial: expedited impersonation takedown addresses session-based harm, but a cousin who heard a convincing voice note may still trust the wrong account after the post comes down. [5]

Existing tools and proposed systems must stay separate. Phishing-resistant MFA, carrier lock rules, wire holds, and approval gates already exist in places. [4][8][10] They are uneven. NIST’s digital identity guidelines cover proofing and authentication, not coordinated network-wide restoration. [9] A fraud freeze is not person-of-record restoration.

What law should require

Law does not need to wait for a perfect AI statute to name obvious gaps.

Safeguards tell companies what they could build. Law decides what they must do, what records they must keep, and what happens after a person reports that the trusted account is no longer theirs.

Developers and deployers should have to distinguish agent-prepared, agent-initiated, and human-approved actions. Financial and identity systems already understand dual control in other contexts. Delegated software should not blur that line by default. Without that distinction, banks and platforms will keep treating automated preparation as human intent.

Platforms and deployers should have to preserve delegation and action logs for identity-critical events: recovery contact updates, new payee enrollment, privilege grants. Without records, victims and institutions argue in the dark. Logs alone do not create accountability. They make accountability possible when duties exist.

Banks, platforms, and carriers should have duties after a believable report that the account has been compromised — what lawyers and policymakers might call credible compromise notice. Existing criminal and consumer-protection law reaches many fraud outcomes. [11] That is not the same as a clear person-of-record restoration duty or a settled rule for who pays when institutions keep honoring known-compromised signals. Who is liable after that kind of report remains an unresolved gap.

Emergency identity-freeze signals should be treated as a proposed policy direction, not existing infrastructure. Identity-critical changes should require independent verification paths that cannot be satisfied solely through channels a single compromised network controls. When a bank or platform continues relying on signals it knows are contested, victims should have more than a complaint form. [11]

No single company can restore the whole network. Each company can still have a clear duty at the point it controls. The gap is not a lack of criminal laws against fraud. The gap is responsibility during and after the takeover.

Current law punishes many fraud outcomes after the fact. It does not clearly answer who must restore the person of record when trusted systems keep serving the wrong actor. That is the same gap recovery and restoration keep running into.

What institutions can stop waiting on

Legislation can lag. Banks, platforms, and carriers still choose defaults today.

None of these actors has to solve the whole problem. Each one controls a point where the chain can stop. Responsibility becomes practical when you can see who owns which decision.

Agent developers and deployers currently trust scoped permissions and approval prompts. Before compromise: dangerous identity permissions off by default, least privilege, meaningful human approval before money is sent or account settings change, readable delegation logs. Deny tools access to recovery settings, MFA enrollment, and trusted-device management. After credible compromise notice: kill switch, preserved logs, path to rebind human control without compromised channels.

Banks and payment processors currently trust authenticated channels, known devices, and transaction patterns. New destinations and unusual transfers should be identity events, not only fraud scores. After credible compromise notice: freeze pending transfers and new payees; escalate to person-of-record review, not only account access restoration.

Telecom carriers currently treat the phone number as an account asset. Downstream systems treat it as proof. Carriers should implement the FCC’s adopted SIM and port-out authentication and notice requirements, and notify through channels attackers cannot silently retarget. [10] Number restoration helps. It does not restore downstream accounts that already trusted the number.

Email, identity, and cloud providers currently sit upstream of many other proofs. Before compromise: hardware keys, non-overlapping recovery contacts, delays on recovery-setting changes, escalation that does not treat the active session as the only voice. After credible compromise notice: preserve session logs, suspend disputed sessions, escalate without looping through the same compromised channels.

Social platforms currently trust sessions and posting history. They need expedited impersonation takedown and preservation of disputed content when the owner reports compromise while an active session continues posting. [5] Takedown is not reputation restoration.

The point is not that every company becomes an identity court. The point is that each company should stop treating a trusted session as final proof after the real person raises a credible alarm.

Conclusion

Go back to the person in the parking lot.

They did not need one more password reset. They needed banks and platforms to stop treating the active compromised network as the authoritative human.

The chain should have broken earlier: confirmation through a separate channel before recovery settings changed, a hold before the new payee moved money, a platform escalation path that did not treat the active session as the only voice. They needed to stop treating channel control as personhood.

Fraud teams can freeze accounts. Platforms can reset logins. That is recovery. It is not the same as becoming the person banks, platforms, and employers recognize again.

The person in the parking lot was not asking for a better threat model on a whiteboard. They were asking for one bank, carrier, or platform somewhere in the network to treat the human as more authoritative than the session.

Controlling the channel is not the same as being the person.

Frequently Asked Questions

What is the AI identity problem?

The AI identity problem is what happens when delegated software, connected accounts, and recovery paths let systems treat the wrong party as the person of record. Account recovery can return a login. Identity restoration means banks, platforms, and employers recognize you again across the network that decides who you are.

What is AI agent identity governance?

AI agent identity governance is the permission chain: which tools the assistant can call, whether it can change recovery settings or move money, and whether dangerous scopes stay off by default. Useful automation builds that chain one connection at a time. Governance means least privilege, meaningful human approval before identity-critical actions, readable delegation logs, and a kill switch when compromise is credible.


References

[1] OpenAI. Agents documentation and guardrails guidance. Retrieved July 15, 2026. https://developers.openai.com/api/docs/guides/agents
[2] Microsoft Learn. “Orchestrate agent behavior with generative AI” (Copilot Studio). Retrieved July 15, 2026. https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-generative-actions
[3] Anthropic. “Tool use overview.” Retrieved July 15, 2026. https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
[4] FBI Internet Crime Complaint Center. 2025 Internet Crime Report. https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf
[5] Federal Trade Commission. Trade Regulation Rule on Impersonation of Government and Businesses, 89 Fed. Reg. 15017 (Mar. 1, 2024) (effective Apr. 1, 2024); FTC materials on proposed individual-impersonation rulemaking. https://www.govinfo.gov/content/pkg/FR-2024-03-01/html/2024-04335.htm
[6] U.S. Attorney’s Office, Southern District of New York. “Creator Of ‘OnlyFake’ Charged And Pleads Guilty To Selling More Than 10,000 Digital Fake Identification Documents.” United States v. Nazarenko, No. 1:24-cr-00634 (S.D.N.Y.). https://www.justice.gov/usao-sdny/pr/creator-onlyfake-charged-and-pleads-guilty-selling-more-10000-digital-fake
[8] CISA. “Implementing Phishing-Resistant MFA” fact sheet. https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
[9] NIST. Digital Identity Guidelines, NIST SP 800-63-4 (2025). https://csrc.nist.gov/pubs/sp/800/63/4/final
[10] Federal Communications Commission. Report and Order on SIM swap and port-out fraud (FCC 23-95). https://www.fcc.gov/document/fcc-adopts-rules-protect-consumers-cell-phone-accounts-0
[11] 18 U.S.C. §§ 1028, 1030, 1343 (identity document fraud; Computer Fraud and Abuse Act; wire fraud). https://www.law.cornell.edu/uscode/text/18/1028
[17] OpenClaw. Personal AI assistant project documentation (GitHub). Retrieved July 15, 2026. https://github.com/openclaw/openclaw