( Ziiro / Security )
We design around controlled access, data minimisation, secure infrastructure, traceability and clear ownership. This page is about the systems we build for you, not about this website, and it is written in the tense that can be kept: how systems are designed, and what is agreed before work starts.
There are three kinds of security statement, and only one of them is honest here. A certification claim needs an issuing body, and we hold none. A present-tense claim about every running environment needs a fleet nobody can show you. What is left is how systems are designed and what is agreed per engagement, which is checkable when you engage us. 27 statements below are written that way.
9 more are marked Not established, meaning we hold no evidence either way and will not assert one. Nothing on this page is marked Implemented, because that status is reserved for something you could verify today without engaging us, and an architecture is verified inside an engagement rather than on a web page. Nothing carries a tick or a badge.
What an engagement touches decides what it needs. A system reading public marketing copy is not built like one handling health records, and the controls for any particular engagement are written into its contract rather than promised in advance on a web page.
Our clients are engineers, designers, law firms and every other kind of business. A law firm brings privilege, a design studio brings unreleased work, an engineering team brings source code and production credentials. One posture stated for all of them would be wrong for nearly all of them, so this is the shape of the conversation instead.
Marketing copy, public documentation, published content, anything already visible to anyone.
The lightest architecture. Nothing here is confidential, so the design is scoped on usefulness rather than on handling.
Process maps, operational metrics, workflow and cost data, general business records.
Most engagements sit here. Isolation, scoped credentials and logging apply, under the engagement's confidentiality terms.
Client intellectual property, unreleased work, privileged or confidential legal material, source code, production credentials.
Adds redaction before anything reaches a model, tighter tool scoping, and approval gates on actions that leave the system. Agreed in writing before work starts.
Health information, regulated financial records, and other special-category personal data.
A BAA is available for qualifying healthcare engagements, where Ziiro is genuinely acting as a business associate and every downstream subprocessor touching the data is itself contracted and configured for it. Work runs only under a configuration agreed before any data moves. We hold no certification or audit for this category and will not imply one.
These are not certified tiers and they are not published control checklists. They describe how the scope of an engagement is decided. The controls that actually apply to your work are written into that engagement's contract, which is the only place a commitment of this kind means anything.
The shape of every system we build. Data is minimised and redacted before it goes anywhere, the action is checked against what the agent is scoped to do, and only then does anything reach a model. What comes back is validated by ordinary code, and by a person where the action is irreversible or externally visible.
The point of drawing it this way is that the model sits in the middle of the path rather than at the end of it. It is one component, and the only stage that leaves your boundary. Permission, context, validation, logging and human control are supplied by the system around it.
This is how systems are designed. It is not a picture of a certified running deployment, and no box in it has been audited by anyone outside Ziiro. What your engagement actually does is written into your engagement.
[ 10 sections / 52 statements ]
The frame for everything below. These are statements about how we build, not about a fleet already running somewhere.
The architecture applied when we design, build and operate a system for a client: who can reach data, how it is isolated, how it moves through models, what an agent may do, and what is agreed before any of it starts.
Systems are designed so that every component, human and agent alike, receives the narrowest permission its task requires. Access is granted to a specific job rather than to a system, and widened deliberately rather than by default.
A system is designed to hold and move the least data that makes it work. Where a field is not needed for the outcome, the design leaves it where it is rather than copying it.
Systems are designed so that a consequential action can be reconstructed afterwards: what was requested, what context was used, what the model returned, what was validated, and what was written back.
What you keep, what is returned and what is destroyed when an engagement ends is written into the contract before it begins, rather than discovered at the end of it.
The centre of this page, because it is where the risk that is specific to this kind of work actually lives.
Production work uses a named set of model providers agreed for that engagement. A model is not swapped in because it is cheaper or newer without that agreement, and a provider outside the set does not receive client data.
A model receives the portion of data the task needs, not a whole dataset for convenience. Retrieval is scoped to the question rather than pointed at everything the client has.
Sensitive fields are redacted or replaced with tokens before a prompt leaves the system, so identifiers that the task does not need are never submitted. Where a value must round-trip, the mapping stays inside the client's boundary.
Stated per provider, because providers genuinely differ and a single blanket sentence would be wrong for some of them. The position for each provider in scope is written down for the engagement before data moves, rather than assumed from a marketing page.
One client's prompts, files and vector indexes are designed to be logically separated from another's. There is no global semantic search spanning clients, because an index that can answer across tenants is a breach waiting for the right question.
Retrieved content and third-party documents are treated as hostile input rather than as instructions. System instruction, client instruction, retrieved content and tool permission are kept separate, so text that arrives inside a document cannot inherit the authority of the system that read it.
Permission, context, validation, logging, business rules and human control live in the system around the model, not in the prompt. A model is replaceable; that surrounding structure is what actually makes the system safe to run.
What an agent is allowed to do on its own, and where a person stays in the path.
Each tool an agent can call is granted separately. An agent that reads email does not thereby gain permission to send it, and one that reads a record does not gain permission to delete it.
Actions that are irreversible, externally visible or financially material are designed to stop at a person. Which actions those are is decided with you rather than assumed.
Model output is checked by ordinary code against the rules of the destination before it is written into a business-critical system. A value that fails validation does not get written and does not get retried silently.
An agent is designed to use a credential scoped to its task rather than a shared account or a human's login, so what it did is distinguishable from what a person did.
How much an agent does unattended is a decision for the engagement, written down, and revisited as confidence is earned rather than set once at the start.
How one client's data is kept away from another's, and from us.
Each engagement's data, credentials and indexes are designed to sit in their own boundary. Nothing is designed to require that two clients' data share a store to work.
Whether a system runs inside your infrastructure, in an environment we operate for you, or in a mix of the two is decided per engagement and affects nearly everything else on this page.
Who on our side can reach what, for how long, and under what logging, is agreed in the contract. The design position is that access is scoped to the work and removed when the work ends.
We do not design systems that learn from one client's data to serve another, and we do not pool client data for our own model training or benchmarking.
The credentials an engagement needs, and how they are designed to be handled.
Integrations are designed to use purpose-scoped credentials, so access can be attributed and revoked without disturbing anyone else's.
Access granted for a piece of work is designed to be removable at the end of it, and the handover includes what to revoke.
We hold no evidence we can publish of what is enforced internally, so we make no claim. Ask, and we will answer directly.
Whether internal access is reviewed on a schedule and revoked on departure is not something we can currently evidence.
Stated as design practice. We will not tell you what every environment does, because we cannot evidence a fleet.
Systems are designed so that data moves over encrypted transport between every component, including to model providers and between an agent and the tools it calls.
Where a system must persist client data, it is designed to use the platform's encryption at rest and to keep the smallest amount for the shortest time the task allows.
Credentials are designed to live in a managed secret store rather than in code, configuration files or prompts, and to be rotatable without a rebuild.
How long anything is kept, and how deletion is requested and confirmed, is agreed per engagement. A system with no agreed retention period is a system nobody can honestly answer questions about.
We will not make a present-tense claim about every environment that exists. What a specific engagement does is written into that engagement and is checkable there.
What changes when the data is regulated, and the conditions that have to be true before such work starts.
A regulated engagement is designed around a risk analysis for that workload, a named person responsible for it, explicit authorisation of who may work on it, and an agreed procedure for incidents.
Access control, authentication, audit controls, integrity checking and transmission security are designed into the system rather than added to it, and each is specified for the workload rather than assumed.
The facility controls sit with the cloud provider under its own terms. The controls we are responsible for are the ones covering our own devices and how work happens on them, and they are specified in the engagement.
A regulated workload runs only under a configuration agreed in advance and with the necessary agreements in place. Every downstream service that could touch the data must itself be contracted and configured for it, which rules out sending regulated data to any service not approved for that purpose.
A BAA is available for qualifying healthcare engagements. Where protected health information is created, received, maintained or transmitted on behalf of a covered entity, a written business associate arrangement is what the rules require, and we will sign one. The conditions below are part of the offer rather than caveats on it: a BAA signed over a stack that cannot honour it would be worth nothing to you.
Conditions
There is no such thing as a generic HIPAA certification, so nobody holds one and we will not imply we do. What is real is whether the safeguards above are specified, agreed and operated for your workload, which is a question about your engagement rather than about a badge.
What a system records, and what is agreed to happen when something goes wrong.
Systems are designed to record the decisions that matter: what an agent was asked, what context it was given, what it returned, what validation did, and what was written back. Logs are designed to avoid carrying the sensitive payload itself where the record of the action is enough.
Log retention, access and export are part of the engagement rather than a default we impose.
What counts as an incident, who is told, in what time, and through which channel is agreed in the contract. That is the only place a notification commitment means anything.
We have no written, exercised runbook of our own to show you. Stating it plainly is more useful to you than a paragraph implying one exists.
What is monitored and who receives an alert is not something we can evidence as a standing capability.
What happens when something breaks, and what happens when the engagement ends.
Systems are designed to fail closed on the path that touches data: when a check cannot complete, the action does not proceed. A degraded model or an unreachable tool stops the work rather than guessing at it.
Whether a system needs backups, how often, and how quickly it must come back are set for the workload. A system that holds nothing of its own needs a different answer from one that becomes a system of record.
We hold no evidence of tested restores as a standing practice, so we make no claim to one.
A system is designed to be handed over: documented, with its access transferable and its data exportable, so that ending the engagement does not mean losing the work.
Certifications, audits, and where a real commitment actually lives.
No examination has been undertaken and no report exists.
Not certified, and no certification process is underway.
None has been carried out. Nothing on this page has been checked by a third party, and it should be read as self-reported.
Used as benchmarks to check designs against, particularly for AI-specific failure modes. Neither is a certification, neither certifies anyone, and we claim no conformance to either.
In the engagement contract. Everything on this page describes how we design; the contract is what obliges us, and it is the document to negotiate against rather than this one.
Send it to the address below and we will answer question by question. Where the answer is that something is not in place, it will say so rather than leave a blank, which is faster for you than a document corrected later.
A role-based address for security correspondence does not exist yet, so this page deliberately does not print one. An address that bounces is worse than no address at all, so the published contact address is used everywhere instead.
Email the address below with what you need and the deadline you are working to. We will answer question by question, and where the answer is that something is not in place we will say so rather than leaving a blank. That is faster for you than a document that has to be corrected later.
contact@ziiroai.comPrivate vulnerability reporting is enabled on our repository, and the published security policy sets out what is in scope and what to expect. The address above also reaches a person directly.
Please do not test against live systems in ways that could affect availability or reach anyone else's data.
[ Last reviewed 2026-09-21 ]
The architecture statements below, re-read against what is actually designed and what is only aspired to. This date moves when a person re-checks those things, not when the site is rebuilt, so it means something specific. If it has aged past your comfort, ask and we will re-verify rather than tell you it is still current.
Evaluating us for work that touches sensitive data? Start with a conversation and bring the questions this page did not answer.