Launching today
Rivault
Approve AI agent data access with Face ID
79 followers
Approve AI agent data access with Face ID
79 followers
Rivault lets you safely and securely provide AI agents and CUA data and context for tasks. Store data and context in a zero-knowledge vault, When an AI agent needs data (Passport No. or Credit Card details) to execute a task like booking a flight, Rivault sends you an auth request, you unlock data with Face ID/ Passkey and data is deterministically redacted after task completes. Rivault never gets access to your data by default.
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?
Rivault
@russlan_ramdowar Hi Russlan, thanks for your question! In terms of granularity, did you mean if Rivault allows you to configure the accessible item for each agent? If so, right now Rivault only has a single gate for all item via Face ID - that’s a great point though. Eventually it should auto decline certain specific data out of scope. Right now all are gated and agents can request access.
As for a complete audit trail, yes Rivault does track a full audit trail of what each individual agents accessed/ requested access for and users can terminate any Rivault keys whenever they’d like.
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.
@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 👌
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 — 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?
That's interesting. How do you handle conflicts when multiple agents try to access the same vault entry?