Vaultless: Ephemeral Credential Broker for Autonomous AI Agents
A zero-standing-privilege security broker built with Fastify, TypeScript, PASETO v4 Ed25519 asymmetric tokens, Redis atomic locks, and an append-only PostgreSQL audit ledger.
The Danger of Standing Privileges in Autonomous Agents
When autonomous software agents interact with third-party APIs (such as payment gateways, internal databases, or cloud infrastructure), conventional architecture equips them with permanent, high-privilege API keys. This creates an unacceptable attack surface:
- Prompt Injection & Hallucinations: A subverted agent or anomalous model response can abuse standing credentials to drain resources or exfiltrate customer records.
- Indefinite Blast Radius: Long-lived static keys possess no natural time-to-live (TTL) and must be rotated manually, complicating disaster recovery.
- Zero Fine-Grained Authorization: Downstream services receive a root-level credential rather than a proof-of-work token scoped to a single operation.
Vaultless was conceived to solve this dilemma by establishing an ephemeral credential broker: agents hold zero permanent privileges. Instead, right before invoking a capability, they request a short-lived (e.g., 300-second), cryptographically tamper-proof token strictly scoped to a single action and constraint.
Two-Phase Lifecycle: Minting & Atomic Single-Use Consumption
The system isolates credential generation from validation through asymmetric cryptography. The broker signs claims with its private key; downstream consumers validate signatures and rely on Redis atomic primitives for instant token invalidation.
1. Agent requests credential with resource, action, constraints, and ttl_seconds.
2. Broker validates optional x-idempotency-key in Redis (24h TTL) to prevent duplicate issuance upon network retry.
3. Broker generates an asymmetric PASETO v4 Public token signed with Ed25519.
4. Synchronously persists grant record and appends issued event to PostgreSQL audit ledger.
1. Downstream API forwards token and expected scope to Vaultless.
2. Broker cryptographically verifies signature and expiration time.
3. Executes Redis SET NX EX on used_token:token_hash. If key exists, immediately returns 409 Conflict.
4. If Redis is unreachable, returns 503 Service Unavailable (never fails open).
5. Appends consumed event to PostgreSQL and returns 200 OK.
[Autonomous Agent] [Vaultless Broker] [Upstash Redis] [Supabase Postgres]
│ │ │ │
│── POST /v1/credentials (scoped) ───>│ │ │
│ │── SETNX idempotency_key ────>│ │
│ │── Sign PASETO v4 (Ed25519) ──│ │
│ │── Append 'issued' event ──────────────────────────>│
│<── Returns Token + Grant ID ────────│ │ │
│ │ │ │
[Downstream API] │ │ │
│── POST /v1/validate (Bearer token) ─>│ │ │
│ │── Verify PASETO v4 sig ──────│ │
│ │── SETNX used_token:<hash> ──>│ │
│ │ ├── [If Acquired]: Append 'consumed' ───────────>│
│<── 200 OK (Claims Verified) ────────│ └── [If Locked]: 409 Conflict (Burned) │Architectural Trade-offs & Security Invariants
PASETO v4 Public vs. Conventional JWT
JSON Web Tokens (JWT) have historically suffered from critical algorithm confusion vulnerabilities (e.g. alg: none exploits or public/private key confusion attacks). PASETO (Platform-Agnostic Security Tokens) v4 strictly mandates Ed25519 asymmetric cryptography without algorithm headers, eliminating header forgery classes entirely.
Fail-Closed Resilience Model
If the Redis caching layer fails or experiences a network partition during validation, Vaultless hard-fails validation requests with HTTP 503 Service Unavailable. The system never falls back to an unverified allowlist: it is mathematically safer to reject valid actions than to permit a replayed token.
Atomic Single-Use Concurrency Control
Single-use enforcement is executed via Redis SETNX with an automated TTL matching the token expiry. This ensures that even if 10 concurrent requests arrive at the exact same millisecond, exactly one thread acquires the lock, while the remaining 9 are deterministically rejected with 409 Conflict.
Agent-Scoped Rate Limiting
Utilizes Fastify rate limiting keyed off the x-agent-id header (falling back to client IP). This defends against runaway or looping autonomous agents, preventing noisy neighbor starvation across multi-tenant deployments.
Service Endpoints & Telemetry
x-idempotency-key)Real Integration Testing Against Containerized Infrastructure
Rather than testing against mocked database drivers or fake in-memory caches, Vaultless implements a Vitest integration test suite executing against live Docker containers (PostgreSQL 15 and Redis 7):
- Concurrent race condition validation: 10 parallel consumers hammering the same token yield 1 success and 9 conflict errors.
- Redis fail-closed behavior: Simulating Redis disconnection forces validation endpoints to reject requests with 503 rather than permitting token reuse.
- Idempotency cache: Re-sending identical minting requests with duplicate idempotency keys returns matching tokens without duplicating audit ledger entries.
- Tampered signature rejection: Invalid PASETO signatures or altered constraints trigger immediate 401 Unauthorized responses.
Hackathon Scope Limitations & Production Path
In accordance with honest engineering principles, the codebase contains explicit architectural compromises documented during the hackathon cycle:
The credential_grants table currently lacks composite B-tree indexes on token_hash and expires_at. While imperceptible under light load, database performance would degrade at high ingestion volumes without an explicit indexing migration.
If the single-use token lock is successfully set in Redis but the subsequent write to PostgreSQL fails due to a network partition, the token is burned without an audit log entry for consumed. Resolving this requires a two-phase commit or transactional outbox pattern.
The /metrics counters reside in Node.js process memory. On a single free-tier instance this is sufficient, but in a horizontally scaled cluster, metrics must be exported to an external collector (e.g. Datadog or Prometheus Pushgateway).
The Postgres connection pool is configured with ssl: { rejectUnauthorized: false } to maintain compatibility with Supabase's managed connection pooler. An enterprise environment would enforce certificate authority pinning.