Read-only by default, with everything we do in your own audit log.

One identity, created by you

We connect through a single identity that you create in your own cloud account: an IAM role on AWS, a managed identity on Azure or a service account on GCP. We give you a template with its permissions already written (a CloudFormation stack or Terraform module on AWS, and the equivalent for Azure and GCP); you read it and create the identity from it. It is the same way monitoring and security tools connect to a cloud account. There is nothing to install and no agents (extra software) on your servers.

The template is read-only, and narrower than the read-only policy your cloud provider offers out of the box. It covers telemetry and configuration: metrics, logs, traces, alerts, dashboards, the settings of your services and the health status your cloud provider publishes. It does not read the data your services store, such as the contents of your buckets, databases or secret stores, and it cannot create, change or delete anything. That is enough to investigate every alert. If your security team wants a line changed, we work from their version.

Write access only where a runbook needs it

A runbook is a step-by-step fix for a known issue, and it runs only if you’ve approved it. When you approve one, you add the narrowest permission that runbook needs (for example, restarting one named service) to your identity, using a snippet in our template. We never edit the identity ourselves. There is no standing write access to production.

Anything without an approved runbook goes to your on-call engineer with the evidence. If you want us to act beyond a runbook during an incident, you grant access for a set time, and it is recorded like everything else.

Code repositories, if you choose to share them

Finding the cause of an alert often means reading the stack trace and what changed in the last release. With read access to the repositories you pick, our engineers can point your team to the change that most likely caused it.

Cover works without it. Without code access, our handovers name the release and the evidence, and your engineer reads the code.

• AllowRead the repositories you add us to, through [a GitHub App or a named machine user] you control
• AllowOpen pull requests for reliability work, such as alert rules and instrumentation, for your team to review and merge
• DenyMerge, push to protected branches or change deployment settings
• DenyCopy your source code outside the incident record

[Confirm each rule matches how Tracefox actually works before publishing]

Every action is recorded in your account

Because we work through an identity in your account, what it does appears in your cloud’s own audit log: CloudTrail on AWS, the Activity Log on Azure and Cloud Audit Logs on GCP. You hold those logs, not us, so you can check our work without asking. Every runbook run is also posted in Slack and your ticket.

How the AI is kept in check

Our AI investigates every alert through the same read-only identity our engineers use, so it can read your metrics, logs and settings but cannot change production or read the data your services store. It suggests a likely cause and shows the evidence, an engineer checks it, and a runbook runs only after that, and only one you’ve approved.

Logs can contain text written by anyone who sends your service a request, so we don’t rely on the AI to police itself. The limits are set outside it: a read-only identity, answers that go only to your own Slack channel and ticket, and screening for personal and secret data before anything is posted.

You can also pause every runbook we can run with one action in Slack or the portal until you turn it back on.

Your data

Your contract sets out which data we read, where it is processed, how long anything is kept and what is removed before it is stored. We keep what an incident record needs, such as the timeline and the evidence behind a likely cause, and not bulk copies of your telemetry.

Why we work this way

Three rules sit behind all of this. Give each person or system the least access it needs. Record any exceptional access somewhere the person using it doesn’t control. Let AI earn access to production in stages, starting with read-only.