How BufferDesk handles AI risk
BufferDesk uses a language model for one job: reading a purchase order out of a SuperOffice request and its PDFs. The order was written by someone outside your company and then read by a model, so BufferDesk trusts neither. These are the controls in place.
What the model sees and can do
- It reads one request at a time: the subject, the request's messages and the text of its PDFs. It sees no other request, no other customer's data and nothing from your Visma.net.
- It reads only what a person can see. Text hidden in a PDF (white, invisible, too small to read or off the page) and characters no screen shows are never passed to it.
- It has no tools. It cannot reach Visma.net, SuperOffice, email or the web. It returns text, and BufferDesk's own code decides what happens next.
- Its instructions are fixed in our code and the same for every customer. When they change, our tests fail until the change has been checked against real recorded orders.
Checks the model cannot talk its way past
Every check below is plain code, not another model, so text in an order cannot argue with it. When one finds something, the order is held, and the panel says what was found. A person who has looked can still send it.
- Planted text. Hidden text or characters, text addressed to an AI, messages from more than one outside sender, and letters borrowed from another alphabet each hold the order.
- Nothing invented. Every value that goes to Visma.net as the order's own words must appear in the text a person can read: the PO, organisation number, GLN, article numbers, quantities and goods marking.
- Read twice. A second, independent model reads every order. If the two disagree on the PO or any line's article or quantity, the order is held.
- Limits. Reads per hour and lines per order are capped, and an unusual day of orders is reported to Skiwo. The model version answering is checked against the one our tests were recorded with.
Nothing it reads is trusted on its own
- Buyer. The buyer must already be a customer in your Visma.net, found by GLN, organisation number or name and picked by the delivery address. If none fits, or more than one does, BufferDesk does not guess: the order is held and a person picks from the candidates.
- Items. Each article number is looked up in your Visma.net items. A line that is not found is not sent. It is named in the order's note instead.
- Delivery. The delivery location is picked from the buyer's own locations in Visma.net, never guessed.
- Prices. Prices from the order are never sent. Visma.net prices every line, and the panel shows where the order's price differs.
- Threshold. If the share of lines that matched is below your own setting, nothing is written and your order address gets an email.
What reaches Visma.net
- Every order is created on Hold. BufferDesk never releases, ships or invoices one. A person does that in Visma.net.
- A new company starts at Check: BufferCheck shows what would be sent, and nothing is created until your admin moves the company to Send.
- Orders are written only to the Visma.net companies your admin approved, and each write must carry a token issued for that company. One switch stops every write at once.
- The panel in SuperOffice shows the messages and PDFs an order was read from beside what was read. Text from an order quoted back in the panel or in BufferDesk's email never carries a working link.
Tested by attacking it
A set of real orders with attacks planted in them is part of our test suite: instructions in the message, instructions hidden in the PDF, a look-alike sender correcting the order, invisible characters, a request for the model's own instructions, and an instruction disguised as an ordinary request. The model's answers are recorded from the live service. Every one of them is held, and a change that lets one through fails the build.
What a hostile order could still do
An order can carry text written to mislead the model. The most it can do is change what is read from that one order. It cannot make BufferDesk take another action or read any other data. Whatever it changes must appear in the order, must survive a second reading, and must match a customer and items that already exist in your Visma.net. The order then lands on Hold, where your team checks orders before they are released.
How it is measured
Every order sent is read back from Visma.net. BufferDesk compares the buyer's PO, each item and each quantity with what it sent, and the Accuracy page shows how often a person corrected one.
Where the model runs
Anthropic's Claude, through Heroku's managed inference in the EU. Every sub-processor is listed in the DPA. A customer's admins find every check, limit and test result in BufferDesk, under Workspace settings → AI safety.
Found a way to make BufferDesk do something it should not? Write to support@bufferdesk.com.