Skip to main content
Errands run now. This page still separates what is true of the design from what is implemented, because the difference is the only part of a privacy page worth reading — and two differences are named below: the erasure routine and revocation.

What your assistant never sees

No credential ever enters your assistant’s context, or the model’s. Not a password, not a one-time code, not a token for a third party. When Hence Assistant needs one, it sends your assistant a link; you open it and enter the value on a single-use page on our domain, and it goes from your browser into the one form it was requested for. Your assistant sees what you would tell a person helping you: which errand is running, what question is pending, what the result was. That last part is not nothing — a result can carry an APR, a balance or a match formula, and those pass through the conversation like any other answer, subject to whatever your assistant’s provider retains. What it never holds is a credential, a one-time code or a third-party token, and a screenshot of a signed-in page never passes through it at all.

What Hence Assistant stores

When an errand runs, it records the task and its steps, the receipt for each act, the audit trail for each single-use credential fill, an account or routing number you typed on a fill page — sealed under a key held for your household, that sealed copy kept on the same clock as the rest of the errand’s record — and, where you typed a figure yourself, an observation on your financial profile. Screenshots are captured during a step and kept for 30 days, encrypted under a key held for your household (what that means); a statement an errand downloads would be kept here too, though no errand downloads one today. A number you typed is sealed on the errand’s record on the errand’s clock and is also in any capture taken of the page you typed it into, on the screenshots’ own 30-day clock — so one identifier can be held in both places at once, on two clocks that run separately. A figure you type in answer to a question may be recorded on your financial profile. When an errand asks you for something the profile already has a place for, your answer is written there as your own stated value — which is what lets a later errand read it instead of asking you again. Only the household-wide ones land today; your filing status is the one the errands currently ask for. An answer that belongs to a particular person or account is attempted and refused until that half is built. What is recorded is the figure, not the conversation around it. An identifier you supply is never written there. An account or routing number goes to the one form it was requested for and to no profile. It is not held the way a credential is, and the difference is worth stating plainly: a credential never enters your assistant’s context or the model’s at all, while an identifier is the very thing a step has to type — so it is unsealed while the errand runs, and the model turn of any live step of that errand can be handed it. Neither travels through your assistant: both are typed by you on our own page. The step that types an identifier also sends it out of here, and those copies are not on the errand’s clock. The request carrying it goes through our own model gateway and on to the model provider. The gateway leaves two copies: an archive we delete on a 30-day clock, and the gateway’s own log, whose matching 30-day deletion is built but not yet switched on — until it is, that copy is held back only by the gateway’s capacity, so on a quiet month it can sit there indefinitely. What the provider retains is on its terms rather than ours. An erasure request walks our own stores; it does not reach either of those. The figures an errand READS off a page are still not stored. A step’s own account of what it found is discarded when the step lands, so an APR or a match formula it establishes on your behalf is not written into your financial profile — which is where such a figure is designed to go. Until that write exists, an errand leaves behind the record of the act and not the number it read. Screenshots are kept 30 days, in force since 2026-09-14. They are removed on that clock whether or not you ask, and the same rule would cover a downloaded statement if an errand ever kept one. The records of the acts themselves — tasks, steps, receipts, events — are kept while you are a customer; a receipt therefore outlives the capture it cites, and a reference older than 30 days points at nothing.

Asking for erasure

To ask what is held about you, or to ask for it to be erased, write to privacy@usehence.com. Erasure completes within 30 days for application data, plus up to 28 days for copies in our database backups and up to 30 days for copies in our file storage to be erased. Nothing about it is instant, and we will not claim otherwise: for that window, copies survive in backups we cannot reach individually, and they age out rather than being picked out. How long we keep your data while you are a customer and how long an erasure takes are different questions, and the paragraph above answers the first. Errand records are in that path. An erasure request deletes your task threads and their runs, steps, receipts, events, approvals and single-use-fill trails, along with the host connections that acted as you, and the execution object store is one of the stores the routine walks. The routine enumerates its stores rather than relying on a cascade, which is why each new one is added to it by hand; the screenshots a step captured are enumerated there, so an erasure request removes them ahead of the 30-day clock rather than waiting for it. Two stores are walked twice, and the second pass is what the routine waits on. A capture that was already under way when the first pass ran can finish writing just after it, and an errand that was already running writes the short note that says it started in the same way — so the routine walks the screenshots, and the memory the assistant keeps for your household (Cloudflare Agent Memory), a second time once the records that let either be written at all are gone. The request is not recorded as done while either second pass is still owed. Three cases fall outside those passes: a write that lands after the second pass has already run; a store whose deletion was switched off between the two passes, where the second pass has nothing it is allowed to walk; and a request that was already parked waiting on an outside service on the day the second pass was added, because the check that confirms such a request finished reads each store’s own ledger rather than the record of that pass — and nothing on that lane could have run the pass for it in any case. What is left over in those cases is a screenshot, bounded by the same 30-day clock, or a note in the memory the assistant keeps, which carries no clock we can state: the service that stores it publishes no retention window, so we will not promise you one. That third case is bounded to requests made before the change: every request since is held by the pass.

Screenshots are not redacted during the pilot

Screenshots taken during the pilot are captured unredacted. An authenticated account page is captured as it appears, account numbers included. Those bytes are kept exactly as captured, for 30 days, encrypted at rest. Nothing reaches your assistant’s transcript — a result points at a capture rather than carrying it — and nothing about that masks what the capture shows.Redacting at capture is planned after the first release, with no date attached, and it is not what opens access beyond the current pilot group. What bounds an unredacted capture in the meantime is on this page: it is encrypted at rest under a key held for your household, deleted after 30 days or on erasure, and never placed in your assistant’s transcript. No other customer can reach it and no surface plays it back to you — but Hence staff can restore it from that store while it lives.

How to revoke a connection

Remove the Hence connector in your host’s settings. It stops being able to call us at that moment, and no further errand can be started through it.
Revoking does not yet cancel runs already in flight, and does not purge stored data. Cancelling every live errand on revocation is built on our side; what is missing is the signal that it happened — your host does not tell us, and there is no disconnect action in the Hence app yet. The purge is not built at all. Until both are: cancel any task you want stopped before you disconnect (how to stop a task), and write to privacy@usehence.com to ask for erasure.

Who can run errands right now

Access is gated to a single-operator internal pilot — one internal account, enabled by hand, not a domain and not a signup list — and it is evaluated on our side for the signed-in user at the moment a tool is called. Anyone may add the connector and complete the consent flow; if access is not enabled, every tool refuses cleanly and says so. Everything on this page — the unredacted screenshots most of all — is confined by that gate to that one account while the pilot runs.

The limits that do not move

  • Hence Assistant does not move money between your accounts.
  • Hence Assistant does not sign anything, elect anything, or prove your identity on your behalf.
  • Hence Assistant does not enter a credential itself; every credential is entered by you, once, on our page.
  • An errand that meets a hard stop — an active debt lawsuit, identity theft, insolvency, an irreversible tax election — stops and points you at a professional.

How to report a problem

A suspected security issue: security@usehence.com. A privacy request, or a question about what is held about you: privacy@usehence.com. Anything else — a result you cannot reconcile, or a page here that does not match what you see — goes to whoever invited you to the pilot. A public support address will be listed here when the pilot opens.