Security
How We Handle Your Systems and Your Data
An AI system that can act on your behalf is a system with real access. This page states plainly what that access looks like, how it is limited, and what we do not do.
What security means for an AI system that takes action
A system that only answers questions carries the risk of being wrong. A system that issues refunds, changes addresses or writes to your CRM carries the risk of being wrong and acting on it. Everything below exists because of that second category. The controls are engineering decisions made per engagement, not a certificate on a wall.
Access
What the system can reach — and what it cannot
Access is the control that matters most, because it bounds every other risk.
Least privilege by default
Each integration gets the narrowest scope that makes the workflow function. A support system that reads order state does not get write access to pricing.
Credentials you own
API keys and service accounts are created in your tenancy, in your name. You can revoke any of them without contacting us, and nothing we build depends on us holding them.
Scoped service accounts
We do not use a person's login to run a system. Each automation authenticates as itself, so its actions are attributable and its access can be withdrawn on its own.
Secrets never in code
Credentials live in environment configuration or a managed secret store, never in the repository, never in a ticket, never in an email.
Separate environments
Development and staging run against test data or a masked copy. Production credentials are not available to a development environment.
Revocation is a first-class step
Every engagement documents how to switch the system off and withdraw its access. Knowing how to stop something is part of deploying it.
AI guardrails
Where the model is allowed to decide, and where it is not
The failure people imagine is an AI inventing an answer. The failure that actually costs money is an AI taking a confident action on a wrong premise. These are the constraints that separate the two.
- Grounded answers only. The model answers from retrieved content and live system data, not from what it recalls. Below the confidence threshold it escalates rather than producing something plausible.
- Actions are tools, not text. Refunds, address changes and record updates are explicit API calls with their own validation — not something the model can talk its way into.
- Policy evaluated before action. Your rules decide what the system may do for a given case: answer only, act, request approval, or hand to a person.
- Thresholds you set. Refund ceilings, approval limits and escalation triggers are configuration, visible and changeable by you, not constants buried in a prompt.
- No silent retries on side effects. An action that may have partially succeeded goes to a person rather than being attempted again.
Data
What happens to the data the system touches
Encryption in transit and at rest
All traffic runs over TLS. Data at rest sits on encrypted storage. This is table stakes rather than a differentiator, which is why it is one line.
Minimisation
A workflow is given the fields it needs to complete. A returns agent does not need a full customer profile to check eligibility, so it does not receive one.
PII handling
Personal data is redacted from logs and traces wherever the workflow does not require it. Where an identifier must be logged for auditability, it is the reference, not the full record.
Retention you choose
Transcripts, traces and intermediate artefacts have a retention period set per engagement. Where a shorter window is a compliance requirement for you, it becomes the requirement for us.
Isolation between clients
No shared indexes, no shared vector stores, no pooled context. One client's content is never retrievable in another client's system.
Deletion means deletion
When an engagement ends, we document what is removed and confirm it. Credentials are yours to revoke, and the data lives in your systems.
Model providers
Where the model runs, and what it is allowed to remember
Which provider a system uses is an engineering choice with security consequences, so it is made openly with you rather than assumed.
- Business-tier APIs by default. We use provider endpoints whose terms exclude your content from training. Where you require it in writing, we confirm the specific commitment before the system handles real data.
- Regional processing where it matters. If your obligations require processing inside a region, that constrains provider and deployment choice, and we say so before the architecture is fixed rather than after.
- Self-hosted and open-weight options. For workloads that cannot leave your infrastructure, an open-weight model deployed in your environment is a legitimate answer. It usually costs more and performs less well, and we will tell you when that trade is worth making and when it is not.
- Provider substitution is designed in. The model sits behind an interface. Changing provider is a configuration change and a re-evaluation, not a rebuild.
Auditability
Every action leaves a record
If you cannot reconstruct why a system did something, you cannot govern it. Each automated action is logged with the case it belongs to, the inputs it read, the policy branch it took and the result.
That record is what makes an incident investigable, a dispute answerable and a threshold tunable. It is also what makes it possible to prove the system did not do something.
When something goes wrong
Incident handling
Systems fail. What matters is whether the failure is contained, noticed and explained.
Containment first
Every workflow has a kill switch that stops automated action while leaving the human path open. Turning a system off never takes your customers offline with it.
Notification
If an incident affects your data or your customers, you hear it from us, with what we know and what we do not yet know. We would rather tell you early and be incomplete.
Root cause, written down
What happened, why the controls did not prevent it, and what changed as a result. Delivered as a document, not a phone call you have to take notes on.
Your escalation path
Named contacts and response expectations are agreed at the start of an engagement, so nobody is looking for a phone number during an incident.
Stated plainly
What we do not claim
We hold no SOC 2 report and no ISO 27001 certificate. Saying otherwise would be the easiest sentence on this page to write and the fastest to be caught out.
If your procurement process requires a certified supplier, we are not that supplier today, and you should know it before a discovery call rather than after. What we can do is work inside the controls your certified environment already imposes — your cloud, your identity provider, your logging, your retention — and document our part of it in a form your auditor can read.
If certification becomes a requirement for the business we want, we will pursue it and say so here on the day it is real.
Send us the security question that worries you most
Whether an AI system can be trusted with your systems is a fair question, and a specific one. Ask the specific version and we will answer it directly.