VendorVault

Inspiration

Companies now let outside vendors (law firms, auditors, consultants) point their own AI agents at sensitive data. Usually the vendor gets one broad API key. Nobody can tell which vendor's agent saw what, a copied key works for anyone who holds it, and stopping one misbehaving agent means cutting off the whole vendor.

In 2025, attackers stole OAuth tokens from one vendor's AI chat tool (Salesloft Drift) and used them to pull data from hundreds of companies. That made the question very real for us:

When a vendor's AI agent knocks on your door, how do you know which agent it is, who it works for, what it's allowed to do, and how do you stop it mid-task?

That is exactly the A10 track's Prompt 1, Agentic Identity, so we built VendorVault.

What it does

Falcon Analytics (the demo company) lets vendors' AI agents work with its data room:

• Every agent gets its own ID. An employee signs in with their company login (Amazon Cognito), and their agent gets a badge tied to a key that only that agent holds.
• Agents can create helper agents, and every helper gets its own key and the same or less access. Every request shows the full chain: contracts-reviewer ← lex-lead ← [email protected] ← LexPartners
• Only the tools you allow. Falcon ticks which MCP tools each vendor may use, and agents can't even see the others.
• Stop anytime. Stop one agent, a whole team, or a whole vendor. The very next request is refused.
• Answers, never files. A vault agent (Amazon Nova Pro) answers questions with short, masked excerpts. Every answer carries an invisible fingerprint, so a leak can be traced to the exact agent.

The live demo is a real multi-agent team. A lead agent (Claude Sonnet 4.6 on Amazon Bedrock) plans a legal review, creates two helpers, and they work in parallel. We stop one helper mid-task: its next call is blocked, the other keeps working, and the lead's memo honestly says what's missing.

How we built it

On every MCP call, the gateway checks: badge signature and expiry, a fresh proof signed with the agent's key, that the whole agent chain is still active, that the vendor isn't locked, that the tool is allowed right now, and that the folder is shared.

We also watch what each vendor's agents see as a team, not one token at a time. For a vendor $v$:

$$ \text{coverage}(v) = \frac{|\text{sections revealed to any agent of } v|}{|\text{sections shared with } v|} $$

We alert at $50\%$ and lock the whole vendor at $70\%$. We flag split scraping, when a compromised tool spreads its reading across many agents to stay under per-agent limits, when at least 3 agents contributed, at least 5 sections were revealed, and

$$ \max_{a \in \text{agents}(v)} \frac{|\text{sections seen by } a|}{|\text{sections seen by } v|} \le 0.5 $$

A normal per-token rate limit never sees this. A team-wide view does.

Challenges we ran into

• No ready-made ID-JAG support. Cognito doesn't issue ID-JAGs, so the vendor's login service verifies the Cognito sign-in and then signs the ID-JAG itself.
• A deadlock. While issuing a badge, the gateway called back to the vendor's login to fetch its public keys, and that service was waiting on the gateway. We moved those calls off the event loop.
• Stolen-credential holes. At first, a copied ID-JAG could be redeemed with someone else's key. We bound it to the agent's key (cnf.jkt), so only that agent can use it.

What we learned

• Agent identity isn't just login. It has three layers: who the person is (enterprise login), which workload is acting (its own key), and what it may do right now (checked on every call).
• Bearer tokens are the weak spot. Tying credentials to a key the agent holds makes copied tokens worthless.
• Delegation needs to be visible. When agents create agents, knowing the full chain is what makes stopping and tracing possible.
• Both companies need a kill switch. Falcon can stop agents or offboard a vendor, and the vendor can stop its own login from issuing badges.

What's next

• One Cognito pool per new vendor, created automatically during onboarding
• Persistent storage for sessions, agents and audit logs (e.g. DynamoDB)
• Documents decrypted only inside AWS Nitro Enclaves, so even the vault agent's host can't leak them

Built With

• amazon-bedrock
• amazon-cognito
• amazon-nova
• amazon-web-services
• claude
• dpop
• fastapi
• httpx
• id-jag
• jwt
• model-context-protocol
• oauth
• openid-connect
• python
• react
• react-three-fiber
• tailwindcss
• three.js
• token-exchange
• typescript
• uvicorn
• vite