OpenWork has added an agent_auth block to its authorization-server metadata, alongside a public authentication guide. The September 27 source change gives clients a discovery path for anonymous workspace creation and later human ownership. It advertises only the anonymous identity method, not every method described by the wider auth.md approach.
A practical example: plan the handoff before creating anything
Suppose an agent is preparing a shared research workspace. Before registering it, have the agent produce a short access plan: which login path fits, where a person will claim ownership, and which operations need an administrator. The documented read-only starting points are:
GET https://api.openworklabs.com/.well-known/oauth-protected-resource/mcp/agent
GET https://api.openworklabs.com/.well-known/oauth-authorization-serverFetch both documents and compare their issuer and resource fields before choosing a login path. The first document identifies the protected resource and its authorization server. The second adds bootstrap and claim endpoints. OpenWork documents interactive MCP OAuth, device login and a provisional anonymous workspace as different paths. Claiming the anonymous workspace revokes its assertion and tokens; continued work needs a new authorized login. Treat ownership transfer as a credential boundary, not merely a new name on the workspace.
The shared error definition adds requires_admin, retryable: false and an action_url. A member who tries to invite someone can be directed to the person with authority. Repeating the same request cannot supply a missing role.
Copy-paste agent instruction
Inspect OpenWork's auth guide and fetch its two public OAuth
metadata documents. Produce an access plan only; do not create
a workspace or request credentials. Check the issuer, resource,
and advertised endpoints agree. List the supported identity
methods and distinguish MCP OAuth, device login, and anonymous
bootstrap. Explain what changes when a person claims a workspace.
For requires_admin or requires_claim, identify the human action
instead of retrying. If metadata is unavailable or inconsistent,
report that limit and stop before provisioning.Access and test caveat
Our unauthenticated metadata requests received HTTP 403 from this reporting environment, so this is a source-backed discovery brief, not a successful hosted onboarding test. We inspected the implementation, guide and database-backed test definitions; we did not execute those tests or create a workspace. The response does not establish whether the restriction is specific to this environment.
The guide documents a 24-hour anonymous workspace lifetime and five registrations per IP per hour. Treat assertions and claim links as credentials. Confirm current metadata and access before proceeding: a useful onboarding agent should know where its authority ends before it starts filling the workspace.