Need-to-Know: a data agent built not to leak

Problem

Teams want AI agents to analyze sensitive data, but an agent with query access can leak identifiers or small groups that point to individuals. A prompt instruction is not a control that an auditor can verify.

Approach

• Raw records sit in a SQLite vault behind an MCP server with exactly five tools and no raw-row query tool, so identifiers cannot leave through the tool schema.
• A typed release contract with no LLM in it enforces the policy: an allowlisted purpose and audience, aggregate-only columns, groups of at least 3, no unapproved joins or filters, and content hashes over the exact payload.
• Each release needs human approval in the agent harness and is re-checked at execution time; any failure blocks the release and writes an audit record.
• Evidence bundles and a verify-receipt CLI let a reviewer confirm offline that approval came before release and recompute the hashes.
• Adversarial test gates attempt raw exports and small-cell leaks and must end with zero releases.

Architecture

1. Data steward
2. LLM agent
3. Vault MCP
4. Release contract
5. Human approval
6. Verifiable receipt

Outcome

I built it for the TrueForge Agent Harness Hackathon. The adversarial gates end with zero releases. In the demo, 12 of 13 scripted runs finished cleanly, and I document the one that didn't.

What I learnedPutting the policy in deterministic code outside the model is what lets someone who does not trust the agent check the guarantee.