Pursor reads. Where it writes, a person pressed the button.
Almost every connection Pursor holds is only ever read. Pursor cannot move money, pay a bill, approve a payment or send anything from your systems. On a bank feed, a spend platform or a store, the write permissions are not requested at all, so they are not there to be misused.
The exception is your ERP, and it is worth reading carefully. No agent writes there on a schedule or on its own judgment. Every write starts with a person pressing a button in Pursor, and there are four things that button can do.
- Draft a supplier invoice for a bill that already exists in your spend platform and is not yet in the ledger. It is never validated and never posted by Pursor; a person does that in the ERP, and until they do it changes no balance and no report. Undo deletes a draft Pursor made, and only while it is still a draft.
- Draft a journal entry an agent has worked out, such as the entry that clears an account. It lands as a draft and changes nothing until it is posted.
- Post a draft journal. This one does change your books, so it is kept to your own administrators, your named account manager and Pursor’s operations staff acting for you. Before posting, Pursor reads the draft again and refuses if it has been changed, if it is no longer a draft, or if the period has closed. Undo posts a reversing entry; it never deletes.
- Create a bank rule, when someone turns a coding decision into a rule. A rule keeps acting on future transactions, so what stood before and what was sent are both logged, and Undo removes it.
All four go through a single function in our code. It plans the whole write before making it, and it stops rather than guesses: an unrecognised supplier, an account code that is not in your chart, a date inside a closed period, and the item is held for a person instead. Every write is recorded with who pressed it and exactly what was sent, before we rely on the result, so you can ask us what Pursor has ever written to your ledger and get a list rather than a promise.
Everything else an agent concludes is a numbered step for a person, naming the record and who owns it. A person does it, in the system, with their own login.
You hold the keys
Banks connect through Plaid. You go through the bank’s own login in the Plaid window; Pursor never sees, holds or stores a bank credential, and the connection can be removed from both Plaid and Pursor in one step.
Spend platforms and ERPs connect through their own APIs. On Ramp, the credential belongs to an app you create in your own Ramp account, with the permissions listed on your own screen; revoking it there ends the connection. On the ERP, Pursor is a user you created and can disable. That user can do whatever you permit it to do, so its permissions are yours to set, and Pursor uses it only for the four writes described above. On QuickBooks, you authorise Pursor through Intuit’s own sign-in for one scope. Intuit offers no read-only accounting scope, so the grant permits more than Pursor uses: Pursor only reads through it and never writes. You can remove it from QuickBooks’ own Apps page or from Pursor; either way the token is revoked and what was read is deleted.
There is no shared master credential. Each connection is yours, and each can be cut without asking us.
What we store, and what we throw away
Pursor keeps what the agents work from: bank balances and transactions, card charges, open bills and purchase orders, the forecast, and the answers people give (which payment settled which order, who owns which card). It keeps the reasoning behind each finding, so a person can see how it knew and correct it.
It does not keep documents it does not need, does not copy your ERP, and does not build anything that could be mistaken for a second set of books. Your ledger stays your ledger.
The AI is not trained on your data
Pursor uses Anthropic’s Claude through its commercial API to read a document and decide what it means. Anthropic states that, by default, it does not use inputs or outputs from its commercial products to train its models. We have not opted in to any feedback or training mechanism, and we never will.
The model has no memory between requests. Each call is one document and what Pursor already knows, and nothing is retained by the model afterwards. Anything Pursor remembers about your business is written deliberately into our own database, and you can read it.
Who sees it
Your own people, as you decide. Your accounting firm, if you put one on the account. Your account manager at Pursor, who implements the agents and reviews what they hand up. Nobody else.
Every customer’s data is scoped to their company at the query level. A firm sees the clients it has been attached to and no others.
How it is protected
- Connection tokens are encrypted with AES-256-GCM before they are stored, under a key held outside the database.
- All traffic runs over TLS. Data is encrypted at rest by our database provider.
- Pursor never asks for, holds or stores a password to any of your systems. Your bank, your ERP and your spend platform are reached through their own connection flows, never by a login you hand over.
- Billing is by bank debit through Stripe. Pursor never sees your bank account number.
Who else is involved
Plaid (bank connections), Intuit (QuickBooks connections), Anthropic (the model), Neon (the database), Vercel (hosting), Stripe (billing) and Postmark (the emails Pursor sends). Plus the systems you connect, through their own APIs. We do not sell data, we do not share it with anyone else, and there is no advertising or analytics product anywhere near it.
When you leave
Disconnecting a source removes the connection at both ends and deletes what Pursor read from it. That is a button, and it does not need our permission. Closing the whole account deletes what Pursor holds about the company; today that is done on request, by a person, and is not yet a button of its own.
Certification
Pursor does not yet hold SOC 2 or ISO 27001. Independent audit is planned, and the report will be published on this page when it exists. We will not describe a policy document as a certification in the meantime.
Until then, everything above is checkable without taking our word for it: the scopes on your own developer console, the connection screens, and the vendors’ published policies. If your assessment needs more than that today, we would rather you told us than found out later.