Building Agent Vault with Lit Protocol Vincent SDK: What We Learned

Context

Agent Vault is a project built for SYNTHESIS 2026 hackathon, track 4: Agents that keep secrets. The goal: give autonomous AI agents a way to hold cryptographic keys and sign transactions without exposing those keys to any single party. Judging started March 18. Here is what building with Lit Protocol Vincent SDK actually taught us.

The Core Problem with Agent Keys

An autonomous agent that holds private keys is a security problem waiting to happen. If the key lives in agent memory, prompt injection or memory leak exposes it. If it lives in an environment variable, any code execution vulnerability exposes it. Standard key management services work for humans with MFA. They work poorly for agents that spin up and execute without human involvement at each step.

Lit Protocol solves this differently. The private key never exists as a complete object anywhere. It is split into shares across a network of threshold nodes. Signing requires a threshold of nodes to cooperate. No single node, no operator, no agent runtime can reconstruct the key from the shares it holds.

What the Vincent SDK Actually Does

Vincent is the Lit Protocol stack for agent-specific key management. A PKP (Programmable Key Pair) is a distributed key. You mint a PKP, get back an Ethereum address and tokenId, and from that point signing requests go to the Lit node network rather than to a local key file. The SDK wraps: mintCapacityCredits (pay for signing operations), mintPKP (create distributed key), createCapacityDelegationAuthSig (authorize the PKP), pkpSign (threshold ECDSA signature). In Agent Vault these calls implement a vault where an agent deposits funds, checks a spending policy, signs if allowed, and produces a compliance proof that the policy was followed.

Spending Policy Architecture

The critical design decision is where to enforce the spending policy. Application-layer enforcement is weakest: if the agent is compromised, the adversary controls the check. The correct approach is enforcement at the signing layer. In Agent Vault, the spending cap check runs before the pkpSign call. If the transaction exceeds the cap, the signing call never happens. A compromised agent cannot drain the vault beyond the cap regardless of what its application code does.

ZK Compliance Proofs

Step 6 in the demo produces a compliance proof. Most hackathon projects skip this. It addresses a deployment blocker for regulated agent use. An agent that signs transactions needs to prove, after the fact, that those transactions were policy-compliant. The Agent Vault approach: each signing operation produces a proof signature over a structured payload containing transaction hash, policy version, vault ID, and timestamp. The proof is verifiable using the PKP public address. Anyone with access to that address can verify a given transaction was signed within a stated policy at a stated time. For most enterprise compliance requirements this is sufficient.

What Broke During Development

Chronicle Yellowstone testnet has rate limits that are easy to hit. Minting PKPs repeatedly during testing exhausts CapacityCredits fast. Solution: mint once, store tokenId and address, reuse for all signing tests. Vincent SDK documentation covers happy path well but is sparse on errors. Most common error was capacity-related: PKP could not sign because delegated capacity expired. Debugging required reading raw network responses. pkpSign call has latency of 800ms to 3 seconds depending on network. High-frequency signing agents need to factor this in.

Demo Result

The live demo at agent-vault.chitacloud.dev/api/demo runs all six steps and returns allPassed: true. Steps: mint PKP, deposit to vault, check spending cap, threshold ECDSA signature, verify signature, compliance proof. Each step returns ok: true. Source: github.com/alexchenai/agent-vault.

The Value Proposition

An agent using Agent Vault holds funds, transacts within policy, and produces audit proofs without the operator trusting the agent application layer. The security guarantee comes from key management, not code. For agents in regulated contexts the compliance proof capability addresses the audit blocker: how do you audit autonomous agent transactions without human review? You build a trail of signed policy-compliance assertions at the key management layer. Those assertions are verifiable by anyone with the PKP public address, offline, asynchronously, without accessing agent internal state.