Inspiration

I run more than one AI agent against my own financial life — a daily catalyst-brief agent I built for OpenAI Build Week (Portfolio Pulse), plus general-purpose assistants I use it for ad-hoc questions. Every time I bring in a new one, I'm either re-explaining my holdings, horizon, and strategy from scratch, or I'm just handing over broad access because retyping context every time isn't realistic. Neither felt right — especially the second one, the moment I imagined a third-party agent (not one I built or trust the internals of) sitting in that same position.

AI Passport's core idea — a user-owned context layer that apps request access to, rather than silently accumulate — was the first framing I'd seen that actually matched this problem. The Agents track was the obvious fit: I wasn't solving a hypothetical, I was solving something I already hit building Portfolio Pulse.

What it does

MRZ is a mockup of the permission layer that would sit between a user's financial context and any agent that wants to use it:

  • A bio-data page holds the schema: holdings, sector exposure, horizon, strategy style, watch patterns, active evaluations — each tagged by sensitivity (Public / Restricted / Confidential).
  • Agent request cardsshow three agents — a personal daily-brief agent, a third-party signal agent, and a general assistant — each asking for specific fields, for a stated purpose, for a bounded duration. Grants are per-field, not per-agent — the third-party agent, for example, never gets holdings, only derived fields like horizon and strategy_style.
  • A write-back proposal shows an agent noticing a new pattern and proposing it as a Passport update, rather than storing it silently — the user has to accept it.
  • A machine-readable log, styled after the MRZ strip on a real passport, records every grant, denial, and write in real time — the audit trail the name comes from.

How I built it

Since this was the build lane, I wanted something interactive rather than static slides — a working mockup a judge could actually click through instead of reading about. I built it as a single self-contained HTML/CSS/JS file: vanilla JS for the state (which agent has which field granted), CSS custom properties for the passport- inspired theme (ink-navy, brass/gold accents, a paper-toned bio-data section), and IBM Plex Mono for the MRZ log to lean into the real machine-readable-zone reference.

I started from a real schema — the actual fields a catalyst-brief agent like Portfolio Pulse would need — rather than inventing generic placeholder data, so the demo reflects a real use case instead of a hypothetical one.

Challenges I ran into

  • Deciding sensitivity tiers wasn't obvious. Is sector_exposure more sensitive than horizon? I had to actually think through what each field reveals on its own vs. combined with others before I could tag them Public/Restricted/Confidential in a way I could defend.
  • Making "least privilege" visible, not just implemented. It's easy to build a toggle UI; it's harder to make a judge instantly see why the third-party agent is denied holdings while the personal agent isn't, without a paragraph of explanation next to every card.
  • Avoiding a generic dashboard look. My first instinct was a standard settings- page UI. Leaning into the actual passport metaphor (bio-data page, stamps, MRZ strip) took more design thought but made the permission model feel concrete instead of abstract.

Accomplishments that I'm proud of

Getting the write-back flow to feel meaningfully different from a normal permission toggle — it's the part of AI Passport I think is easiest to skip past, since "agent proposes, user approves" is a subtler UX problem than "agent asks, user grants."

What I learned

(This one's genuinely yours to fill in — what surprised you building this, what you'd do differently, anything from actually working through the permission model that changed how you think about your own agents.)

What's next for MRZ

  • Flag requests that expand an agent's previously granted scope, so scope creep is visible instead of blending in with routine renewals.
  • Extend the schema beyond financial context to test whether the same field-level grant model holds up for other data types.
  • Wire it to a real agent (Portfolio Pulse) instead of mock requests, to see where the permission flow breaks under actual use.

Built With

Share this project:

Updates

Submission history