Useful enough to do the job. Restricted enough to protect the business.

01How access is decided

Access is designed, not assumed. Before an employee is built, we agree a written scope with you that names every system it may reach and what it may do in each one. Nothing outside that scope is connected.

• Least privilege. We ask for the narrowest access that lets the role work. Read-only where reading is enough. A single folder rather than a whole drive. An agreed set of records rather than a whole CRM.
• Named systems. The scope lists systems explicitly. Adding one is a change we agree with you, not something that happens quietly.
• Draft-only by default. Where an employee works with email, it prepares and does not send.
• Human approval at the boundary. Anything leaving your business waits for one of your people.

02What an employee can never do

• No payment access. We do not connect employees to payment rails, and we will not agree a scope that lets one move money. This holds even for a Finance employee, which reconciles, chases and reports, and never pays.
• No unapproved external sends. Outbound messages are prepared for a person to approve.
• No access outside the agreed scope. Credentials are provisioned per system, per role.
• No decisions with legal effect about individuals without meaningful human involvement.

03Model data handling

We use AI model endpoints configured for zero data retention. Prompts and outputs are not retained by the model provider after the request completes, and they are not used to train the provider's models.

Employees are given the minimum context needed for the task in front of them rather than broad access to everything they could technically read. Where a task can be done without personal data, it is.

Requests are routed through OpenRouter to large language model providers operating under zero-retention terms. The underlying model is chosen for the task and can change. The retention requirement does not: any provider we route to has to meet it. We will name the providers in use on request, and we tell existing customers before anything material changes.

04The website and intake

The site you are reading is a static build served by a small Node service with no runtime dependencies. Its controls are verifiable from the response headers.

The onboarding form

• Rate limited using an irreversible hash of the requesting address, held in memory only. The address itself is never stored or logged.
• Session bound. Submissions must carry a signed, HttpOnly session cookie issued by this site, and must come from this origin.
• Strictly validated. Every field is checked against an allowlist of expected values and lengths before it goes anywhere. Unexpected fields are rejected rather than ignored.
• Deduplicated by fingerprint. A repeated submission is recognised by a one-way fingerprint so that a retry cannot create a duplicate record. The ledger stores fingerprints and identifiers, never the content of what you submitted.
• Fails closed. If the service is not fully configured, intake refuses rather than accepting data it cannot deliver safely.

Booking is only loaded after your submission has been accepted, so the third-party booking script is never present on a page that has not needed it.

05Secrets and configuration

• Secrets are held in the deployment platform's secret store and are never committed to the repository.
• No secret is ever sent to your browser. The public configuration endpoint exposes only approved values: legal links and whether booking is ready.
• An automated scan runs on every build and fails it if a credential pattern or a server-only identifier appears in a client file.
• Delivery to our internal systems uses an authenticated endpoint over HTTPS with a bearer secret, and requests are idempotent.

06Logging and monitoring

Logs are designed so that personal data cannot end up in them by accident. A request log entry contains a request identifier, the method, the path, the status and the duration. It contains no IP address, no browser identifier, no cookie and no submitted field.

We monitor the health of your employees and their connections continuously, and we act on failures rather than waiting for you to notice.

07Incidents

If we become aware of a security incident affecting your data, we will contain it, tell you within 72 hours, explain what happened and what we are doing, and follow up with what we changed so it cannot happen the same way twice.

Where a personal data breach is likely to result in a risk to people's rights and freedoms, we report it to the Information Commissioner's Office within 72 hours of becoming aware of it, as required by UK data protection law.

08Reporting something

If you believe you have found a vulnerability, write to [email protected]. Tell us what you found and how to reproduce it.

We will acknowledge within two working days and keep you updated until it is resolved. We will not pursue legal action against anyone who reports a genuine issue in good faith, avoids privacy violations and service disruption, and gives us reasonable time to fix it before disclosing publicly.

09What we do not claim

Security pages tend to imply more than they mean. To be clear about where we currently stand:

• We do not hold SOC 2, ISO 27001 or equivalent certification. If that is a requirement for you, tell us early rather than late.
• We have not commissioned an independent penetration test. If that matters for your procurement, say so and we will talk about arranging one.
• We do not offer a contractual uptime guarantee, because a meaningful part of the service depends on third-party platforms we do not control.
• AI systems make mistakes. The approval boundaries exist precisely because we do not claim otherwise.

Everything else on this page describes controls that are in place today and can be checked, in most cases from the response headers of this page.