Rivault

Approve AI agent data access with Face ID

Productivity

Artificial Intelligence

Tech

Visit WebsiteSee on Product HuntInstagram ⧉Twitter ⧉

Deterministic redaction after the task completes is the interesting part, most approaches gate access up front and then hope. Question: how do you scope a multi step task where the agent needs the data twice, say booking the flight and then adding it to the hotel reservation? Does each use trigger its own Face ID ask, or does one approval cover a task boundary you define? Where that line sits decides whether this is usable daily or death by prompts.

face id gate for agent data access is smart, gonna be a must-have soon 🔐 congrats!!

The design decision I would want to understand: during a session, does the raw value ever reach the agent's context, or does the agent only ever hold a reference to it?

Redacting after each session protects your vault, but it does not retract a passport number from everywhere it flowed while the session was live: the model provider's logs, a screenshot taken mid-task, a retry, a stack trace. Redaction after the fact is cleanup rather than containment.

The version I would trust most is one where the secret never enters the model's context at all, because substitution happens at the point of entry into the form rather than inside the agent's reasoning. Then there is nothing to redact and the guarantee is structural, not a promise about your own logging.

I build in a nearby space, and the thing I keep relearning is that users do not audit a retention policy. They ask one question: can it see the thing or not. A "never sees it" answer is far easier to defend than "sees it briefly, then forgets".

finally a clean way to hand sensitive info to AI without trusting it. the Face ID approval flow actually makes sense for booking tasks, and the zero-knowledge part gives real peace of mind.

this thread already covers the interesting security architecture questions, so here's a boring but real one - what happens on the recovery side if someone loses the device their Face ID/Passkey is tied to. is there an account recovery path back into the vault, and if so what stops that recovery flow itself from becoming the weak point that all the redaction and zero-knowledge design was supposed to avoid

@hyu_lim the auth-request + deterministic-redaction model is a real step up from pasting a PAN into a prompt — and +1 to Yuki's proxy-vs-hold point, since whether the agent ever sees the raw value or just a reference is the whole game under prompt injection.

Pushing into the payments case specifically: for a card at checkout, could Rivault hand the merchant a scoped single-use / network token instead of the real PAN? That would shrink both the PCI surface and the blast radius if the destination page turns out hostile.

And is a release bound to a destination — "this card unlocks only for delta.com checkout" — so a redirected or injected form can't draw it? Curious how you're thinking about the agentic-payment rails 👌

A dedicated context vault addresses a real problem for long-running agents. How granular are the permissions, and can access be revoked immediately with a complete audit trail of what each agent retrieved?

the whole thread is asking where the value goes after unlock, but I'm stuck a step earlier - the vault, the Face ID prompt, and the agent process are all running on the same device. if that device has anything actually malicious on it, or the CUA framework itself has a bug that lets it read process memory, does zero-knowledge storage even matter at that point, or is the entire security model resting on "trust the local machine" and everything after that is just making the honest-agent case safer

Hyu — most of the fields I saw were consumer-shaped (passport, credit card, SSN). WinBidIQ's agent handles company UEI numbers and CAGE codes, not personal PII. Can you define custom field types in the vault, or is it built around a fixed set of common credential types?

The credential injection problem in agentic workflows is real — I've seen teams paste sensitive values directly into agent prompts or env vars just to get things working, which creates a different kind of risk. Before integrating: is the vault configuration declarative, where you define which entries each task is allowed to access upfront, or does the agent request credentials at runtime dynamically? For a multi-step pipeline where different tasks need different secrets, I want to understand whether I can pre-authorize the full workflow rather than getting a Face ID gate on each individual lookup.

Everything in the thread so far treats sensitive data as fields — passport, card, SSN — and those are the tractable class precisely because they have a shape a redactor can match. The category I'd want to hear about is the one with no shape: the paragraph a person types describing their situation. A health detail, a legal problem, something about their kid. More damaging than a card number, can't be reissued, and no pattern finds it.

I build a consumer app where the most sensitive thing in the product is free text someone wrote in a bad moment, and the only answer I ended up trusting was architectural rather than filtering — certain content is contractually never allowed to leave the device, so there's no store, no log, and nothing to redact afterward. Deterministic redaction after the fact is a strictly weaker guarantee than never having transmitted it.

So: does Rivault hold context that isn't a typed field? If the vault carries a freeform note for the agent to use, what is the redaction matching against?

The hard part with secrets and agents isn't storage, it's that the moment a value lands in a context window it's effectively been disclosed. Anything that can steer the model afterwards can usually get it back out.

So the question I'd have is where Rivault sits in that sequence. Is it a vault the agent authenticates against and then holds the value, or does it stay in the path — proxying the call so the agent works with a reference and never sees the raw credential? Those are very different security properties under prompt injection, and only the second one really survives it.

Congrats on the launch, Hyu. The redaction covering screenshots and every trail across platforms answers the exact question I'd have asked first, most tools stop at "we don't log it" and never touch what the agent saw on screen. What I'd still want to know about the approval side: when a task needs more than one entry in sequence, say a card number for checkout, then an email for the receipt, does each pull need its own Face ID approval, or does unlocking once open a window the agent can draw from until the task finishes?

The zero-knowledge vault with Face ID unlock is a clean way to solve CUA credential injection. We've thought a lot about the tension between automation speed and human-in-the-loop gates when building agentic workflows. The auth request pattern is smart but introduces a latency dependency. How do you handle timeouts or retry logic when the user isn't available to unlock and the agent is already mid-task?

That's interesting. How do you handle conflicts when multiple agents try to access the same vault entry?

Hyu, the vault is the easy half of this problem, and I suspect you already know that.

Once the agent unlocks the passport number and types it into a page, that value exists in the DOM, in whatever screenshot the agent took to see the field, and in the model context that reasoned about the page. Deterministic redaction after the task covers your own store, not the trail the agent left getting there. Doing PHI redaction in healthcare, the downstream copies were the hard part every single time, never the storage.

Does the redaction reach the agent's screenshots and page context, or does that stay the responsibility of whoever runs the agent?