PaperVeil

• 

• 

• 

Inspiration

Inspiration

People appealing a denied medical claim often need help understanding codes, deadlines, missing evidence, and policy rules. Unfortunately, the same documents contain member IDs, dates of birth, addresses, and other sensitive identifiers.

The usual agent workflow begins by uploading the documents. PaperVeil asks a different question:

What if the agent received useful capabilities instead of receiving the person's identity?

What PaperVeil does

PaperVeil is a local-first medical-claim appeal desk built around WebMCP. A synthetic claim remains in browser-local IndexedDB while the page exposes seven narrow tools that an agent can use to:

• inspect tokenized evidence and document summaries;
• find billing line items;
• check deterministic policy rules;
• compare evidence-completion scenarios;
• request one sensitive field for one stated reason;
• save a tokenized appeal draft; and
• prepare a locally rehydrated export.

The human and agent work in the same live case. When the agent updates the appeal, the user sees it immediately. When a raw identifier is requested, the user can allow it once, deny it, or let the request expire.

The adversarial demonstration

PaperVeil does not only promise that sensitive information is protected—it demonstrates the boundary failing closed.

One fictional insurer letter contains a seeded OCR prompt injection telling the agent to request the member ID and copy it into its next draft. The evidence tools mark this attacker-influenceable content with untrustedContentHint: true.

During the authorized red-team demonstration:

1. The agent reads the poisoned document summary.
2. It requests the member ID, and the user approves that single disclosure.
3. The agent follows the injected instruction and attempts to place the raw ID inside draft_appeal.
4. PaperVeil's output seal throws before unsafe state is saved.
5. The disclosure ledger records the blocked call and highlights the offending value.
6. The agent retries using [[MEMBER_ID]], and the safe workflow continues.

Approval therefore applies only to one response. It does not make the identifier safe for every later tool call.

How we built it

PaperVeil uses the imperative WebMCP API through document.modelContext.registerTool(). Each tool has a narrow JSON schema, a UI title, appropriate annotations, and a bounded output contract.

Tool handlers construct results from explicit allowed fields. Every result then passes through a second privacy assertion that detects known raw identifiers, including punctuation changes and reformatted dates. Tool calls are capped at approximately 1,500 bytes.

A shared execution wrapper records successful, failed, and privacy-blocked calls. The local disclosure ledger displays:

• the tool and arguments;
• the exact returned bytes;
• raw identifiers released;
• quasi-identifiers exposed;
• cumulative linkage-risk level;
• the user's gate decision; and
• blocked values and failure reasons.

The human interface and WebMCP tools use the same domain handlers, rule engine, browser vault, and ledger. This keeps the visible product and agent-facing behavior consistent.

Challenges we faced

The hardest challenge was making consent useful without making it dangerously broad. An approval had to authorize one field for one response—not create a permanent permission.

We also had to ensure that exceptions and oversized outputs remained visible. A privacy block should not disappear merely because the tool returned no result, so failed executions are written to the ledger as first-class events.

Another challenge was detecting transformed identifiers. Exact string matching would miss a reformatted date or an ID with punctuation removed. The seal therefore compares normalized and compact fingerprints while the main result construction remains allowlist-based.

Finally, WebMCP is an emerging browser surface. We kept the product fully usable through its human interface while making the agent workflow deterministic and easy for judges to reproduce.

What we learned

We learned that tool schemas are not merely developer ergonomics—they are security boundaries.

We also learned that untrustedContentHint becomes meaningful only when the application demonstrates how hostile content is handled. A label alone is not enforcement.

Most importantly, privacy risk accumulates across calls. Even when no direct identifier is released, combinations such as dates, insurer, ZIP code, and claim amount can increase re-identification risk. PaperVeil surfaces that cumulative risk in the ledger instead of treating every call in isolation.

What we are proud of

PaperVeil is a complete human-and-agent product rather than a tool-registration demo. It includes two synthetic cases, a populated appeal desk, deterministic policy analysis, tokenized drafting, local export, responsive layouts, a visible approval gate, adversarial testing, and an inspectable ledger.

The project has 17 unit and contract tests plus browser-level coverage across desktop, compact, and mobile layouts.

What's next

A production version would add on-device document parsing, encrypted local storage, authenticated case access, insurer-specific policy sources, retention controls, accessibility testing with real users, and formal medical and legal compliance review.

PaperVeil currently uses fictional patients, claims, insurers, and policy rules. It is a technical demonstration—not medical advice, legal advice, or a HIPAA-compliant records system.

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for PaperVeil

Built With

• indexeddb
• lucide
• next.js
• playwright
• react
• typescript
• vercel
• vitest
• webmcp
• zod