Rivault
Approve AI agent data access with Face ID
104 followers
Approve AI agent data access with Face ID
104 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.
Rivault
Hi ProductHunt! 👋 I created Rivault to solve for the friction and worry of typing in sensitive details and data (SSN, payment details, phone number, emails) for CUA to automate tasks. This allowed me to store, manage and own those data without having any sensitive data stored in session logs and memory.
Please let me know what do you think about Rivault and if you have any questions! 🙇♂️
P.s. If you are interested in this space and would like to build together, send me a DM or reach out to me on LinkedIn!
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?
Rivault
@vollos Hey Chalermpon, great question! The agent will consolidate all required data requests at each step or phase and perform a group auth request for that batch of required data, users can audit the full list before approval + Face ID. Those data gets a time bound lifespan for the task session, so if the subsequent task requires a data from the already approved prior step, it can be reused. if it is a new piece of data required, a new auth request will be sent.
@hyu_lim Good, that clears up the new-vs-reused split. One nuance I'm still curious about on the reuse side: when a later step pulls from data that's already approved, does the check confirm it's for the same original purpose or action, or just that the data itself was unlocked this session, meaning it could get reused for a different action than what it was originally approved for?
ClinicFrame
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?
Rivault
@clemente_lopez1 Hey Clemente, thanks for writing in and sharing your thoughts! The window of the value existing on the DOM level also persists across manually executed task - I am currently experimenting with other techniques through browser extension for end to end execution without providing agents any visibility to values, as for the screenshots the redaction mechanism covers that too! (Spent quite a while working on that) The redaction also covers every trail left by the agent (across all supported platforms). So by the time the task completes, no sensitive data would be left behind.
Hope this helps! Those are some great and sharp points. There are definitely opportunities in making Rivault even more robust which I will keep revving on - but for now, Rivault makes it much safer than pasting sensitive data in plaintext
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?
Rivault
@anand_thakkar1 Hey Anand, thats a great point and is something that I've been considering as well. As of right now I think thats a meaningful trade off with the data input re-attempted after unlock. To clarify, the full redaction deterministically happens at the time of when the task session ends (completed or not) or at a defined timeout.
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.
Rivault
@ark_y_k Hey Yuki, thats a stellar point. Right now Rivault solves that "on the fly" prompt injection by providing users visibility into the intent of that data retrieval, users will be communicated and notified of the agent's intent for retrieving those data during auth and the user can approve or deny it if the agent has been steered off course.
@hyu_lim Surfacing the intent behind each retrieval is a reasonable first line, and it's honest — you're not claiming to have solved injection, you're keeping a human in the position to catch it.
The part I'd worry about is notification fatigue doing the attacker's work for them. An agent that legitimately reads twenty things an hour trains me to approve without reading, and then the malicious twenty-first arrives looking like all the others. The attacks that scare me aren't the ones with obviously wrong intent, they're the ones that read as plausible.
Is there any notion of a retrieval being unusual relative to that agent's normal pattern, so the alerts can be rare enough to still mean something? Otherwise the security ends up resting on the user's attention, which is the resource that runs out first.
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?
Rivault
@narek_keshishyan Hi Narek, thats a great question! Right now Rivault works best for a dedicated data type/ shape. The open ended freeform note is something to think about - perhaps using the model to identify and redact a string of detail might work.
@hyu_lim A model-side redactor for freeform is doable, but it changes the shape of the guarantee in a way worth being explicit about. With typed fields you can state recall: the passport regex either matches or it doesn't, and you can enumerate what a miss looks like. With a paragraph someone wrote about their own situation there's no schema to diff against, so you can't measure what you missed without labels you don't have. One miss is the whole breach, and it stays invisible.
The other half is where the redactor runs. If the reason you're redacting is that a third party shouldn't see the text, a model that reads the text in order to redact it has to sit inside the trusted boundary, not past it. That's the fork I hit: I ended up ruling that a certain class of content never leaves the device at all, which is a weaker product and a much stronger promise, because there's no store and no log and so nothing to redact. Post-hoc redaction is the right tool when the data has to move. It just can't be the answer to "what if it shouldn't have moved".
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
Rivault
@galdayan Hi Gal, thanks for sharing your thoughts. Right now the core problem Rivault solves for is to prevent a build up and storing of critical and sensitive data on a device and prevent those data from being exfiltrated during external prompt injection (non installed attacks from the web. that’s the core vulnerability of CUA and browser use agents)
Rivault does not cover the scope of a locally compromised device - in those cases even manual human executed tasks will be vulnerable.
@hyu_lim that's a fair line to draw honestly. most security products blur that boundary and imply they cover everything, so respect for just saying it plainly. makes sense - you're solving the exfil-in-transit problem, not endpoint trust.