A shared agent can look collaborative long before I would trust it.
Put two people in the same session. Give them the same transcript. Let them watch the same terminal, steer the same agent, or ask the same bot questions. The collaboration surface is clearly shared.
The authority model might still be a mystery.
Who is acting when the agent invokes a tool? Whose credentials apply? Does “owner” mean responsibility, access, or actual control? Can one participant approve an action another participant started? If two people give conflicting instructions, which one wins? If an authorized user retrieves private information, can the result appear in a room visible to people who could not retrieve it themselves?
Those are not edge cases around the collaboration feature. They are the contract underneath it.
Shared context is not an authority model.
The current products in the source record do not converge on one answer, and I do not think they need to. OpenClaw separates creator, owner, participants, visibility, and operator scopes inside one trusted Gateway boundary. AQ shares the live workspace but makes active terminal control something the owner delegates. PromptQL documents per-human authorization switching, so the bot acts with the permissions of the person who asked. Microsoft's Agent Host Protocol puts authoritative state, turn ordering, confirmation arbitration, cancellation, and reconciliation in the host.
Different mechanisms. Same operator problem.
Before I rely on a shared agent workflow, I want its authority rules to be explicit enough that I can inspect them before something consequential happens.
Start with principals, not just users
The first question is who the system believes is participating.
That sounds trivial until one person can occupy several roles at once. A human might be the creator of a session, its current owner, a participant who can observe, the person whose message triggered a turn, the account whose credentials authorize a tool call, and the approver of the resulting action.
Those roles can all belong to the same person. A trustworthy design should not depend on that always being true.
OpenClaw's current multi-user documentation is useful here because it separates several of them. Creator identity, when known, is immutable. Ownership is assignable responsibility rather than an access-control primitive. Participant history is separate again. Changing the owner does not automatically change sharing authority, and operator scopes remain a separate action control.
The same documentation also draws a hard boundary around what that model means: a shared Gateway is still one trust domain for sessions, tools, credentials, and files. It is not hostile-user isolation.
That distinction is exactly the kind of thing I would want visible. “Owner” is a reassuring word. It is not useful if I cannot tell what power the word actually carries.
Visibility needs the same precision.
PromptQL documents a model where the bot acts as the person who asked and switches permission scope when another person asks. Sharing the bot does not automatically share one user's connected-data access. But its documentation also notes a separate boundary: a response posted into a shared chat is visible to everyone who can see that chat, even when some participants could not have accessed the original source.
So there are two questions, not one:
- Who may retrieve the source?
- Who may receive the result?
A system can get the first one right and still leak across the second.
Access to the agent is not authority to use every capability
The next distinction I would look for is between entering the workspace and exercising the agent's capabilities.
Shared access can mean observing a session, sending a message, taking over a terminal, invoking a tool, using a credential, approving a write, cancelling active work, or changing persistent state. Those powers have very different consequences.
AQ takes a deliberately narrow approach. Teammates can see the same live workspace, but typing into another person's terminal requires a control request that the owner approves. Multiplayer does not mean unrestricted simultaneous steering.
That matters because “everyone can collaborate” is otherwise easy to translate into “everyone can act,” even when the product never intended those to be the same permission.
A public PrimeClaws discussion gives a useful limiting example from the other direction. When someone asked whether member permissions extended to per-user tool controls, the PrimeClaws account said the permissions were not currently that granular and were mainly around the container or VPS surrounding the agent. That is community/vendor evidence, not independent security documentation, but the distinction is still useful: access to an agent is not automatically authority over every connected tool.
The same separation appears around credentials. PromptQL documents per-user authorization for connected data and tools. A Lark/OpenClaw plugin discussion shows the implementation pressure that appears when one deployment is expected to hold multiple people's user-scoped credentials: trust-boundary expansion, key blast radius, token lifecycle, revocation, consent, and governance all become part of the design.
That issue is plugin-specific. I would not generalize it into a claim about OpenClaw as a whole.
I would generalize the question, though:
Whose authority is the agent borrowing when it acts?
Dream Atlas has already treated agent capability as something that needs a containment contract. A shared agent adds another layer to the same problem. It is not enough to bound what the runtime can reach. The system also has to make clear which human principal is allowed to exercise that reach.
Permission and approval are different controls
A user can be permitted to perform an action and still need approval to perform this action now.
I would want those layers separated too.
Permission answers whether an actor is generally allowed to invoke a capability. Approval answers whether a particular consequential action should proceed under the current circumstances.
DevRev's current material describes identity-scoped actions, approval gates, audit, and reversibility as parts of its enterprise agent model. Those are first-party claims, not independently validated guarantees. I would treat them as examples of the control surface an operator should inspect rather than proof that one vendor has solved it.
A useful authority contract should make the approval rule answerable:
- Which actions require confirmation?
- Whose confirmation counts?
- Is the approval attached to a person, a role, a session, or a specific action?
- What happens if approvals conflict?
- Can an approval be withdrawn before execution?
The exact mechanism can vary. The ambiguity should not.
Conflict needs an ordering rule, not model intuition
The second human also creates a timing problem.
If two people can act on one persistent state, something has to decide what happens when their inputs overlap. The system can serialize turns, delegate control, branch state, queue actions, reject conflicts, or permit constrained concurrency.
The current evidence does not establish that one of those models is universally correct.
What it does show is that leaving the rule implicit is a bad foundation for trust.
Microsoft AHP makes the coordination layer unusually explicit. The host owns authoritative shared state, sequences mutations, allows one active turn per chat, exposes turn ownership, arbitrates tool confirmation so the first confirmation wins, sequences cancellation, and reconciles optimistic client updates against server ordering.
That is a technical design, not evidence of a broadly deployed industry standard. It is useful because it shows how many separate decisions are hiding inside the phrase “shared session.”
AQ answers some of the same coordination pressure by delegating active control rather than allowing everyone to type freely. Again, different mechanism. The important part is that the rule exists.
Historical OpenClaw operator evidence is useful here, but only with the version boundary intact. Issue #96477 described session-lock pressure and later message-delivery failures in a multi-user production setup on v2026.6.10. Later repository review says the old physical session-write lease was removed in a shipped refactor. Current same-session work remains serialized, but the old message-loss behavior is not established on current main.
The safe conclusion is not “OpenClaw loses messages when several people use it.” The safe conclusion is that real multi-user concurrency exposed operational pressure serious enough to change the implementation.
Coshell's Overlap feature is another good boundary case. It addresses concurrent file-edit detection and steering in a shared workspace. That tells me something about file-state conflict. It does not tell me that conflicting human instructions, credentials, approvals, or tool permissions are solved.
“Conflict” is not one thing.
For a shared agent, I would want to know at least four things:
- How are turns or actions ordered?
- Who can interrupt or cancel active work?
- Which state becomes authoritative after overlapping changes?
- How are participants told that an action was queued, rejected, reordered, or superseded?
I would also want those rules outside the model whenever they are load-bearing.
The 2026 preprint Multi-User Large Language Model Agents treats shared-agent use as a multi-principal problem and reports weaknesses under conflicting objectives, privacy constraints, and coordination demands. It is a benchmark/stress-test paper, not production validation of any named product. What it supports is narrower: I would not make “the model will infer whose instruction should win” the authority mechanism when the system can encode the rule deterministically.
Attribution is not just a display name
Once the agent can act, the authority contract also needs to preserve who caused what.
A message label is not enough.
OpenClaw notes that turn attribution can become best-effort when steering merges new input into active work. AHP treats turn ownership and state sequencing as host responsibilities. DevRev describes audit and reversibility controls around agent actions.
These examples cover different layers, but the operator question is the same: after a consequential action, can I reconstruct which principal requested it, who approved it, what actually executed, who changed or interrupted it, and what state resulted?
That matters for accountability. It also matters for recovery.
If a system claims an action is reversible, I would want to know what “reversible” covers. Does it undo the external side effect, restore internal state, reverse both, or merely create a compensating action? Who is allowed to request the reversal? What happens to later work that depended on the state being changed?
The current source set does not independently validate vendor reversibility guarantees, so I would not treat any product's answer as settled. I would still insist that the question has an answer.
Output disclosure belongs in this same part of the contract. An authorized retrieval can be perfectly valid for the requester and still produce an invalid disclosure if the result lands in a room with a broader audience.
The agent needs to know more than whether it may act, but it also needs a rule for where the result may land.
The authority contract I would require
I do not mean a literal document with twelve boxes every product must implement in the same UI.
I mean that, before extending trust, I should be able to get explicit answers to these questions:
- Identity: Which human or system principal is attached to each request, approval, tool call, state change, and output?
- Visibility: What may each participant see in the session, its sources, intermediate state, and results?
- Ownership: What does “owner” mean here: responsibility, access, authority, coordination, or some combination?
- Action authority: Who may actively steer the agent, start a turn, or mutate shared work?
- Credential scope: Whose credentials are used for reads and writes, and how are they selected, stored, revoked, and rotated?
- Tool permission: Does access to the agent imply access to every connected capability, or are tools scoped separately?
- Approval: Which actions require confirmation, whose confirmation counts, and what happens when approvals conflict?
- Concurrency and ordering: What is serialized, queued, branched, rejected, or allowed in parallel?
- Interruption and cancellation: Who may stop current work, and how is cancellation sequenced against actions already in flight?
- Attribution and audit: Can the system reconstruct who requested, approved, executed, changed, or interrupted a consequential action?
- State consistency: Which copy of shared state is authoritative, and how are concurrent or optimistic changes reconciled?
- Output disclosure: After an authorized retrieval or action, who is allowed to see the result?
A product does not need to expose all of this in one settings screen. Some answers may live in protocol semantics, workspace roles, service policy, credential boundaries, or host behavior.
The standard I care about is simpler:
The authority rule should exist, be inspectable at the level the operator needs, and be proportionate to what the agent can do.
A shared research assistant with read-only access to low-risk material does not need the same contract as an agent that can deploy code, spend money, message customers, modify production data, or act through personal credentials.
Explicitness should scale with consequence.
These are old controls in a new composition
None of this requires pretending agents invented access control.
Roles, credential scoping, queues, locks, approvals, audit logs, and cancellation semantics are established systems ideas. The agent-specific problem is the composition.
One conversational surface can now retrieve private context, invoke external tools, retain memory, edit persistent work, request approvals, and accept instructions from several human principals. That pulls controls that used to live in separate systems into one interaction loop.
It also explains why simple answers are incomplete.
“Use per-user credentials” helps with data and tool authorization. It does not automatically answer who may see the output, who can approve a write, how two people's requests are ordered, or whether one participant may cancel work another participant started.
“Allow only one active human” does not avoid the authority problem either. It is an authority model. AQ's delegated control and AHP's serialized turns are both examples of constraining concurrency deliberately.
The requirement is not maximum simultaneity, maximum permission granularity, or one preferred protocol.
It is knowing what the rule is before the rule matters.
Trust the contract, not the multiplayer surface
The current evidence supports an operator framework, not a vendor ranking.
It does not establish that one architecture is generally superior. It does not establish broad adoption, a settled shared-agent category, mature cross-domain standardization, or independently verified security across the products above.
That is fine. I do not need consensus on the architecture before I can ask for legible authority.
If several people are going to depend on the same agent state, I want to know who can act, what they can see, whose credentials the system borrows, how consequential actions are approved and ordered, who can stop them, how the resulting state is reconciled, and where the output is allowed to go.
A collaboration surface tells me that people can share the room. The authority contract tells me whether I should trust what can happen inside it.
// End of transmission. Trust needs explicit authority — ZYANE