← Resources
Features
#feature #sharing #auth

Share It Like a Google Doc

Private, specific people, groups, the whole org, or a public link — per app, changeable without a redeploy, with colleagues signing in through the work account they already have. No auth code, ever.

TL;DR: Every AgentCell app has a share list with five states — private, specific people, groups, anyone in the org, public link — set by the owner in plain UI, changeable without redeploying. The app itself contains zero auth code: an identity-aware front door authenticates every request before it reaches your code and hands it a verified user.

The mental model you already know

Nobody trains colleagues to use Google Docs sharing. That is the bar:

StateMeaning
PrivateOnly you. The default.
Specific peoplepriya@, marco@ — named emails, in or out of the org
Groupsdesign@, ops-team — managed once, applied to many cells
Anyone in the orgSigned in with the work account; no per-person invite
Public linkAnyone with the URL (verified identity still required before exposure — abuse controls apply)

Sharing never requires the app to be redeployed. The share list lives at the boundary, not in the code — so “add Priya” is a membership change, not a commit, a rebuild, and a prayer.

The recipient experience

A colleague clicks the link. They sign in with the work account they already have — Google Workspace, Okta, Entra, whatever the org uses. The app opens. Nothing to install, no new account, no VPN client, no tailnet to join.

Contrast the alternatives: Tailscale-style sharing assumes participants install a client or join a network (~$6–8/user/mo and the wrong shape for “colleague clicks a link”). Cloudflare Access does org-internal Zero Trust well ($7/user after 50 free) but fails at ad-hoc sharing with someone outside the org. Vercel’s “Shareable Links” — a query-string token for external viewers — is the closest existing pattern, and worth studying: but a token on a deployment is not a membership list with groups, revocation, and an audit trail.

Zero auth code in your app

The mechanism is an identity-aware proxy in front of every cell. Requests authenticate against the org’s identity provider before reaching app code; the app receives a verified user in a header/context object and implements no login, no sessions, no password resets, no “who can see this” branches.

Why this matters beyond convenience: the answer to “who can see the revenue dashboard” currently lives in code an agent wrote in an afternoon, unreviewed, and different in each of your twenty tools. Moving that boundary to the platform means it is consistent, reviewable in one place, and changeable by the person who owns the tool — not just the person who can read the code.

For apps that want per-user behavior (show my queue, save my view), a small identity SDK exposes the verified user — optional, never required.

Ownership that survives people

Tools outlive authors. Cells have ownership and transfer: when someone leaves, the tool doesn’t die with their account — it transfers to the team, and SCIM-shaped deprovisioning removes the leaver’s access to all twenty tools at once. The per-cell access log (who opened it, when) is what makes an IT team comfortable sanctioning this instead of banning it.

Limits (beta scope, stated plainly)

FAQ

Do recipients need an AgentCell account? No. They sign in with their existing work account (or email for personal sharing). Sharing must not require the recipient to join anything.

Can I revoke access? Per person, per group, or whole-link — instantly, without touching the app.

What does the app developer do for auth? Nothing. Ship business logic; read the verified user only if per-user behavior is wanted.


Built something three colleagues should be using? Deploy now — bring the tool stuck on localhost.

Keep reading

AgentCell

Deploy · Logs · Rollback · Access · All headless

Deploy now