Security and trust

Principles

• Read-only by default.

  Investigation uses read-only tools. A new workspace cannot change anything until you turn actions on.

• A person approves changes.

  You choose how far adoe may go. In approve mode, every action waits for a person.

• Verified before resolved.

  Adoe resolves an incident only after it checks the alert's own signal. If it cannot verify, it escalates.

• Every step on the record.

  Investigations, decisions, approvals and actions are saved on the incident.

Safety controls

These controls decide whether adoe may act, what it may do, and when it must stop.

Workspace execution setting

Each workspace has one setting that limits what adoe may do. Every workspace starts at off.

Today our team changes this setting for you, on request. TODO(owner): self-serve setting for admins?

Limits on actions

• Adoe's own actions can never delete, terminate, destroy or drop resources. Any action it does not recognise is blocked too.
• Actions that can add cost, such as starting or scaling resources, always need approval.
• Runbooks run with a time limit per step. The default is 5 minutes.
• Scripts may only start with approved commands. Chained commands, background jobs, redirects and command substitution are rejected.

Confidence and verification

• Below a confidence of 0.8, adoe escalates instead of recommending. An SOP sets its own, usually higher, bar for running without a person.
• Adoe never runs a fix it cannot verify. If an SOP's check needs a metric source that is not connected, adoe recommends instead of running.
• After a runbook runs, adoe checks the alert's own signal. A metric check reads only the series for the alert's own host or service.
• If there is no data, the data is ambiguous, or the check does not pass in time, adoe escalates. It does not resolve.

Time limits and stop switches

• Approval requests for adoe's own actions expire after 15 minutes. A recommendation that nobody acts on escalates after 24 hours.
• When adoe retries a fix on its own, it stops after two attempts and calls a person.
• Our team can turn off all actions, or all AI processing, for the whole service or for one workspace, at once.
• The dashboard shows a preview of every run and offers a dry run first.

Access and identity

• Single sign-on. SAML 2.0 and OpenID Connect, with any standard identity provider such as Okta, Microsoft Entra ID or Google Workspace. Admins can require SSO, which turns off password login.
• User provisioning. SCIM 2.0 for users and groups. With SSO, groups from your identity provider can map to adoe roles.
• Roles. Admin, editor and viewer, per workspace. Viewers can see incidents. Editors can also run and change SOPs. Admins also manage members and single sign-on.
• Passwords. Stored as bcrypt hashes. Login attempts are limited to 10 per minute per address. Sessions expire after 24 hours.
• Two-factor login. Adoe does not have its own two-factor login yet. Use SSO to enforce it through your identity provider.

Data handling

What adoe stores

Alerts and their details, incidents, investigations, decisions, approvals and actions. Also your integration settings, SOPs, and usage records for AI processing.

Encryption

• All traffic to adoe uses HTTPS.
• Integration credentials are encrypted at rest with Fernet (AES-128 with an HMAC-SHA256 check). After you save a credential, adoe shows it only in masked form.
• The service will not start in production without an encryption key and a non-default signing key.
• Database encryption at rest: TODO(owner): confirm Fly.io volume encryption and state it

Separation between customers

Every record belongs to one workspace. Your alerts, incidents, investigations and credentials are scoped to your workspace, and adoe matches your alerts only to your own SOPs.

Retention and deletion

Adoe keeps your data until you delete your workspace or ask us to delete it. TODO(owner): retention policy and deletion timeline

Subprocessors

TODO(owner): confirm the full subprocessor list and locations

AI processing

Adoe uses Claude models from Anthropic. To investigate an incident, it sends the model:

• the alert and its details,
• recent deploys,
• the alert's definition from your repository, and the live check definition,
• the log events and metric values it reads,
• Slack messages in an alert thread, when someone mentions adoe there.

Adoe does not remove personal data from this content before sending it. Keep secrets and personal data out of alert payloads.

Anthropic does not use API data to train its models by default. TODO(owner): confirm contract terms (data processing agreement, zero data retention)

Our team can turn off AI processing for your workspace at any time.

Connections to your tools

• Alerts in. Each workspace gets private webhook addresses that contain a secret token. PagerDuty signatures are checked when you set a signing secret. Requests over 2 MB are rejected, and each source has a rate limit.
• Slack. Adoe checks Slack requests with your Slack app's signing secret. Set it during Slack setup.
• AWS. Adoe uses a role in your own account. You choose its permissions, and you can require an external ID. Read access is enough for investigation.
• Least access. Investigation needs only read access to your monitoring and code tools. Write access is needed only for the runbooks you choose to run.

Audit trail

• Each incident keeps its record: the alerts, the investigation steps, every decision with its reasoning, approvals with the approver, and every action with its result.
• The audit log records single sign-on and SCIM provisioning events.
• Start, stop and reboot actions on AWS instances have their own log.

Hosting

Adoe is a hosted service. The application and database run on Fly.io in London, UK. The website runs on Cloudflare. TODO(owner): confirm region statement and any availability commitment

Engineering practices

• Dependencies are checked for known vulnerabilities on every change and every week.
• Automated tests run on every pull request.
• Adoe proposes new SOPs and alert-tuning changes as pull requests, for your team to review.

Compliance status

Adoe does not have a SOC 2 or ISO 27001 report yet. TODO(owner): planned audit and target date, if any

We answer security questionnaires during evaluation. TODO(owner): confirm this offer

Not available yet

Security reviews ask about these, so we list them plainly.

• Two-factor login without SSO.

  Use your identity provider through SSO.

• SOC 2 or ISO 27001 report.

  See compliance status above.

• Self-hosted or private-cloud deployment.

  Adoe runs as a hosted service only.

• Your own AI model key, or a model in your own cloud account.

  Adoe uses its own Anthropic account.

• Automatic rollback.

  When a fix does not verify, adoe escalates to a person instead.

• Audit log for setting changes.

  Changes to settings, SOPs and integrations are not yet in the audit log.

• Automatic data retention limits.

  See retention and deletion above.

Contact

Ask a security question, or request a call with an engineer, through the contact form. To report a vulnerability, email [email protected]. TODO(owner): dedicated security address and security.txt