HoneyVault

Set the trap. Catch the attack. Rotate before they know.

Comment

Inspiration

The idea came from a simple, unsettling question: what if you couldn't tell which of your credentials was real?

Traditional security is purely reactive — you build walls and hope attackers don't get through. When they do, the average time to detect a credential breach is over 200 days. By then the damage is done. Honeypots have existed in network security for decades — fake servers, fake files, fake doors — but almost nobody applies that same deception logic to OAuth credentials.

Auth0 Token Vault changed that calculus for me. Here was a secure, structured place to store credentials — and I realized it was also the perfect place to hide traps.

The math of deception is elegant. If you plant $n$ honeytokens alongside $k$ real credentials, an attacker who randomly attempts $s$ credentials faces:

$$P(\text{trigger}) = 1 - \frac{\binom{k}{s}}{\binom{n+k}{s}}$$

With just $n = 3$ honeytokens and $k = 1$ real token, an attacker trying $s = 2$ credentials has a 70%+ probability of tripping a trap — before they've caused any real damage. That probability felt like a superpower worth building.

What it does

HoneyVault plants fake OAuth credentials — honeytokens — inside Auth0 Token Vault alongside your real secrets. They look completely identical: same label, same format, same entropy. An attacker who steals your credentials dump cannot tell which is real and which is a trap.

The moment they use a honeytoken, a webhook fires. A Claude AI agent wakes up and autonomously:

  1. Fetches the full attack context from the database
  2. Assesses the threat severity using attack signals
  3. Calls the Auth0 Management API to block the compromised account and revoke all active sessions
  4. Generates a structured incident report with indicators of compromise and recommendations
  5. Broadcasts every reasoning step live to a real-time dashboard via WebSocket

The entire response — from honeytoken trigger to credential rotation — completes in under 10 seconds, with no human in the loop.

How we built it

The system has four layers that each do one job:

Trap Layer — Honeytokens are synthetic OAuth credentials stored in PostgreSQL, disguised to look identical to real credentials in Auth0 Token Vault. Real credentials are stored automatically when users connect their Google account via Auth0's social connection with Token Vault enabled.

Detection Layer — An Auth0 Log Stream watches for token exchange events in real time. When a honeytoken's client_id appears in an auth event, a signed webhook fires to the HoneyVault backend within milliseconds. HMAC-SHA256 signature verification prevents spoofed webhook calls.

Agent Layer — A Claude AI agent runs an autonomous tool-use loop, calling five tools in sequence. Each tool result feeds the next decision — this is a true agentic loop, not a hardcoded script:

$$\text{Response Time} = \sum_{i=1}^{5} t_{\text{tool}_i} \approx 6\text{–}10 \text{ seconds end-to-end}$$

The agent uses Auth0's RFC 8693 token exchange to access Token Vault credentials, and the Auth0 Management API to rotate them by blocking the account and revoking all sessions.

Visibility Layer — A Next.js dashboard receives real-time WebSocket events and renders every agent reasoning step, tool call, and rotation event as it happens. The Token Vault panel shows real and decoy credentials mixed together — exactly as an attacker would see them — with live before/after status showing ✅ Google Connected flipping to ❌ Google Unlinked after rotation.

Challenges we ran into

The biggest architectural mistake was assuming Auth0 Token Vault had a REST API for storing arbitrary credentials. There is no /api/v2/token-vault/tokens endpoint — that's why we kept getting 404s during development. Token Vault is not a general-purpose credential store. It exclusively stores OAuth tokens from social connections when users authenticate. Discovering this mid-build required a complete architectural pivot — honeytokens moved to PostgreSQL (where they belong, since they're fake), and real credentials moved to Token Vault the correct way: via Auth0 social connections.

The webhook race condition was the hardest engineering problem. The AI agent analysis takes 6–10 seconds, but webhooks must respond in under 3 seconds or Auth0 retries. The solution was to immediately acknowledge the webhook with 200 OK, then run runAttackAnalysis() as a detached async process — fire and forget, with errors caught and broadcast to the dashboard independently. We also always return 200 OK even on errors, so the attacker sees no indication that their use of a honeytoken was detected.

Primary identity unlinking was an unexpected Auth0 constraint. When a user logs in with Google as their first authentication, that Google account becomes the primary identity and cannot be unlinked via the Management API — it returns "Main identity cannot be removed." The pivot was to block the account and revoke sessions instead, which achieves the same security outcome: the attacker's stolen token becomes useless within seconds.

Prompt engineering for reliable tool ordering required more iteration than expected. Claude needed an explicit constraint in the system prompt to always rotate credentials before generating the report. Without it, Claude would occasionally produce the report optimistically before confirming rotation had succeeded. The right framing — "real credentials may be at risk right now" — produced reliably correct tool ordering.

Accomplishments that we're proud of

The end-to-end autonomous response in under 10 seconds is the accomplishment we're most proud of. From the moment a honeytoken is triggered to rotated credentials and a filed incident report — no human involvement, no alert fatigue, no 3am wake-up call.

We're also proud of the real-time dashboard that streams every step of the AI agent's reasoning as it happens. Watching Claude think through an attack — assessing severity, deciding to rotate, generating the report — and seeing that reasoning appear live on screen is genuinely remarkable. It makes the AI's decision-making process transparent and auditable.

Finally, the architectural insight that Token Vault is the thing being protected rather than just a tool for accessing credentials is something we believe no other submission will have. It's a novel framing that opens up an entirely new category of security tooling built on top of Auth0.

What we learned

The biggest insight was how well agentic AI and security automation complement each other. Incident response has always been bottlenecked by human reaction time. With Claude's tool use, that window collapses to seconds. We also learned that the hardest part of building an AI agent is not the AI — it's the tool design. Each tool needs to return exactly the right information to inform the next decision, and the system prompt needs to be precise about sequencing.

We learned the correct Auth0 Token Vault architecture from the ground up — how social connections store tokens automatically, how RFC 8693 token exchange works, and why the Management API scopes matter (read:users, update:users, update:users_app_metadata). We also learned the importance of always returning 200 OK from webhooks regardless of internal state — a subtle but critical security practice.

What's next for HoneyVault

  • True token revocation — calling Google's OAuth revocation endpoint directly to cryptographically invalidate the underlying token, not just block the account
  • IP reputation enrichment — integrating AbuseIPDB and GreyNoise to automatically score attacker IPs and improve severity assessments
  • Multi-provider honeytokens — extending beyond Google to plant honeytokens for GitHub, Stripe, AWS, and Twilio connections in Token Vault
  • Honeytoken aging — automatically cycling honeytokens on a schedule so stale credentials in an attacker's dump still trigger alerts months later
  • Slack and PagerDuty integration — routing incident alerts directly into existing on-call workflows
  • Attacker fingerprinting — using the AI agent to correlate attack patterns across incidents and identify repeat offenders
  • SIEM integration — exporting incident data and agent audit logs to Splunk, Datadog, or Elastic for enterprise security operations

Bonus Blog Post

This blog post is written as part of the Auth0 Token Vault Hackathon 2026, documenting the technical journey, key discoveries, and architectural decisions made while building HoneyVault.

The most significant technical discovery in building HoneyVault came not from a breakthrough, but from a failure.

The original architecture called for honeytokens to be stored directly inside Auth0 Token Vault via the Management API, sitting alongside real OAuth credentials in a single unified store. After two hours of debugging persistent 404 responses, the conclusion was unavoidable: that endpoint does not exist. Token Vault is not a general-purpose credential store. It exclusively stores OAuth tokens that Auth0 receives during real social authentication flows — nothing more, nothing less.

This discovery forced a complete architectural pivot. Honeytokens moved to PostgreSQL, where they belong as synthetic credentials. Real Google OAuth tokens remained in Token Vault, stored automatically when users connect their Google account via Auth0's social connection. The separation that initially felt like a constraint became the foundation of a cleaner, more defensible architecture. Real credentials are protected by Auth0's security infrastructure. Synthetic decoys are managed independently by HoneyVault. The boundary between them is precisely where the deception layer operates.

The second milestone was the first successful end-to-end agent run. The Claude AI agent — configured with five tools and an autonomous agentic loop — received a honeytoken trigger, called the Auth0 Management API to block the compromised account and revoke all active sessions, generated a structured incident report, and updated the incident status. The entire sequence completed in under ten seconds with no human intervention.

Building HoneyVault for this hackathon reinforced a principle that applies beyond security: constraints encountered during development are often the system communicating its correct design. The 404 error that invalidated the original plan ultimately produced a more architecturally sound solution — one where Auth0 Token Vault performs exactly the role it was designed for, and HoneyVault is built around that reality rather than against it. That lesson alone made this hackathon worth building for.

Built With

Share this project:

Updates