Security and trust

Saible runs on Amazon Web Services in two regions: Ohio (us-east-2) for organisations in the United States and Stockholm (eu-north-1) for organisations in the EU. The region is chosen when your organisation is created.

An EU organisation's database, storage, backups, encryption keys, sign-in accounts and e-mail are held in Stockholm, with no copy in another region. There are three exceptions:

• Saible's own AI features use Amazon Bedrock through its EU profile, which may process a request in any of six EU regions. Saible refuses Bedrock's global profiles in every region.
• AWS's own log of activity in Saible's AWS accounts is kept in the United States. It records who called which AWS service, when and from which address; for changes to a person's account, that can include their sign-in name. It holds no prompts, decision records or files.
• An organisation created with a personal e-mail address, such as a Gmail address, is held in Ohio.

The companies that help Saible run the service are listed on the sub-processors page.

The Saible gateway runs in your network, and your prompts go from there to your AI provider. For each request, Saible receives a decision record. It holds facts about the request, such as the application, the model, the policy applied, the outcome, the token counts, the cost, and the type and position of any personal data found. It never holds the text. Saible does not store a record that carries a field outside the record format.

Prompt capture is off by default. If your administrator turns it on, your gateways write the text of requests and responses to your organisation's own S3 bucket, encrypted under your own KMS key. The gateway's role is given permission to write there, not to read, and Saible holds no credential to read the bucket.

The evaluation corpus is also off by default, and you opt in each workload separately. For a workload you opt in, your gateways write pseudonymised copies of the requests and answers to your own bucket, kept for the period you choose (7 to 180 days, 30 by default). Each piece of personal data the detectors find is replaced with a surrogate; anything they miss is kept as sent. While your access grant stands, Saible reads these copies, decrypted, in your region when an evaluation, a review or an access check uses them.

Saible does not train or fine-tune any model on your data. AWS states that Amazon Bedrock does not share requests or answers with the companies that make the models.

Each decision record is linked by its hash to the record before it in the evidence ledger, so a record that is changed or missing is detected when the ledger is verified. Anyone in your organisation can verify the ledger from the console. The evidence ledger is tamper-evident.

Each hour, new ledger records are copied to storage in your region that uses S3 Object Lock in compliance mode. In Ohio and Stockholm these copies are kept for 180 days, and in that time no one, Saible included, can change or delete them. Verification checks the ledger against them. Saible's AWS administrators could still disable the key that encrypts them, which would make them unreadable, not different, and verification would then fail.

Each gateway instance signs every record it writes with its own key.

People in your organisation sign in with a password of at least 12 characters and can enrol an authenticator app. By default, privileged actions ask for an authenticator code, including approving a policy, inviting people, issuing keys, changing provider credentials and exporting evidence. A change to the policy your gateways enforce is approved by a different person from the one who proposed it.

Saible staff see each organisation's gateway health and billing figures to run the service. They read the pages of your console only under a support grant that your administrator approves with an authenticator code. A grant is read-only, with no exports or downloads, lasts 2 hours by default and 4 hours at most, and can be revoked at any time. Each request, approval, first use and end of a grant is a record in your evidence ledger, and the reads under it are counted by console area. Your administrators can see them under Settings › Saible access. Outside a grant, Saible staff can also produce a full export of your organisation's data for handing to you, such as when your access ends. It needs a staff authenticator code and a stated reason, and each one is a record in your evidence ledger and your audit log.

Saible operates the service and holds its encryption keys, and a small number of Saible staff administer the AWS accounts it runs in.

Connections to Saible use TLS 1.2 or 1.3, and browsers are told to use HTTPS only. The database, backups, logs and evidence storage are encrypted with AWS KMS keys created for each region and rotated automatically each year. Application keys and gateway credentials are stored only as hashes and shown once.

• The database and services run in private networks. Only the load balancer accepts connections from the internet.
• Each region connects out from fixed addresses, listed on network addresses to allow. Private connectivity over AWS PrivateLink is available on request.
• A web application firewall limits request rates and sign-in attempts and blocks known malicious traffic.
• Amazon GuardDuty watches for threats. AWS Security Hub checks the accounts against AWS's Foundational Security Best Practices.
• Amazon Inspector continuously scans the container images Saible runs and ships for known vulnerabilities.
• The service's containers run as a non-root user with a read-only file system.
• Dependencies are checked for known vulnerabilities on each pull request that changes them, and all of them are checked again each day. The gateway images are built with a software bill of materials.
• Changes reach the main branch through pull requests that run the automated tests. An administrator can override the required checks.
• The infrastructure that runs the service is defined in Terraform.

The database can be restored to any point in the last 14 days. A separate copy is made each day and kept for 35 days in a backup vault with a governance-mode lock, which Saible's AWS administrators can lift. The network, the database and the console run across two availability zones in each region.

On 8 October 2026 Saible restored a copy of the US production database in about 15 minutes, before any pilot traffic. The Stockholm region has not had a restore drill yet. Backups are not copied to another region, so the loss of a whole region is not covered.

When Saible's service cannot be reached, your gateways keep applying the policy in force, buffer the decision records and deliver them when the service is back; this was measured once on AWS. A gateway instance that loses its disk loses the records it had not yet delivered.

Saible does not yet hold a SOC 2 report or an ISO 27001 certification, and has not yet had an independent penetration test. AWS's certifications cover the infrastructure Saible runs on, not Saible itself. Saible records the evidence of what your AI did; it does not make an organisation compliant.

Write to ops@saible.ai to report a vulnerability or a security concern. The person on call reads that mailbox. Please do not include personal data in the report. How Saible handles personal data is set out in the privacy notice.