User Identity: the access model for multiplayer AI

When you use AI on your own, the question of identity is boring. The agent is you. It reads what you can read, writes what you can write, and every action it takes is your action. There is one human, one set of permissions, one log.

The moment a second human shows up in the same conversation, that simple picture is supposed to break. A possible answer is to give the AI its own identity — its own account, its own credentials, its own per-channel access profile — and have it act as itself. Call it agent identity.

We think that's the wrong turn, taken for the right reasons. The fix for multiplayer isn't to invent a new actor with its own privileges. It's to keep the agent acting as the specific human who is driving it, right now — and to make that hold no matter how many people are in the room. Call it user identity. This is the model PromptQL has shipped from day one, and below is why we think it is the only model that is actually multiplayer.

"Act as the user" doesn't break down — "act as itself" does

The case for giving the agent its own identity rests on two forces. We agree both are real. We just think they argue for the opposite conclusion.

Increasing autonomy. As agents do more on their own — overnight runs, scheduled jobs, reacting to events — the worry is that there's "no user in the loop" to borrow authority from, so the agent needs standing credentials of its own. But an autonomous run isn't author-less. Someone scheduled it. Someone wrote the trigger. The correct identity for a 3am job is the human who set it in motion, carried forward — not a free-floating service account that answers to no one. The instant you give the agent its own credentials, you haven't solved the autonomy problem; you've created an account with broad access and no human attached to its actions.

Multiplayer teams. When ten people share one agent in one channel, giving each interaction a different person's permissions sounds complicated, so the tempting shortcut is to give the agent one identity and one access profile for the whole channel. But that shortcut is exactly where "multiplayer" quietly dies. If the agent has a single fixed set of permissions, then every one of those ten people is really sharing one login. That's not ten people collaborating with AI. That's ten people behind a shared service account. The thing that makes it multiplayer is precisely that the agent's authority changes depending on who is talking.

So yes — autonomy and teams break the naive picture. They break agent identity. User identity is what survives them.

The agent acts as you

In the user-identity model, the agent never has credentials of its own to a customer's systems. There is no bot account to provision, no API token sitting in the agent waiting to be misused, no "what can the assistant see" that's separate from "what can this person see."

When you ask the agent to do something, it does it as you. When your teammate asks it the next thing in the same thread, it does that as your teammate. The agent is a lens, not an actor. The rule is simple enough to hold in your head: if you can't see it, the agent can't see it for you. There is no side door, because there is no second identity to be the side door.

This is the inverse of the agent-identity pitch. There, the selling point is that the agent has no personal credentials of yours, so you can't be impersonated. True — but it solves that by giving the agent credentials of its own, which everyone in the channel then shares. We remove the shared credential entirely. The only identity in play is the real human currently driving.

Inheriting permissions, not reinventing them

The most underrated cost of agent identity is the new permission system it forces you to build. Someone has to sit down and define, per channel, what this agent is allowed to touch — a second, parallel access-control scheme that lives next to the one your company already runs in Okta, in your database grants, in your SaaS roles. Now you maintain two, and they drift.

User identity inherits the permissions you already have. The agent connects to your existing identity provider, takes the claims it issues for the human in the seat, and enforces them — at the context layer (which wiki, which rooms this person can see) and, crucially, at the data layer (which tables, rows, and columns this person is allowed to query). Nothing new to provision. The access map is the one your security team already designed and already audits. Onboard a person, off-board a person, change their role — the agent's behavior changes with them automatically, because there was never a separate profile to keep in sync.

How user identity works

Agent identity asks: what is this agent allowed to do in this compartment? It's a deliberate departure from per-user access control — a new, coarser unit of permission attached to the assistant.

User identity asks the only question that was ever the right one: what is this human allowed to do? It isn't a departure from per-user access control. It is per-user access control, applied live, at the moment of every action. The agent computes the answer freshly for whoever is speaking, against that person's real permissions, on every single request.

The boundary is the person, not the channel

This is the heart of the disagreement. Agent identity makes the channel the unit of permission: everyone who can post in a room inherits whatever the agent can do there, regardless of what each individual is actually entitled to. A channel is a conversation boundary. It was never designed to be a permission boundary, and quietly promoting it into one is how someone with no access to a system ends up reading from it anyway — through the agent — in a way even its defenders concede is "unusual."

User identity makes the person the boundary. Authorization follows whoever is driving, and it switches the instant the driver changes. If you start a task and a teammate jumps in mid-thread, the agent re-scopes to your teammate's permissions for their turn, then back. The conversation is shared; the authority is not. Membership in a room lets you talk. It grants you exactly nothing you couldn't already do yourself.

Right-sized by construction, not pared back from over-grant

Because agent identity can't know who will speak, it has to provision for the union of everyone — grant the agent broad access up front and then, the advice goes, watch the audit logs and pare it back over time. You start over-permissioned and hope to converge downward. That's backwards, and it's never actually done.

User identity is right-sized on the first request and every request after, with no tuning. Each person already carries exactly their own access — no more, no less — so the agent is automatically least-privilege for whoever is using it. There's no generous default to walk back, because there's no shared grant in the first place.

No special case for DMs

It's telling that the agent-identity model has to carve out an exception for direct messages: in a private 1:1, it quietly reverts to acting as your individual account and your permissions — because in a DM, obviously, the agent should be you. That's user identity, reintroduced the moment the channel abstraction becomes indefensible.

We just don't have the exception. A DM and a busy shared room work identically: the agent always acts as the specific human it's responding to. The model that needs a special case to stay coherent in the one setting where the answer is obvious is telling you what the right default was all along.

Security and audit that hold up under a real team

Two properties fall out of user identity for free, and both are hard to retrofit onto agent identity.

Permissions the model can't argue its way past. Access isn't enforced by prompting the LLM nicely; it's enforced deterministically at the data layer, below the model, where no clever instruction can reach. We can do this natively because we built the security-first data-access layer first — the same engine that serves regulated data at companies like Meta, Apple, UnitedHealth, and JPMorgan Chase — and put the AI on top of it. Security here isn't a wrapper bolted around a chatbot; it's the foundation the chatbot stands on.

Every action attributed to a real human. When the agent reads or writes, the log shows the person it acted for — not a bot account that launders ten people's actions into one ambiguous identity. Under agent identity, "who actually did this?" resolves to the assistant, and you reconstruct intent from channel membership. Under user identity, the answer is already a name. For anyone who has to answer an auditor, that difference is the whole game.

What's next: multiplayer artifacts

Once identity is settled, the interesting frontier isn't more identity machinery — we already have all of it. It's what a team can make together with a shared agent.

The next chapter of multiplayer AI is multiplayer artifacts: shared dashboards, to-do apps, trackers, little interactive tools — built collaboratively in the flow of a conversation and owned by the team, not by one person's laptop. PromptQL already supports this, and it falls out of the architecture rather than being a feature we bolted on. Every thread — including the ones you have over Slack — is just a conversation on our cowork app. So any thread can produce and host a live artifact that the whole team reads, edits, and acts on, with each person's permissions still enforced underneath.

That's the payoff of getting identity right first. When the agent acts as each real human, a shared workspace can be genuinely shared — collaborative artifacts and all — without ever becoming a shared login.