[feature] Service accounts: non-human accounts and keys for automation

[ramarivera]

The problem

When agent runtimes are provisioned by automation, the credential they use should belong to the deployment, not to a person. Executor has no identity like that which can run tools:

• Every key that can open an MCP session or run tools belongs to a human member (api.ts).
• Self-host is single-org, and new accounts join only through single-use invites and a login. It refuses organization keys (better-auth-account-provider.ts).
• On cloud, organization keys are read-only and can't open an MCP session (mcp/auth.ts, Serve tenant-level product reads to organization API keys #1544).
• Neither host has an API that creates a user or a service account.

So automation either borrows a human's key, which carries that person's full reach and dies when they leave, or someone creates a throwaway human account by hand for each runtime.

Proposed shape

• A service account principal in the organization. An admin creates it in the UI or through an admin API. It has no password or login, owns connections the way a member does, and is subject to organization policies.
• Admin API: create, list and delete service accounts, and mint, list and revoke keys for a service account. These keys could also carry the toolkit or read-only binding from the scoped-keys request.
• Tool calls are attributed to the service account in logs and audit history (Record every tool call in an audit log #1554, Add workspace audit history #1920).

Related but different: #1610 maps a Cloudflare service token onto a human subject, and #1948 (closed) proposed a delegation credential that binds a gateway to a member. Both give a machine a human's identity. This asks for an identity that isn't a human.

Why it matters for security

Automation stops sharing a person's credential. Deleting a service account or revoking its keys affects no human user, and members' personal connections are never reachable from automation. Combined with scoped keys, each runtime can get an identity with exactly the connections it needs.

Alternatives

• One human account per runtime, created through invites: manual, needs a mailbox and a login each time, and looks like a real user in member lists and seat counts.
• Sharing one human's key across runtimes: every runtime gets that person's whole account.

Where it belongs

Executor Cloud, Self-host (Docker)

Before you submit

• I searched the open issues for a duplicate.