platform: a machine identity that can create projects and issue their deploy tokens #692

Motivation

We run a self-hosted Void platform behind Cloudflare Access for LumiOS, an internal agent platform (the connected-app client from #631). LumiOS agents build small web apps for our users. Each app needs its own D1, KV, R2, queues and Durable State, and Void scopes those to a project, so LumiOS needs to create one project per app and deploy to it, unattended, from a server.

Deploying works today: a project credential (aud: deploy) plus our Access service token is admitted for that project. Creating the project and minting its first credential is the gap. Only a human login session can do either, and the platform refuses a human session that arrives with an Access service token. The docs say this is deliberate:

• "machine Access proof cannot turn a human Void token into an automation identity" (cli/auth.md)
• "Void does not issue permanent service tokens for administrator automation" (operations.md)

We'd like to know whether you'd support a machine identity for this, and in what shape, before we build anything.

Where it is decided (v1.5.0)

• Access service identities may only reach /projects/* with a project-scoped deploy/oauth-deploy/oauth-preview token; everything else gets access_human_identity_required: platform-access.ts#L106-L121
• POST /projects creates the project for the session's user: projects.ts#L658-L660
• POST /projects/:id/tokens signs the credential for the session's user, at most 90 days: project-tokens.ts#L125-L143, deploy-token.ts#L22
• The operator API can list, transfer and delete projects but not create them or issue their credentials.

What we would do without it

Create an ordinary user for the service, keep its 30-day Void session and a user Access token in our secret store, and have a person sign in as it about once a month. That works, but it's the pattern the docs above warn against: a human-type account with a password and MFA held by a server, and an outage whenever someone misses the renewal.

Possible shape (for discussion)

An operator registers a machine user and binds it to one Access service token:

void platform machine create lumios --access-service-token <client-id>

• The platform-access middleware admits that service token for a small set of routes when it is paired with the machine user's credential: create a project, issue and revoke credentials for projects the machine user owns, and (maybe) write those projects' secrets.
• The machine credential is revocable and rotatable by an operator, and never works without its bound service token, so leaking one half is not enough.
• Projects it creates count against its plan like any user's, and can be transferred to a human owner with the existing operator command.

Questions

1. Is a machine identity something you'd want in Void, or would you rather solve this another way (for example a connected-app grant an administrator approves once, or the GitHub-OIDC executor generalized to other issuers)?
2. If machine users: should the credential be long-lived and revocable, or short-lived and exchanged from the bound service token on each use?
3. Should projects belong to the machine user, or be created on behalf of a named human owner or team?
4. Would you accept a PR once the shape is agreed?

Prepared with an AI coding agent on behalf of @sglyon; reviewed by @sglyon before posting.