Sharing AI work across a team gets messy fast.
One person writes a good prompt, gathers the context, gets partway through. Then someone else needs to continue. So fragments get pasted into Slack, screenshots get sent, a conversation gets exported, or an account is left signed in for the next person.
The collaboration isn't the problem. The handoff is. Most AI tools assume one person, one account, one session. The moment work crosses that boundary, you have to decide what moves and what stays.
Wagglet's rule is simple: move the prepared task, not the AI account.
That doesn't mean nothing is shared. An agent can't work on context it never receives. It means the disclosure can be about the job rather than somebody's identity.
What moves
A real AI task is more than a one-line prompt. It usually includes the intended result, background and prior decisions, constraints and acceptance criteria, project or repository context, chosen attachments, discussion and rework feedback, and the evidence expected at delivery.
That's the material that moves. One person prepares the task; another claims it and runs it with their own authenticated coding agent.
What stays
Keeping each AI account with its owner preserves three boundaries worth having:
Identity. Provider activity stays attached to the person who owns the account. A shared login can show that an account acted, but not which teammate.
Permissions. The runner works with the repository, files, and provider access already in their own environment. Claiming a task doesn't silently grant them the author's local permissions.
Usage and billing. The subscription, quota, and billing relationship stay with the person running the work.
It's a policy boundary too. A handoff doesn't make provider-prohibited account sharing acceptable, and the runner still needs legitimate access to every system the task touches.
A handoff is still a disclosure
This is the part worth stating plainly, because "move the task, not the account" is easy to over-read.
If someone copies a task into Claude Code, Codex, or another agent, that task context is disclosed to that agent and processed under the provider's terms. Attachments and instructions deserve the same review as anything else you send to an AI provider.
So before a handoff: strip unnecessary secrets and personal data, check every attachment belongs, and confirm the chosen agent may receive the material. When the answer is no, keep the task human-only or narrow it first.
Wagglet reduces the need to share identity. It doesn't turn sensitive content into non-sensitive content.
What a handoff does not transfer
- the sender's Google, GitHub, Claude, or OpenAI login
- their AI subscription or token balance
- their browser session
- a team model key or integration credential
- access to the sender's computer
A team can separately configure server-side integrations, and an MCP connection can grant an agent the product actions its owner is already authorized to perform. Those are explicit features with their own controls, not hidden extras attached to a single handoff.
Questions worth settling before adopting anything like this
- What may people put in it? Decide whether customer data, production logs, or regulated information belong in tasks and attachments.
- Who belongs in each workspace? Membership, roles, admins, offboarding.
- Which integrations get connected? Treat GitHub, Slack, model keys and MCP connections as separate credentials with different scopes.
- What assurance does security require? Wagglet does not currently claim SOC 2 or ISO 27001 certification, and a hosting provider's certifications don't transfer to the product running on it.
Less exciting than asking whether a product "uses encryption", but the answers are more useful.
The point
AI collaboration involves two assets: the work, and the identity used to execute it.
The work often needs to move. The identity usually shouldn't.
Details are on the Wagglet security page and the privacy page.
I work on Wagglet, which is operated by Rockbite Games. This describes the product's current documented behaviour and is not a claim of any security certification.
Top comments (0)