Security

Your data is safe. Read-only by architecture.

Read-only everywhere else is a setting somebody switched off and has to keep switched off. In Kipper there is no code that writes at all. The ability was never built, so a stolen password, a strange question or a mistake on our side all end the same way. Your accounts stay exactly as your accountant left them.

Below is how access works, what reaches a language model, where your data sits, and where we are on certification. Anything still in progress is described that way.

Read the DPA Talk to us

The objections, taken seriously

Six questions finance teams ask before they say yes

These are the real ones, in the order they usually come up. Each is a fair thing to ask.

“How do we know the answer is right?”

What is actually true

This is the most common question about AI in finance, and the right one to ask. The figure in an answer never comes from the model. Your question is translated into a database query, that query runs against your own records, and the number you see is the one the query returned. The model reads the question and phrases the reply, so there is no step where it could invent a total or recall one from somewhere else. Where Kipper has no answer, it says so rather than estimating.

“Could anything change our books?”

What is actually true

Nothing in Kipper writes. There is no create, no edit, no delete, and no code path that reaches for one. This is not a permission that could be misconfigured or a toggle an administrator could flip by accident. Even with full control of a Kipper account, the most anyone could do is read.

“Once we connect it, does it see everything, forever?”

What is actually true

Access is scoped twice. The connection itself is limited to the records Kipper answers from, and on NetSuite you choose the subsidiaries before anything is pulled. On top of that, your administrator decides inside Kipper which people can ask and what each of them is allowed to see. Disconnect whenever you want and the stored copy is deleted.

“Does the AI inherit whatever the connection can reach?”

What is actually true

That is a real problem with tools that hand an assistant the connection and let it act with those permissions. Kipper puts its own permission layer in front. Every question is resolved against what that specific person is allowed to see before any records are touched, and the check sits at the database level, so it applies no matter how the query was produced.

“Do our numbers end up training somebody's model?”

What is actually true

Every model call runs through Amazon Bedrock inside Kipper's own AWS account. Kipper never calls a model provider's API directly, so no provider receives your data for their own use. Under AWS's published documentation, Bedrock does not store inputs or outputs and does not train on them. Your data is not sold, rented, or used for anything except answering your team.

“How do we see who looked at what?”

What is actually true

Every question is logged with the person who asked and the time. That is usually better than the situation it replaces: today the same questions get answered by someone exporting a spreadsheet and sending it on, or pasting figures into a consumer AI tool, and none of that leaves a record anyone can review.

Bring your security review to a call.

We will walk your reviewer through the connection, the permission model and the audit log, on your own finance system.

Schedule free onboarding

How access actually works

From connecting the system to answering one question

01

One administrator connects the system

A single person with the right permissions in QuickBooks Online, Xero or NetSuite authorizes the connection. Nobody else needs an account on that finance system for Kipper to work.

02

The connection is scoped to reading

The authorization covers reading the records Kipper answers from. The scopes required vary by system, and some require administrative permissions in order to read at all. Kipper still never writes.

03

Your administrator decides who can ask

Data access configurations are set inside Kipper and control which people can ask and what each of them sees. This layer belongs to you and is independent of the finance system's own role model.

04

Each question is checked, answered and recorded

A question is resolved against the asker's permissions, answered from your synced records, and written to the audit log with the identity of the person who asked.

What reaches a language model

Kipper is an AI product, so this part should be explicit

Two steps involve a language model. Your question is translated into a database query, and the results of that query are phrased into a plain answer. So your question and its results are both processed by a model. Here is exactly what that means.

  • Every model call runs through Amazon Bedrock inside Kipper's own AWS account. Kipper does not call a model provider's API directly.

  • Under AWS's published Bedrock documentation, Bedrock does not store input or output data, does not share it with the model providers whose models it hosts, and does not use it to train models.

  • Your data is never used to train, fine-tune or improve any model. Kipper operates no models of its own.

  • Your financial data is not sold, rented or shared with third parties for their own use, and is not repurposed for advertising, benchmarking or any secondary product.

Data handling

Where it sits and how it is held

The contractual version is in the Data Processing Agreement and the Privacy Policy.

Where does our data live?

On Amazon Web Services infrastructure in the United States by default. Enterprise customers can ask about additional regions by writing to support@kipper.com.

How is it encrypted?

In transit, using standard protocols. At rest, your records sit in an Amazon Aurora PostgreSQL cluster with encryption enabled through AWS KMS, covering database storage, automated backups, snapshots and replicas. An answer delivered through Slack, Microsoft Teams or SMS is additionally subject to that provider's own transport protections, which Kipper does not control.

How are customers kept apart from each other?

Your data is logically isolated, enforced at the database level through row-level security. The check applies to every query regardless of how that query was produced, so one customer's question cannot return another customer's rows.

Why does Kipper keep a copy at all?

Questions run against a synced copy of your records rather than a live call to your finance system, which is what makes an answer fast on a large account. That copy is not your authoritative books and records, which stay where they are.

What happens to it if we leave?

Stored finance data is retained while the account is active. On account closure or disconnection of a finance system, the data for that connection is deleted within a reasonable period, subject to legal, backup and audit retention requirements.

Compliance status

Including the parts that are in progress

A security page earns its trust by showing the work under way as plainly as the work already done. Current as of September 2026.

SOC 2

In progress

A SOC 2 Type II examination is underway with an independent audit firm. The report is not issued yet, so Kipper does not hold SOC 2 certification today, and this page will be updated as soon as that changes.

Penetration testing

In progress

An independent penetration test is part of that same engagement and is scheduled within it. It has not been carried out yet, so there are no results to share, and we would rather say that than imply a test that has already happened.

GDPR and UK GDPR

Addressed

Kipper acts as processor for customer personal data. Roles, processing scope, data subject rights and breach notification are set out in the Data Processing Agreement.

CCPA and CPRA

Addressed

For California privacy law, Kipper acts as a Service Provider and processes personal data solely to perform the Service.

Sub-processors

Published

The current list is maintained publicly and incorporated into the DPA by reference. Customers are notified of material changes.

Breach notification

Committed

Where a breach is reasonably likely to result in risk to rights or freedoms, Kipper notifies affected customers without undue delay and, where required, the relevant supervisory authority within 72 hours of becoming aware.

The current sub-processor list lives on the Sub-processors page so there is only ever one copy to keep accurate. For a signed DPA or a security questionnaire, write to legal@kipper.com.

People and environments

Who can reach what, on both sides

Who at Kipper can reach your data

Only senior, vetted engineers can access the production environment. Staff sign in through Google Workspace with multi-factor authentication enforced, and the credential manager holding production access inherits that enforcement. Anyone authorized to process personal data is bound by confidentiality obligations and works on a need-to-know basis.

How your own people sign in

Multi-factor authentication using an authenticator app is available to every Kipper user and can be enabled by any of them. Enforcing it across a workspace, and SAML single sign-on, are available on Enterprise contracts.

When we help with a bad answer

If an answer is not right, our team may test alternative prompts against that question to improve it. This tunes our prompts and trains no model, because Kipper operates none of its own. Access to that data is least-privilege and limited to the production-authorized engineers above.

The public demo on this website

It runs in a dedicated AWS account deliberately isolated from all customer data. Nothing anyone types into it touches a customer's records, and nothing in it comes from one.

FAQ

Security questions, answered directly

What a reviewer needs before approving the connection.

Kipper connects with read access only and cannot create, edit or delete anything in QuickBooks Online, Xero or NetSuite. Your administrator controls which people can ask questions and what each of them is allowed to see, every question is written to an audit log, and the connection can be revoked at any time, after which the stored copy is deleted.
The figures in a Kipper answer are not produced by a language model. Your question is translated into a database query, that query runs against your own synced records, and the result is exactly what the query returned. A model interprets the question and phrases the reply, so it is never the source of a number and cannot invent a total or recall one from another company's data. Where Kipper cannot answer from your records, it says so rather than estimating.
No. There is no code path in Kipper that writes to a connected finance system. It cannot create records, edit them or delete them. This is a property of how Kipper is built rather than a permission setting, so it cannot be misconfigured.
No. All model processing runs through Amazon Bedrock inside Kipper's own AWS account, and Kipper never calls a model provider's API directly. Under AWS's published Bedrock documentation, Bedrock does not store inputs or outputs, does not share them with the model providers whose models it hosts, and does not use them to train models. Kipper operates no models of its own and does not sell or rent your data.
A SOC 2 Type II examination is in progress with an independent audit firm. The report is not issued yet, so Kipper does not hold SOC 2 certification today. An independent penetration test is part of the same engagement and is also still to be completed. Both will be reflected here as soon as they are.
On Amazon Web Services infrastructure in the United States by default. It is encrypted in transit using standard protocols, and encrypted at rest in an Amazon Aurora PostgreSQL cluster through AWS KMS, covering database storage, automated backups, snapshots and replicas. Enterprise customers can ask about additional regions.
Data is logically isolated and enforced at the database level using row-level security. That check applies to every query no matter how the query was generated, so a question from one customer cannot return another customer's records.
Your administrator sets data access configurations inside Kipper that determine who can ask and what each person can see. This is a separate layer from your finance system's own roles, so giving someone access in Kipper never gives them access to the finance system itself. Permissions are bound to the combination of workspace and email address rather than an email address alone.
Yes. The platform logs access and query activity for security and audit purposes, including who asked, what they asked and when, so financial information use can be reviewed.
Only senior, vetted engineers can reach the production environment where customer data lives. Staff access runs through Google Workspace with multi-factor authentication enforced, and personnel authorized to process personal data are bound by confidentiality obligations and work on a need-to-know basis.
Stored finance data is retained while the account is active. On account closure or disconnection of a finance system, data associated with that connection is deleted within a reasonable period, subject to legal, backup, security and audit retention requirements. Your authoritative books and records are never in Kipper to begin with, so nothing you depend on is affected.
They would see what that one person is permitted to see, and the activity would appear in the audit log. Your finance system stays exactly as it is, because Kipper has no ability to write to it, and records outside that person's permissions stay out of reach, because the check is enforced at the database level.
Yes. The Data Processing Agreement is published at kipper.com/dpa and the current sub-processor list at kipper.com/subprocessors. For a signed DPA or a security questionnaire, write to legal@kipper.com.

Still have a question this page did not answer?

Security questionnaires and signed agreements are answered directly, because those have to state exactly what is in place today rather than what a marketing page can generalize.

Email legal@kipper.com Schedule free onboarding

The documents themselves: Privacy Policy, DPA, Sub-processors, Terms of Service.