agent-id-browser

Alien Agent ID

A portable cryptographic identity, encrypted credential vault, and logged-in browser for AI agents.
Standalone by default — optionally linked to a verified human via Alien Network biometric SSO.

Give an AI agent its own identity and the tools to act with it safely. It works from the first second with a local key — no account, no sign-up:

• 🪪 A portable agent identity — an Ed25519 keypair the agent owns; everything it signs (commits, operations) is attributable to it and verifiable by anyone.
• 🔐 A credential vault — keep API keys, tokens, OAuth logins, even blockchain wallet keys in an encrypted vault; the agent uses them by name through a local proxy and never sees the secret value. Unlocked automatically by the agent's own local key. (agent-id-vault + agent-id-proxy)
• 🌐 Browser logins — sign in once in a real browser when a desktop head is available, or let the agent log in headless from a stored login credential, answering any 2FA over an abstracted secure-entry channel (browser form, mobile app, hosted harness, or CLI). Either way the agent then drives the logged-in session headless for sites that block API/cookie access (e.g. Gmail/Workspace) — still without ever handling your credential. (agent-id-browser)
• 🔏 Signed git commits — SSH-signed with trailers tracing back to the agent (and, once you bind, to a human). (agent-id-git)

Human identity is opt-in. When you want provenance you can prove to a third party, link the agent's key to a verified human via Alien Network's biometric SSO. Git commits then trace the full chain commit → agent key → SSO id_token (cnf.jkt) → verified human owner — but you never need it to use the identity, vault, or browser. See Assurance levels.

💻 Watch the setup demo on X

Table of Contents

• How It Works
• Plugin Layout
• Quick Start (Claude Code)
• What a Signed Commit Looks Like
• Verifying Provenance
• Service Authentication
• Service Discovery
• Credential Vault
• Session Refresh
• Prerequisites
• Agent State
• CLI Reference
• Security

---

How It Works

The identity is a local Ed25519 keypair: agent-id-core init generates it and the agent can sign, run the vault, and make commits with it immediately — level 0, no human, no network. Everything below is the opt-in step of binding that key to a verified human, for when you want third-party-provable provenance.

sequenceDiagram
    participant Agent as AI Agent
    participant SSO as Alien SSO
    participant App as Alien App (Human)

    Agent->>SSO: 1. Start OIDC auth, get QR / deep link
    SSO->>App: 2. Human scans QR with Alien App
    App->>SSO: 3. Human approves, callback to SSO
    SSO->>Agent: 4. Exchange tokens, create cryptographic owner binding
    Note over Agent: Alien Agent ID bound → SSH-signed git commits with provenance trailers

1. Agent starts OIDC auth, gets a QR code / deep link
2. Human scans QR with Alien App
3. Human approves, Alien App calls back to SSO
4. Agent exchanges tokens, creates cryptographic owner binding

The agent now has an Ed25519 keypair with a signed binding proving a verified human authorized it.

Assurance levels — identity from the first second, binding added later

An agent identity is a single, stable Ed25519 key. What grows over time is the attestation backing it, not the key — so the identity is usable immediately and binding is something you add, never a gate on using it. The key never changes across levels, so climbing the ladder never invalidates an earlier signature or commit.

Level	Backing	A verifier learns
L0 — self-asserted	the agent key alone (init)	"signed by key X" — no human. Already usable: the credential vault, the local audit trail (sign/verify), and L0 git commits.
L1 — anonymous-human	SSO id_token, cnf.jkt-bound, pairwise/pseudonymous sub + alien_assurance: "anonymous"	"a verified human stands behind key X" — not which human, and not linkable across services.
L2 — linked	SSO id_token whose sub is the canonical AlienID	the full chain: artifact → key → this specific human.