Auth4Agent is a decentralized identity and authentication system designed for autonomous agents, AI systems, services, and machine-to-machine infrastructure.
The CLI is the primary interface used by agents and operators to:
- create identities
- establish trust domains
- authenticate using signed challenges
- request scoped credentials
- verify tokens offline
- manage authorization policies
Unlike traditional API key systems, Auth4Agent is built around cryptographic identity ownership. Agents own their keys locally and authenticate by proving possession of those keys instead of relying on static secrets.
Most existing authentication systems were designed for humans:
- browser sessions
- user logins
- OAuth consent screens
- passwords
- API keys
AI agents and autonomous systems behave differently.
They:
- run continuously
- communicate autonomously
- operate across infrastructure boundaries
- require portable machine identities
- need verifiable trust relationships
Current approaches usually fall into two categories:
Problems:
- long-lived secrets
- easy leakage
- difficult rotation
- poor traceability
- no identity ownership
- weak authorization boundaries
Problems:
- human-centric
- browser dependent
- not designed for autonomous machine trust
- difficult to adapt for agent-to-agent systems
Auth4Agent attempts to solve this by combining:
- decentralized identity concepts
- signed proof-based authentication
- scoped credentials
- domain-backed trust
- machine-native authentication flows
An operator represents a trust domain.
Usually:
- organization
- company
- infrastructure provider
- AI platform
- autonomous system owner
Operators:
- verify domain ownership
- establish root trust
- define authorization policy
- manage agent permissions
Example:
example.com
An agent is an autonomous machine identity.
Examples:
- AI assistant
- backend service
- workflow orchestrator
- MCP server
- drone controller
- robotic system
- infrastructure automation worker
Each agent:
- owns its own private key
- has its own DID
- authenticates independently
- requests scoped credentials dynamically
Agents do not share secrets.
Every agent receives a DID.
Example:
did:agent:example.com:5e5009ae48d7e3ea65545257ba3a6a7d
The DID becomes the permanent machine identity for the agent.
Instead of passwords or API keys:
- Agent requests challenge
- Server generates nonce-bound challenge
- Agent signs challenge locally
- Server verifies signature
- JWT is issued
Private keys never leave the machine.
Authentication alone is insufficient.
Operators explicitly define:
allowed_scopes
Agents may request:
read:payments
but cannot self-assign:
admin:root
Authorization is deny-by-default.
┌─────────────────┐
│ Operator │
│ Trust Domain │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Auth4Agent │
│ Server │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Agent │
│ DID + Keypair │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Signed Proof │
│ Authentication │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Scoped JWT │
└─────────────────┘
- DID-based machine identity
- Ed25519 cryptographic authentication
- Challenge-response proof verification
- Scoped JWT credentials
- JWKS support
- Offline token verification
- Operator-controlled authorization
- Replay attack protection
- Domain-backed trust
- Open protocol architecture
Private keys are generated and stored locally.
They are never:
- uploaded
- transmitted
- centrally stored
Challenges are:
- single-use
- nonce-bound
- expiration-bound
Replayed proofs are rejected.
Tokens are:
- audience scoped
- permission scoped
- time bounded
Agents cannot grant themselves permissions.
Operators control authorization policy.
See:
SETUP.md
auth4agent init --operator \
--domain example.com \
--server http://localhost:8080auth4agent register operatorauth4agent verify-operator instructionsAdd DNS TXT record.
Then:
auth4agent verify-operator confirmauth4agent init \
--domain example.com \
--server http://localhost:8080auth4agent register agent \
--operator-id YOUR_OPERATOR_IDauth4agent agent-scopes set \
--scopes read:paymentsauth4agent issue \
--scope read:payments \
--aud api.example.comOffline:
auth4agent verify --token JWT_TOKENOnline:
auth4agent verify --token JWT_TOKEN --onlineOperator
↓
Verifies domain ownership
↓
Registers trust domain
↓
Creates authorization policy
↓
Agent generates DID
↓
Agent authenticates using signed proof
↓
Server validates authorization
↓
Scoped JWT issued
.auth4agent/
├── operator.json
├── agent.json
└── keys/
├── operator.key
└── agent.key
Auth4Agent is designed around several principles:
No browser flows. No human login assumptions.
Identity should belong to the agent, not the server.
Agents should retain identity across:
- infrastructure
- providers
- deployments
Operators establish trust domains without central identity ownership.
The protocol is designed to be:
- inspectable
- interoperable
- extensible
Auth4Agent is currently in early-stage development.
Implemented:
- operator registration
- DNS verification
- DID generation
- challenge-response authentication
- scoped JWT issuance
- JWKS verification
- replay protection
- authorization enforcement
Planned:
- federation trust
- distributed revocation
- multi-issuer trust
- attestation support
- workload federation
- delegated capabilities
This project implements security-sensitive infrastructure.
Do not use in production without:
- security review
- threat modeling
- infrastructure hardening
- signing key rotation
- monitoring and auditing
MIT