User-authorized Multiplayer AI

Single-player AI doesn't raise hard identity questions. The agent acts as you: it reads what you can read, writes what you can write, and every action it takes is attributable to you. One person, one set of permissions, one audit trail.

Multiplayer AI — several people working with one agent in a shared conversation — forces a question single-player never asks: when the agent acts, whose authority does it use? There are two ways to answer it.

Self-authorized (agent identity). The agent has an identity of its own: its own account, its own credentials, and one access profile that applies to everyone in the channel. People share the agent's access.

User-authorized. The agent has no credentials of its own. It acts as the specific person driving it, with that person's permissions, and re-scopes when the driver changes.

This page describes the user-authorized model in enough detail to evaluate a product against it, or to build one. PromptQL implements it; the building blocks below are what to look for either way.

The difference is where credentials sit, and there are two distinct points where they're needed. The agent reads shared context to answer a request — that read has to be authorized. The agent also writes code, and the code's execution calls tools (queries, integrations, side effects) — those calls have to be authorized too. In the self-authorized model, a single static credential held by the agent authorizes both, so the people behind it are interchangeable. In the user-authorized model, the agent holds no credential of its own; the acting person's credential authorizes both the context read and the code's tool calls.

Three building blocks of user-authorized AI

The model rests on three controls, each applied per request to whoever is driving.

1. Access control on context

The agent's shared context — knowledge base, rooms, threads, artifacts — is permissioned per person. When the agent assembles context to answer a request, it retrieves only what the acting user is allowed to see; answering a different teammate, it retrieves a different slice. The workspace is shared for collaboration without widening any individual's read access.

2. Access control on data and tools

Every query the agent runs against a connected system, and every tool or side-effecting action the agent-written code invokes, is authorized as the acting user — at the data layer (tables, rows, columns) and at the tool/integration layer (which integration, which action). These permissions are inherited from the identity provider and data grants already in place, rather than defined in a separate, agent-specific scheme. A useful thing to check when evaluating an implementation: whether enforcement happens in the model's prompt, or below the model where it can't be bypassed.

3. User-configurable approvals

Sensitive reads and side-effecting actions can require explicit confirmation from the driver, with graduated scope: allow (this action), allow for this run (the rest of the task), or always allow (remember the choice). Approvals are per user, so the person who authorized an action is the one accountable for it.

What the model affects

The choice between self- and user-authorized shows up along three axes.

User experience

Under user-authorized, each person's agent operates with that person's own access, not a profile sized for the whole group. There's no need to reduce the shared agent to a lowest-common-denominator set of permissions to keep it safe, and no path for one person to reach data they otherwise couldn't. A 1:1 and a shared room behave the same way: the agent acts as the person it's responding to.

Governance

User-authorized adds no second permission system to maintain alongside the identity provider and existing data grants. Provisioning, role changes, and off-boarding take effect automatically, because there's no agent-specific profile to keep in sync. Access is scoped to the acting user on every request, rather than granted broadly up front and narrowed later based on observed usage.

Security and audit

Two properties follow from enforcing the acting user's permissions below the model. First, access decisions don't depend on the LLM following instructions — they're enforced deterministically at the data layer. (PromptQL runs this on a data-access layer originally built for regulated data at companies including Meta, Apple, UnitedHealth, and JPMorgan Chase.) Second, each action is attributed to a specific person in the audit log, rather than to a shared agent account that several people act through. For audit and compliance, the relevant question is whether a log entry resolves to a human or to the agent.

Common arguments for self-authorized, and how they hold up

Two arguments are usually made for giving the agent its own identity. Both point at real problems; neither requires agent credentials to solve.

Autonomy. As agents run unattended — scheduled jobs, event-triggered runs — there may be no person in the loop at execution time, which is taken to mean the agent needs standing credentials. But an unattended run still has an author: whoever scheduled it or wrote the trigger. That person's identity can be carried forward to the run, keeping the action attributable. A standing agent credential instead creates an account with broad access and no person attached to its actions.

Team scale. Giving each interaction a different person's permissions seems more complex than giving the agent one profile for the channel. The tradeoff is that a single fixed profile means everyone in the channel shares one effective login, which removes the per-person authorization that makes the setting multiplayer in the first place.

Channels as a boundary. Channel membership is a conversation boundary, not a permission boundary. Treating it as one lets a participant read, through the agent, from systems they have no direct access to. It also creates a confused-deputy risk: an escalated request in a shared thread can expose data to others in the room, or be influenced by another participant's input, and execute with the agent's broad privileges. Scoping to the acting user keeps room membership about participation, not access.

Direct messages. Self-authorized implementations commonly special-case 1:1 DMs, reverting to the individual's own account and permissions. User-authorized needs no such exception, since it already acts as the individual in every setting.

Beyond identity: multiplayer artifacts

With identity handled per user, a shared agent can produce shared outputs without a shared login. Multiplayer artifacts — dashboards, trackers, to-do apps, and other interactive tools — can be built collaboratively within a conversation and owned by the team rather than an individual. Because every thread (including those over Slack) runs on the same workspace, any thread can host a live artifact that the team reads and edits, with each person's permissions still enforced underneath.