User management#

Antithesis considers the basic unit of isolation to be a tenant. Each tenant receives their own instance of our entire cloud infrastructure, and their data cannot be read by other tenants, even when acting maliciously. In general, each customer gets a single tenant. It is possible, however, to configure multiple tenants for a single customer. This might be necessary if (for example) a customer has two teams, one of whom works on highly sensitive information.

There are three major actions in Antithesis which require authorization. These are:

  1. Pushing images to the Antithesis registry

  2. Kicking off tests

  3. Viewing reports

The first two authorization scopes are managed differently from the third one, because these two actions should be launched by an automatic process such as a CI server. Consequently, we provide machine credentials for these actions which can be used by your CI process.

Machine Credentials#

Credentials for your CI system are generated by Antithesis and sent to you securely when you sign up. These credentials are used to push images and to run tests. Because these are long-lived credentials, after your initial setup period, you should not use them in manual or interactive processes. If these credentials are compromised, it is straightforward for Antithesis to rotate them and issue you new credentials.

The following credentials are generated for each Antithesis tenant:


Container image registry credentials. A JSON file for pushing images to the Antithesis image registry created for your tenant.

user and password

Webhook credentials. Used to kick off Antithesis tests.

If you want us to post results back to your CI service, as in the Antithesis Github Action, you may need to create additional credentials or tokens.

Report Access#

Antithesis reports can be accessed only via a signed URL. This URL is impossible for an attacker to reverse-engineer, even with knowledge of the report ID and the encryption scheme. If the contents of your Antithesis reports are sensitive, take care not to post these report URLs in public. Report signing keys can be rotated, however doing so is a destructive operation that will invalidate all previously-generated reports, not just the one that was accidentally leaked.

For customers concerned about report access, Antithesis supports integration with Identity Providers (IdPs) to further restrict access to reports. If this integration is enabled, all access to reports will require a login through your IdP in addition to a signed URL.

This integration is available for any IdP that implements the OIDC protocol. Identity Providers who implement the OIDC protocol include:

Please consult your IdP’s documentation for more information on their OIDC support.

OIDC Integration#

The following steps are a general guide to OIDC integration. The exact flow will be IdP specific – consult their documentation for details.

  1. Antithesis provides you a login redirect. It will be something like:


  2. In your Identity Provider, create a new project or application.

  3. Under this project/application, generate new credentials.

  4. You will choose or generate a new client ID and secret. Provide these to Antithesis.

  5. Add the redirect URL from (1) to the new credentials from (3).

Advanced Features#

Antithesis’s IdP integration supports Custom Claims. When configured in your IdP, these claims can restrict report access to specific members of your organization. See the documentation provided by your IdP, such as the Auth0 custom claims documentation, for more information.