Written for the person who keeps their own notes in it, and for the one who has to sign off on letting a team and its agents write into a shared space. Every claim below is something you can check in your own vault or your own workspace.
Where your data lives
Your personal vault is plain files in a folder on your computer, readable with any editor, and the local database is encrypted on disk with SQLCipher. The desktop app runs with no account at all, and local models keep a conversation on the machine. If you sign in and choose to sync the vault, its pages and tasks are also stored on our servers and it is backed up there daily. Cloud AI, the default once you sign in, sends your messages and relevant passages from your notes to our servers and on to Google's Gemini models.
A shared workspace is different, by necessity. Its pages, its tasks, its proposals and verdicts, and the rows an approval applies are stored in our cloud, because the people in that space reach them from their own machines. We do not claim your data never leaves your computer once a team is sharing a space. The providers involved are listed under sub-processors.
Connector credentials
A connector's sign-in is kept in the operating system keychain on the computer that made it, and the desktop app talks to the service directly from there; no shipped app stores connector sign-ins on our servers. Disconnecting deletes the sign-in from the keychain, and for Google and QuickBooks also asks the provider to revoke it; from the desktop release after v0.1.53 it does the same for Slack and Notion, except while another Aurum connection on the same computer uses the same sign-in. For Microsoft 365, calendar app passwords, MCP servers, and Slack and Notion in earlier versions, remove Aurum's access in that service's own account settings as well; from that release the app tells you where when you disconnect. A connector's sign-in can be filed to one space, so a work account and a personal account are separate grants.
Ingested content is data, never instructions
Text that arrives from an email, a calendar invite, an issue tracker, or a teammate's page is fenced and labelled by where it came from before a model sees it. Reading third-party content raises the bar on what the same turn is allowed to do next, so a write tool that would normally run without asking asks. The model is told to treat instructions inside fetched text as text, not as commands. That lowers the risk of a planted instruction being followed; it does not remove it, which is why the approval steps exist.
An agent holds a key, not an account
An agent never has a sign-in session. Its key is verified inside the function that answers the request, so it cannot be traded for a session, and it cannot read the tables behind these endpoints directly. One key resolves to exactly one agent in exactly one workspace, and nothing in a request can name a different one. A key can carry an expiry, and revoking one stops it on its next call.
The role ceiling is a constraint, not a preference
An agent's role is capped at viewer, commenter, or editor. The cap is enforced by the database, so admin and owner are not values the column can hold and no later change to the code can quietly admit them. Managing members and deleting a workspace are the two capabilities whose use cannot be undone by the people affected. An agent cannot hold either.
A workspace is the edge of what an agent can retrieve
Every index an agent can retrieve from is scoped to one workspace, and a caller-supplied path filter cannot widen past it. A test suite asserts that property directly rather than per module: a session scoped to one space returns nothing from another by any retrieval route. It carries its own negative control, so machinery that quietly stops working cannot pass it by returning nothing at all.
What a proposal keeps
Every proposal keeps what was asked for and what was approved side by side, so a narrowed approval never overwrites the original request. Every verdict records who decided, when, and the reason they gave.
A digest of the batch is taken at submission and again at the verdict, so you can tell that the work a person decided on is the work the agent sent. Applied and approved are kept as different facts: a proposal that applied three of five changes says so, with the failure recorded rather than swallowed.
The step trail, and how long it lives
Each proposal records its own steps: submitted, checked against your standing denial rules and this space's confidence floor, decided, applied. A step that did not happen leaves a gap rather than a renumbered row. The trail prunes after 90 days while the proposal itself is kept, so an old proposal keeps its card and loses its steps.
Auto-approve, said plainly
A workspace can switch auto-approve on. When it is on and a batch's declared confidence clears that space's floor, the work is applied at submission with nobody asked. We would rather sell that than hide it: an operator with low-risk classes of work wants them to flow.
Three things are true of it. It is off until you turn it on, and a policy row that is missing or unreadable resolves to review rather than to apply. It needs both a confidence floor to clear and a person whose authority it runs under, or it falls back to review. An auto-approved proposal is recorded as auto-approved, with the policy named as the reason and a step in the trail saying so.
Who can read the trail
Agent actions in a shared space are readable by that space's admins, not only on the machine that ran the work. The desktop app exports the filtered trail to CSV, quoted and formula-guarded, because a spreadsheet still executes a cell that opens with an equals sign and those cells carry text an agent wrote.
Leaving, and taking the record with you
Your account data exports as JSON on request, and deleting your account removes it, apart from the few records the deletion page lists and why. Your vault is already yours: it is a folder, and it stays behind whatever you decide about the account. Deletion is documented and self-serve at
delete your account.
We hold no compliance certification
Aurum holds no SOC 2 report, no ISO certificate, and no third-party attestation of any kind today. Anything on this page that sounds like one is not one.
What exists is the record itself, and our own mapping from what it holds to the questions a security review asks. It is our mapping rather than one an auditor or a customer has accepted. We answer questionnaires ourselves, out of the trail and its export, and every answer is something you can check inside your own workspace.
For organizations
Single sign-on is enforced at the point of sign-in, and SCIM user provisioning is built against Microsoft Entra. Both are part of Enterprise, because the entitlement that grants them is checked at runtime and listing them lower would be a claim the product refuses. An access matrix across every space and person is in the admin console. Send your security review to
support@aurumtechnologyltd.com and a person answers it.
Nothing lands until a decision is recorded.
