Security and method

What we do is not possible without trust.

We operate inside your systems, with your data, on behalf of your clients. Our security protocol is non-negotiable and documented before every engagement.

Our commitment

Written authorisation first

We do not start working on any system without a signed access scope. This document names the authorised systems, the accounts used, the roles assigned and the absolute limits. It is reviewed at every scope extension.

Least privilege — minimum required access

Each agent only has access to the resources strictly necessary for its task. An email-reading agent has no access to the CRM. A CRM-updating agent has no access to emails. Permissions are documented and auditable.

Mandatory dry-run before any mutation

Before executing any action that modifies data, the agent runs in simulation mode. You see exactly what would be done, without anything actually happening. Production only starts after your explicit validation.

Audit logs reviewable by the client

Every action executed — read, write, send, rejection — is recorded with a timestamp, the identity of the agent, the result and the data concerned. These logs belong to you and stay within your infrastructure.

Rollback plan defined in advance

Before any go-live, we define a rollback plan with you: what happens if the automation produces an unexpected result? Who is notified? How do we return to the previous state? This plan is tested before the start.

Example of an audit log

Every action is timestamped, identified by agent, and shows the status. The "pending" entries are awaiting human approval.

Timestamp (UTC)	Agent	Action	Status
2026-05-19T08:14:33Z	lead-qualifier	READ email:inbox#1821	ok
2026-05-19T08:14:35Z	lead-qualifier	WRITE crm:contact#NEW pending approval	pending
2026-05-19T08:15:01Z	lead-qualifier	WRITE crm:contact#4482 — approved by M.D.	ok
2026-05-19T08:22:47Z	email-triage	WRITE drafts:reply#928 — awaiting approval	pending

What we never do

Accessing a system without written authorisation

Storing credentials in plain text (code, notes, prompts, screenshots, commits)

Bypassing authentication, CAPTCHAs, access controls

Executing in production without a validated prior dry-run

Logging sensitive data unnecessarily

Copying client data to third parties without a signed agreement

Data and residency

Your data stays in your systems. We maintain no central database and export nothing without a signed agreement.

No client data is copied to third-party services without explicit, written agreement.
Credentials are stored via an approved secrets manager — never in plain text in code, notes or prompts.
Sensitive data (personal, financial) is not logged unless there is an explicitly validated functional need.
Data stays in your systems. We do not operate a central database on the agency side.

Models used and residency

We choose the model according to the sensitivity of the data processed — not by a uniform rule.

For personal data of tenants and owners: LLMs hosted in Switzerland or the EU, or locally depending on the contracted scope.
No client data is used to train models, under any circumstances.
The exact routing, the providers used and the processing zones are documented and signed before any start.
If your case requires strict Swiss residency, we operate via compatible models (Apertus or Exoscale-class hosting).

Exit and portability

No black box. No proprietary format. If you decide to stop, you leave with everything you need to continue without us.

Functional specification, flow diagrams, prompts and code delivered in plain form.
All artefacts belong to you by contract from delivery.
An internal IT team or another provider can take over the workflows from the documentation provided.
The scope of access to systems is revocable at any time, without penalty.

Questions about our protocol?

Let's talk it through directly. No preparation required on your side.