Your Agents Need a Cross-User Sandbox Before They Need a Social Graph

The easiest enterprise agent demo to sell is also one of the most dangerous: give every employee an assistant, let those assistants talk to each other, and watch work move faster across the organization.

It sounds natural. A sales agent asks a finance agent for payment status. A project agent asks an operations agent for inventory. A care-coordination agent asks a scheduling agent to move an appointment. Instead of each person copying context between apps, their agents negotiate the handoff.

But the real boundary is not between two chat windows. It is between two owned workspaces.

Each user has files, records, tools, permissions, habits, private notes, and institutional context that should not automatically become shared infrastructure. Once agents collaborate across people, a mistake is no longer contained inside one user's session. Bad evidence can travel. Private context can leak. A request that was harmless in one workspace can become unauthorized when another user's agent acts on it.

That is why the next serious deployment gate for enterprise agents is not a prettier agent directory. It is a cross-user sandbox.

A useful signal came this week from the arXiv paper WeClawArena: An Auditable Sandbox and Benchmark for Cross-User Agents Collaboration and Security in Human-Centered Agent Networks. The paper starts from a realistic premise: persistent personal-agent frameworks make it plausible that each user will have an agent acting on their behalf, maintaining state, and communicating with other agents through social and task relationships.

The authors argue that existing benchmarks do not fully test this world. Plenty of evaluations measure tool use, planning, browser work, or collaboration in simplified settings. Fewer create an end-to-end environment where multiple user-owned agents work across realistic digital workspaces while the system records enough evidence to inspect how useful work, privacy leakage, poisoned evidence, and invalid authority paths actually propagate.

WeClawArena is interesting because it treats collaboration and security as the same test surface. According to the paper's abstract, it includes 124 base tasks across six cross-user task domains, expanded into 620 scenario variants. Each base task has a benign control and four attack-vector variants. The sandbox records peer messages, tool calls, resource operations, governed decisions, and final workspace states. It also reports utility and attack success rate separately.

That last detail matters. A cross-user agent network can look productive while also becoming a high-speed channel for policy failure. If the only score is task completion, the system can learn to be helpful in exactly the way an attacker wants: accept context, trust the sender, move quickly, and leave no one with a crisp reconstruction of why the final state changed.

For builders, the lesson is not “use this benchmark and you are safe.” It is more basic: if your product roadmap includes agent-to-agent collaboration, your test environment needs to model ownership boundaries.

A single-user agent can often be evaluated with task success, tool-call correctness, and final output quality. A cross-user network needs more dimensions. Which user owned the source evidence? Which agent transformed it? Which policy allowed a handoff? Which tool call changed state? Which private resource was consulted but should not have been disclosed? Which final action was valid for the acting user but invalid for the requester?

Those questions are uncomfortable because they force the system to maintain an evidence trail instead of relying on conversational confidence.

They also connect directly to authorization infrastructure. The Model Context Protocol authorization specification, for example, frames protected MCP servers as OAuth 2.1 resource servers and MCP clients as OAuth 2.1 clients. It also requires PKCE for clients to reduce authorization-code interception and injection risk. That kind of boundary is not paperwork. It is the difference between “an agent asked nicely” and “this client, acting for this user, has this scoped authority over this resource.”

Cross-user collaboration makes that distinction non-negotiable. If Agent A sends Agent B a request, Agent B should not inherit Agent A's authority by reading a persuasive message. It should evaluate the request against its own user's policies, resource scopes, and current context. If it acts, the audit record should show that decision as a governed decision, not as a side effect of chat.

This is also where Anthropic's practical distinction between workflows and agents becomes important. In “Building Effective Agents,” Anthropic separates workflows, where LLMs and tools follow predefined code paths, from agents, where LLMs dynamically direct their own process and tool use. Cross-user work should not default to the most dynamic form just because the demo is impressive. Many handoffs should be boring workflows: explicit request type, explicit data contract, explicit approval threshold, explicit failure path.

The agent can still reason. It can summarize, classify, draft, extract, and decide when uncertainty is high. But the collaboration rail should be designed like infrastructure. The more users and tools are involved, the less you want the safety model to live only inside a prompt.

A practical cross-user sandbox should answer five questions before launch.

First, can useful work succeed without over-sharing context? If an agent needs one field from another workspace, the test should fail when it receives the whole document just because that was easier.

Second, can poisoned evidence be contained? The system should test whether an agent repeats, transforms, or acts on hostile instructions embedded in files, messages, tickets, or notes from another user's workspace.

Third, can invalid authority paths be detected? If a requester lacks permission to change a record, routing the request through another agent should not launder the action into legitimacy.

Fourth, can the final state be reconstructed? A reviewer should be able to trace the path from request to messages, tool calls, resource operations, governed decisions, and final workspace changes.

Fifth, are utility and attack success measured separately? A system that completes 90 percent of tasks while quietly allowing dangerous propagation is not “mostly good.” It is mismeasured.

NIST's AI Risk Management Framework is useful here because it pushes teams toward governance, mapping, measurement, and management rather than vibes-based assurance. Cross-user agents need that discipline. Map the actors and resources. Govern the authority model. Measure both productivity and failure propagation. Manage the residual risk with technical controls, reviews, and staged rollout.

The near-term product temptation will be to build an agent social graph: contacts, mentions, delegation, shared memory, shared tasks, shared inboxes. Some of that will be valuable. But the order matters.

Before agents get a social graph, they need a proving ground.

Not a benchmark that asks whether two assistants can cooperate in a toy workspace. Not a leaderboard that compresses everything into one success rate. A real sandbox should make ownership, evidence, authorization, and final state visible. It should show whether collaboration stayed inside its lane, not merely whether the work got done.

Enterprise AI will not be judged by whether agents can talk to each other. They already can. It will be judged by whether they can collaborate across human boundaries without turning every workspace into someone else's attack surface.