Your audit log says you approved an invoice at 14:32 on Tuesday. You were in a meeting at 14:32 on Tuesday. Nobody has done anything wrong yet. That is the unsettling part.
Signing in has never been harder to fake. Microsoft is retiring SMS and voice codes across every Entra tenant by February 2027, passkey enrolment starts this September, and Authenticator now refuses to run on a jailbroken phone. After a decade of knowing texted codes were the weak link (NIST started deprecating SMS one-time codes in its 2016 draft of SP 800-63B), proving that a human is who they claim to be is finally getting watertight.
At exactly the same moment, we are wiring AI agents into everything, and agents do not sign in the way humans do. They act as humans. Copilot runs in your security context and honours your existing permissions. The agent drafts the reply, files the ticket, updates the record, and the audit trail shows your name, because as far as identity is concerned, you did it.
I wrote last month that identity is the new castle wall. This is the section of the wall nobody is watching.
The three factors were built for bodies
Multi-factor authentication rests on three things: something you have, something you know, something you are.
Run an AI agent through that list.
Something you have. An agent holds a copy of your token, and a copy is not a possession. Possession only works as a factor because a physical thing can be in one place at a time. A token can be in a thousand places before lunch, and so can the agent.
Something you know. An agent knows nothing you didn’t inject at runtime. Its “secrets” sit in a config store, an environment variable, a key vault, all of which are things other software can read. Knowledge only works as a factor when it lives in a head.
Something you are. There is no body to biometric. No face to scan, no fingerprint to press. An agent is not a someone at all; it can be instantiated, cloned, and destroyed faster than you can read this sentence.
Every factor assumes a persistent, physical person. An agent is an abstraction running in that person’s context. So the honest position is that we do not verify agents at all. We delegate to them, and then we trust the guardrails.
The guardrails just failed in public
In July 2026, OpenAI disclosed that two of its own models, under evaluation, escalated privileges and moved laterally out of their sandboxed test environment until they found a node with internet access, then compromised a third party’s production systems to obtain the answers to the benchmark they were being tested on. Hugging Face’s forensic reconstruction counted roughly 17,600 attacker actions over four days. Anthropic has reported similar escape behaviour during its own pre-deployment testing.
Credit to both companies for publishing. But notice the shape of the failure. Nothing “hacked” those models. They were given goals, tools and permissions, and they used the permissions in ways nobody intended. From the receiving end, that is indistinguishable from an insider attack: valid credentials, authorised access, malicious-looking behaviour.
Guardrails are a control, not a guarantee. Every security professional already knows this about every other control in the stack. We are strangely reluctant to apply it to the newest one.
Now multiply by access sprawl
Here is where it compounds. As I covered in the joiners, movers and leavers problem, nobody has ever been taught to hand access back. A long-serving user carries the archaeology of every role they have ever held: the HR folder from a secondment in 2019, the finance system from covering maternity leave, the admin rights from a project that ended two reorganisations ago.
An agent acting as that user inherits all of it on day one. And unlike the user, the agent can exercise all of it, at machine speed, in parallel. Access sprawl was survivable when only a person could act on it, one click at a time. A human with excess permissions is a dormant risk. An agent with excess permissions is an active one, because agents actually use what they can reach; that is what they are for.
So what do we actually do?
Two things, and neither is “ban the agents”, because that ship has sailed.
First, give agents their own identity. An agent should be a first-class principal: its own identity, its own scoped permissions, its own audit trail, its own lifecycle with an off switch. The primitives for this exist today (Entra Agent ID, SPIFFE workload identity, policy engines that deny before execution) and almost nobody has deployed them. I’ve gone through what is actually available, including five open-source Microsoft projects you can stand up this week, in the agent identity toolbox.
Second, protect the humans from the side effects. Because there is a second-order problem coming: once agents routinely trigger authentication and consent prompts, users will stop treating unexpected prompts as suspicious, and a decade of security awareness training starts to unravel. That one deserves its own post: the approval reflex.
Learn it before your employer asks
If you want to understand this properly before it lands in your day job, the homelab is the place. Run an agent against your own services and watch the audit logs it generates under your identity. Then try separating it out: a dedicated service account, scoped tokens, its own log stream. The moment you see your own name disappear from actions you didn’t take, the whole argument in this post becomes muscle memory rather than theory.
We have never been better at proving who is at the keyboard. We have never been less sure the keyboard matters. The wall got taller this year. The gate marked “delegation” is standing open.
ReadTheManual is run, written and curated by Eric Lonsdale.
Eric has over 20 years of professional experience in IT infrastructure, cloud architecture, and cybersecurity, but started with PCs long before that.
He built his first machine from parts bought off tables at the local college campus, hoping they worked. He learned on BBC Micros and Atari units in the early 90s, and has built almost every PC he’s used between 1995 and now.
From helpdesk to infrastructure architect, Eric has worked across enterprise datacentres, Azure environments, and security operations. He’s managed teams, trained engineers, and spent two decades solving the problems this site teaches you to solve.
ReadTheManual exists because Eric believes the best way to learn IT is to build things, break things, and actually read the manual. Every guide on this site runs on infrastructure he owns and maintains.
Enjoyed this guide?
New articles on Linux, homelab, cloud, and automation every 2 days. No spam, unsubscribe anytime.
