MobSessiondocs

Security model

How access, execution, and control work in MobSession today, and the controls rolling out for teams.

This page explains where the agent runs, how access works today, who is in control, and the controls we are adding for teams. We would rather be precise than vague, so you can decide how to use it.

Where the agent runs

The agent is a real Claude Code session, and it runs on the orchestrator's own machine, in the orchestrator's repository and shell, using the orchestrator's own Claude subscription. There is no separate cloud sandbox running your code. The agent has the same access the orchestrator already has when they run Claude Code alone: the working directory, the file system, and the shell.

That is the point of MobSession, and it is why control matters. A prompt from a participant becomes input to an agent that can run commands on the orchestrator's computer.

How access works today

You reach a session through an unguessable share link of the form mobsession.ai/s/<code>. The code comes from a cryptographically secure random generator with a large keyspace, so codes cannot be guessed or enumerated in practice.

Today the link is the access control. Anyone who has the link can open the session, watch it live, and submit prompts that steer the agent. Treat the link like a secret:

  • Share it only with people you trust to drive an agent on your machine.
  • Prefer private channels over public ones.
  • End the session when you are done. The orchestrator ends a session with Ctrl+C, which stops the agent.

The orchestrator stays in control

The orchestrator runs the agent and holds ultimate control over what executes:

  • They drive from their own terminal, alongside the mob.
  • They can interrupt the current turn at any moment by pressing ESC.
  • They can end the session at any time.

Because the agent runs locally, the orchestrator is never outside the loop.

What we are adding for teams

We are rolling out controls that move MobSession from link-based access to identity-based access. These are in early access and are not generally available yet:

  • An approval gate. The orchestrator approves prompts from the mob before they run, so untrusted input does not auto-execute. See SSO and access control.
  • Verified identity and roles. SSO-backed sign-in replaces self-entered display names, with role-based access for who can join and who can steer.
  • Audit logs. A durable, exportable record of who joined, who prompted, and what ran. See Audit logs and compliance.

Until those ship, run MobSession the way you would run Claude Code with a trusted pair or mob: with people you trust, on work you are comfortable doing together.

Reporting a security issue

If you find a security problem, contact us at security@mobsession.ai or through our contact page. We take reports seriously and will respond quickly.

Related