Your Agent Is Logged In as You
Your Agent Is Logged In as You
Open the audit log of any system your agent touched last week. Your name is on every line.
Not the agent’s. Yours. The GitHub commit is authored by you. The calendar invite came from you. The API call carried your token, the file was written by your user, the email went out from your address. If something in that list was wrong — sent to the wrong person, deleted from the wrong folder, retried three times against a non-idempotent endpoint — the record says a human did it, and the human is you.
This is not a misconfiguration. It is how nearly every agent stack in production works today, and almost nobody has decided it should be that way. It is simply the path of least resistance: the agent needed access, you had access, so it borrowed yours.
How the borrowing happens
Look at where an agent’s authority actually comes from and the pattern is the same at every layer.
At the shell, the agent runs as your Unix user. It inherits your home directory, your SSH keys, your sudo rights, your cloud CLI sessions. Anything you can do from a terminal, it can do, and the process table shows your UID.
At the API layer, it holds your OAuth token. You clicked “Allow” once, in a consent screen that offered two options — everything or nothing — and the agent has been presenting that token ever since. The service on the other end cannot tell the difference between you and the thing acting as you. By design, it is not supposed to.
In the browser, it drives your logged-in session. Cookies, saved passwords, the tabs you left open. To every site it visits, it is you.
Each of these is defensible in isolation. The agent has to run as something; it has to authenticate as something. But stack them and you have built a system in which a non-human actor performs consequential actions across a dozen systems while every one of those systems records a person.
What breaks
The first thing that breaks is the question “who did this?” — which sounds academic until you are asking it at two in the morning.
A production incident happens. Something was changed. The change log names an engineer. The engineer says, truthfully, that they did not make that change; they were asleep; they had an agent running a maintenance task. Now you have a record that is wrong in the most load-bearing field a record has, and no way to know how many other entries in the log share the defect. Every incident review that follows starts with an investigation into whether the people named in the logs were actually there.
The second thing that breaks is revocation. When the agent does something it shouldn’t — and we have written about why instructions are a weak control against that — the correct response is to pull its access. But it doesn’t have any. It has yours. Revoking the token revokes you. Rotating the key locks you out. The only way to take authority away from the agent without taking it away from yourself is to have given it separate authority in the first place, and you didn’t, because nothing offered to.
The third thing is scope. Because the agent borrows your identity, it borrows all of it. You did not give it permission to read your email so it could schedule a meeting; you gave it your Google session. The task needed one calendar write. The token grants everything you have ever been allowed to do. We’ve argued that authority should be granted per capability, narrow and typed; identity borrowing is the exact opposite — it is the maximally broad grant, made by default, to an actor that cannot be distinguished from you afterward.
The fourth thing is blame, and it is the one people feel first. When the record says you did it, you did it. Organizations run on their records. A compliance regime that asks “which individual authorized this transfer?” gets your name. A security review that asks “who accessed this data?” gets your name. Agents have been added to the system and accountability has not moved an inch — it still lands entirely on the human whose credentials happened to be lying around.
The delegation problem has a name, and a partial answer
None of this is new to identity people. Acting on someone’s behalf is an old problem with real solutions. The OAuth token-exchange specification, RFC 8693, defines a way to mint a token that says “this actor is acting for this subject,” so a downstream service can see both parties. NIST’s digital identity guidelines are built around the idea that a subject is a distinct thing that can be identified, authenticated, and held to account.
The machinery for “the agent is a principal, acting on behalf of a person, with authority the person delegated” exists. So why does almost no agent stack use it?
Because every piece of it is optional, and it lives in the wrong place. It lives in each service, each API, each integration — which means it exists only where some team happened to build it, in whatever shape they happened to choose. One SaaS product has service accounts with scoped permissions; the next has a single personal token. The shell has no concept of “a process acting for a user” beyond sudo’s one-line log entry. The browser has no concept of it at all. An agent that wants to be properly attributed has to negotiate a different arrangement with every system it touches, and the default when no arrangement exists is: borrow the human.
Attribution, like receipts, is a property you get from the structure of a system or you don’t get at all. You cannot ask the agent to log who it is — that is an instruction, and instructions are not controls. You cannot rely on each downstream service to have built delegation — most haven’t, and the agent’s task doesn’t wait for them to. The property has to be produced by whatever layer sits between the agent and every consequential action it takes, so that it is true everywhere, by construction, without anyone remembering to arrange it.
What the correct arrangement looks like
Strip the problem to its shape and the arrangement is not mysterious.
The agent is its own principal. It has an identity distinct from any human’s. Logs that record it, record it. When it runs as a process, the process belongs to the agent; when it holds a credential, the credential names the agent.
Every action carries two names. The agent that acted, and the human on whose behalf it acted. Not one or the other — both. “Alice’s deploy agent, acting for Alice” is a record you can reason about. “Alice” is a record that is wrong. “deploy-bot-7” with no link back to Alice is a record that cannot be held to anyone.
Authority is delegated, scoped, and separately revocable. The human grants the agent specific capabilities, not a copy of themselves. Pulling the agent’s authority leaves the human’s intact. Narrowing it to one calendar does not require trusting the agent with the inbox.
The arrangement is enforced at the point of action. Not in a policy document, not in a system prompt, not in the goodwill of each downstream service. Wherever the agent’s intent becomes an effect on the world — a file written, a request sent, a command executed — that seam is where identity is attached and scope is checked. If every consequential action has to pass through one mediating layer anyway, that layer is where attribution belongs, because it is the only place that sees every action.
That last point is why we think this is an operating-system problem, not an application one. Applications can each solve it for themselves, and a few have. But the agent doesn’t live in one application. It lives on the machine and reaches into all of them. The only layer with the same reach is the one underneath.
Where we are, honestly
MagenticOS is in alpha, and the rule we hold ourselves to is that aspiration and shipped capability never share a sentence. So, plainly: the thesis above is the thesis we are building toward — every consequential action passes a typed broker, so the broker is where an action picks up its actor and its scope. What the alpha ships is the runtime, that broker, and a reference shell. What the full arrangement looks like across a whole distro is later work, and we will say so when it is real rather than when it is designed.
In the meantime the diagnostic is free and worth running on whatever you have. Pick one system your agent touched this week. Open its log. Find the action. Read the name on it.
If the name is yours, you don’t have an agent identity problem someday. You have one now, and your records are already wrong.