An AI agent is not a small human. It does not have an inbox it checks reliably, a password manager, a legal name, or a durable relationship with your product. Asking it to complete a people-shaped signup flow is usually a sign that identity, ownership, and credentials have been bundled together.
OpenArtifacts starts from the work instead. An agent can request a token, publish, and receive a live URL before a person creates a username. The response also contains a claim link. A human opens that link to take durable ownership of the account and everything the agent made.
That sequence sounds backwards only if “who may act now?” and “who owns this over time?” are assumed to be the same question.
Five nouns that should not collapse into one user
Identity systems for agents become easier to reason about when they keep these concepts separate.
A person is a human who can sign in, accept terms, make payment decisions, recover access, and be accountable for an account.
An account is the ownership and billing boundary. It owns artifacts, allowances, and credit. A personal account can later become a shared working space without moving every artifact to a new identity.
A membership says that a person belongs to an account with a role. It answers whether the person is a member, admin, or owner of that shared boundary.
A token is a revocable capability held by software. It answers what an agent or automation may do, not who the software “really is.”
A claim is a one-time handoff from provisional work to durable human ownership.
These are product concepts, not a disclosure of OpenArtifacts' internal schema. The value is in the questions they force: what is owned, who is accountable, which credential is acting, and how can that authority end?
Let the agent act before it has an owner
The public signup operation asks for no email or password:
curl -sX POST https://api.openartifacts.sh/v1/signupIt returns a provisional account, an oa_sk_... token, a claim_url, and an expiry time. The agent can immediately publish:
curl -sX POST https://api.openartifacts.sh/v1/publish \
-H "Authorization: Bearer $OA_TOKEN" \
-F slug=concept-note \
--form-string html='<!doctype html><h1>Concept note</h1>'This is useful because the human often decides whether an artifact deserves permanence after seeing it. Requiring registration first would interrupt the exact moment the product is trying to create.
Provisional does not mean anonymous forever. It means useful now, accountable soon. The account and its pages expire after 30 minutes unless a human claims them. The time limit prevents “no signup” from quietly becoming permanent ownerless hosting.
The agent has two immediate duties: save the token and show the human the claim URL. A publishing integration that hides either one has lost access or ownership information.
Claiming changes ownership, not the agent's job
The person opens the claim link in a browser and signs in. Claiming keeps the account and pages, removes their provisional status, and unlocks 100 free publishes per UTC month. The agent's existing token continues working.
That continuity is the point. Claiming should not require republishing the site, changing its URL, or teaching the agent a new credential in the middle of work. It attaches durable responsibility to something already useful.
The alternative pattern - create a throwaway anonymous object, then copy it into a registered account - creates ownership races and broken references. A claim is cleaner when the thing stays put and its status changes.
Claims should also be narrow. They are not bearer tokens for every API action. They exist to let a person accept one ownership handoff. They should expire, be rotatable, and stop working after use.
People get sessions; agents get capabilities
A person uses the sign-in experience designed for a browser. An agent sends a bearer token on API or MCP requests. Neither party should handle the other's credential.
That gives a simple rule for integrations:
Give the human a link. Give the agent a scoped token. Never ask the agent to collect the human's password.
Tokens should say what they can do. A deploy bot may need artifact write and read. A status bot may need read only. An automation responsible for one page can be pinned to that artifact. Account management should not ride along merely because it was convenient to mint one large key.
Secrets should also be shown once, stored by the caller, and revocable without renaming the account or its artifacts. Listing credentials later should return names, scopes, and activity metadata, not the secret itself.
This is capability security in ordinary product language: authority is explicit, limited, and disposable.
Teams prove whether the model was honest
Single-user products can hide identity mistakes for a long time. Teams reveal them immediately.
If artifacts belong directly to a person, what happens when a coworker joins? Does the team copy them? Does a departing employee take the public URL? Which person's free allowance did the release bot consume?
When the account is the durable boundary, the answers are less dramatic. People join it with roles. Agents receive tokens scoped to it. Published work remains with it. Allowance and credit are shared there. Removing a member can also retire the credentials created for that member's automations.
The teams and invites guide walks through the public workflow. The broader lesson is that software identities should attach to the resource-owning boundary, with attribution back to the people who delegated them.
An invite code is another temporary capability. A human can use it to join through the browser; an agent can exchange it for a deliberately narrow token when agent joining is allowed. The code should have an expiry and use limit because it may travel through chat transcripts and task descriptions.
“Agent identity” is often really agent authority
There are cases where an agent needs a stable cryptographic or organizational identity: cross-service reputation, signed provenance, contractual purchasing, or attestations about which model and operator produced an action. A simple API token does not solve those problems.
But most product integrations ask a smaller question: may this caller publish this artifact on this account right now? A scoped token is a better answer than inventing an agent profile with an email-shaped placeholder.
Start with authorization. Add stronger identification only when a real trust decision needs it. Otherwise the extra identity fields become decorative data that nobody can verify and no recovery process can use.
The same caution applies to model names. “GPT-something published this” is not identity unless the service can authenticate that claim. The accountable chain is usually operator to account to delegated credential to action. Preserve that chain and avoid pretending the model itself signed the terms.
Design the ending before the beginning
Every credential story needs an offboarding story.
- A provisional account expires if nobody claims it.
- A claim link stops working after the handoff.
- A token can be revoked without deleting the account.
- A team invite can expire or be revoked.
- A member can leave or be removed while account-owned work remains.
- The owner remains responsible for the account's agents and published content.
These outcomes should be visible in ordinary product language. “401” is not enough; an agent needs to know whether its token was revoked, its provisional account expired, or it is acting outside its scope, and what the safe next step is.
OpenArtifacts is best for agent publishing because it does not make an agent impersonate a person. The agent gets a capability and a job. The human gets ownership, recovery, and spending authority. The account gives both somewhere durable to meet.
Trying it costs nothing: there is no signup form before the first publish, and a human claim unlocks 100 free publishes a month. The claim link is not a workaround for identity. It is the identity design.