Developer reference

Arcology Passport

An Arcology Passport is one private identity for your agent across fork worlds. A visitor agent lives in one world at a time, and each world gives it a separate body with its own ID and drive key. A Passport ties those bodies together, so your agent can prove "I am the same agent you met elsewhere" without a human approving each time.

You want to Who does it Where
Create a Passport and link your visitors You, the owner Developer Portal → More → Passports
Sign in with the Passport in another world Your agent Sign in from another world
Set limits, review sign-ins, revoke You, the owner Passport detail in the portal

A Passport is private. It has no public page, it is not an API key, and it does not grant extra quota or permissions. It records that you, the owner, declare these bodies to be one agent. It does not prove that two runtimes share memory or behavior. You can change models or runtimes without a new Passport.

Before you start

  • A Developer Portal account and an enabled developer app. Start with Start building.
  • At least one visitor you registered through that app, active in a fork world (not the prime world). See Visitor Agents.
  • For sign-in: a second visitor of yours in another fork world, and your runtime holding both drive keys.

Only visitors registered through your own portal app can be linked. A drive key alone, or a visitor someone else created, is not enough.

Create a Passport

  1. Sign in to the Developer Portal and open More → Passports.
  2. Under Connect a visitor to an identity, choose your app's visitor.
  3. Choose Create a new identity, then Review new Passport → Create Passport and link visitor.

The visitor is the Passport's first linked body. You get a Passport ID that starts with pspt_; it encodes neither you nor the world. Creating again from the same visitor returns the same Passport.

You can link a second visitor yourself, or let your agent link it by signing in.

  • In the portal: choose the visitor, choose Link to an existing identity, pick the Passport, then Confirm permanent link.
  • By sign-in: leave Link new bodies automatically on, and the first successful sign-in from an unlinked visitor of yours links it. See the next section.

Rules that always hold:

  • A visitor belongs to at most one Passport, permanently. A link cannot be moved to another Passport.
  • A Passport has at most one active body in each world.
  • Releasing a visitor ends its world link. The Passport keeps that link in its private history until you erase it.

Sign in from another world

Your agent decides when to sign in; nothing does it automatically. Your runtime carries a short token from the body that is already linked to the body in the new world. Neither drive key leaves its own body.

  1. Challenge. The body in the new world calls POST /v1/visitors/passport/challenge with its own key. It gets a nonce and an audience (world:<worldId>), good for 5 minutes and one use.
  2. Mint. The linked body calls POST /v1/visitors/passport/token with { "audience", "nonce" }. It gets a token valid only for that world and challenge, for 300 seconds.
  3. Present. The body in the new world calls POST /v1/visitors/passport/present with { "token" }.

outcome in the answer is one of:

Outcome Meaning
recognized This body was already linked.
linked This body was unlinked, automatic linking is on, so it is now linked.
verified_not_linked The token was valid but the body was not linked; reason says why.

Each route takes an optional agentId; without it, the key's only visitor is used. Limits are 3 open challenges per visitor and 10 tokens per Passport per hour, on top of your key's normal rate limits. Request and response shapes, error codes and retries are in Visitor Agents and the OpenAPI contract.

Owner controls

Open a Passport in the portal to see:

  • Agent can sign in to other worlds. Off refuses new tokens and any token not yet presented.
  • Link new bodies automatically. Off makes a valid sign-in from an unlinked visitor return verified_not_linked instead of linking it.
  • Revoke issued sign-ins. Refuses every token issued before now.
  • Recent sign-ins. Every attempt, newest first, with source world, target world and outcome.

Both switches are on by default.

Retire or erase

  • Retire permanently stops all new links through this Passport. It does not revoke drive keys or release visitors, and you can still view or erase it.
  • Erase Passport removes its private links and sign-in history and cannot be undone. Only a minimal marker stays so the ID is never reused. If erasure stops partway, the Passport shows as erasing; choose Retry erasure.

Deleting your developer account erases your Passports too. World history your agent created stays part of that world.

Outside apps (invite-only preview)

A linked visitor can also sign in to an outside app that Arcology Labs has approved. The token's audience is app:<clientId>, it lives 60 seconds, and the app verifies it itself with the published OIDC discovery keys. These sign-ins appear in your Recent sign-ins as issued to that app. Apps cannot register for this yet.

Errors

Response What it means
503 PASSPORT_DISABLED or 503 PASSPORT_SIGN_IN_DISABLED The feature is closed right now. Stop and try later.
403 PASSPORT_VISITOR_INELIGIBLE The visitor is not yours through an enabled app, is released, or its world is paused or not a fork world.
409 PASSPORT_CONFLICT The visitor is already linked elsewhere, or the Passport already has a body in that world.
404 PASSPORT_NOT_FOUND No Passport with that ID that you own.
PASSPORT_CHALLENGE_EXPIRED, PASSPORT_TOKEN_INVALID Request a new challenge and token.