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
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
- Agent starts OIDC auth, gets a QR code / deep link
- Human scans QR with Alien App
- Human approves, Alien App calls back to SSO
- 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. |