SaaS provider integrations

These integrations run from the GitGuardian platform: no ggscout to deploy. You create a read-only credential in the provider, then paste it in Settings > Sources. GitGuardian polls the provider's API to inventory users, service accounts, API keys, and the permissions attached to them.

GitGuardian only calls read endpoints and never receives secret values. Provider admin APIs return key metadata (name, owner, creation date, last use, scopes), not the keys themselves. Some providers (Anthropic, Snowflake) have no read-only credential that covers the whole inventory; each section says so when it applies.

Add an integration

1. In GitGuardian, go to Settings > Sources and pick the provider. You need the Manager role.
2. Fill in the Name and the provider fields listed below.
3. Optionally set an Environment and an Owner email. They tag every identity collected from this source.

Create a dedicated credential for GitGuardian rather than reusing one that serves other tools. It keeps the audit trail clean and lets you revoke it without side effects.

Identity providers

Auth0

Create a Machine to Machine application in the Auth0 Dashboard (Applications > Applications > Create Application) and authorize it for the Auth0 Management API with these read-only scopes:

read:users, read:clients, read:client_grants, read:grants, read:resource_servers, read:roles, read:organizations, read:organization_members, read:connections, read:actions, read:device_credentials, read:signing_keys, read:rules, read:log_streams, read:custom_domains, read:email_provider, read:tenant_settings, read:attack_protection, read:prompts

Missing scopes do not block the collection: the corresponding objects are skipped.

Fields: Domain (your-tenant.auth0.com or your custom domain), Client ID, Client secret.

Collected: users and their roles, applications and their credentials, client grants, APIs and scopes, roles and permissions, organizations and members, connections, actions, and tenant security settings.

Okta

Create an API token in the Okta Admin Console (Security > API > Tokens > Create token). An Okta API token inherits the permissions of the administrator who creates it, so create it from a dedicated service account with the Read-Only Administrator role. That role reads users, groups, applications, authorization servers, and admin role assignments. If API token metadata is missing from the inventory, the creating administrator lacks the permission to view API tokens: a Super Administrator token covers every object.

remarque

Okta expires API tokens unused for 30 days. GitGuardian polls regularly, so the token stays active as long as the integration is enabled.

Fields: Okta domain (your-org.okta.com), API token.

Collected: users, groups and memberships, applications and their OAuth clients, OAuth grants, authorization servers with their scopes and policies, API tokens, and admin role assignments.

SaaS providers

Airbyte

In Airbyte Cloud, go to Settings > Applications and create an application. An application inherits the permissions of the user who creates it, so create it as an Organization Admin: that is the role that can list users and permissions across the organization.

Fields: Client ID, Client secret.

Collected: organizations, workspaces, users and their permissions, applications, sources, destinations, and connections. Connector credentials are inventoried as metadata only; Airbyte masks their values.

Anthropic

Create an Admin API key in the Claude Console (Settings > Admin keys). Only organization members with the Admin role (or Owner, Primary Owner) can create one. Admin keys start with sk-ant-admin and carry organization administration rights with no read-only option, so store it like any admin credential: GitGuardian only uses it to list resources.

The Admin API is unavailable for individual accounts; your organization must be set up in the Console.

Fields: Admin API key, Organization ID (Settings > Organization).

Collected: organization members and their roles, workspaces and their members, API keys (name, owner, workspace, creation date, last use), and 30 and 90 day usage per key, which feeds the active, dormant, inactive, and never used statuses.

Datadog

You need an API key and an application key from the same organization (Organization Settings > API Keys and Application Keys). An application key carries the permissions of the user or service account that owns it. Create a service account with a custom role holding these permissions, then create its application key and scope it to the same list:

• user_access_read: users, roles, and role permissions
• teams_read: teams and memberships
• api_keys_read: API keys
• org_app_keys_read: application keys owned by any user
• org_management (optional): organization details

The Datadog Read Only Role does not include api_keys_read or org_app_keys_read; without them API and application keys are missing from the inventory.

Fields: API key, App key, Site (datadoghq.com by default; use datadoghq.eu, us3.datadoghq.com, us5.datadoghq.com, ap1.datadoghq.com, or ddog-gov.com to match your region).

Collected: users and service accounts, teams, roles and their permissions, API keys, and application keys with their scopes.

n8n

Create an API key in n8n (Settings > n8n API > Create an API key) as the instance owner: the users endpoint is restricted to owners. If your plan supports scoped API keys, grant user:list, workflow:list, and variable:list.

Fields: Base URL (https://n8n.example.com or your cloud instance URL), API token.

Collected: users and their roles, workflows and the credentials they reference, and variables.

OpenAI

Create an Admin API key in the OpenAI platform (Settings > Organization > Admin keys). Only organization owners can create one. Choose Restricted permissions and set:

• Organization Administration: Read (api.management.read)
• Usage: Read (api.usage.read), for the usage statistics behind the key activity statuses

Select the permissions when you create the key. A key created without them, then edited, can keep failing with Missing scopes: api.management.read; delete it and create a new one.

Fields: Admin API key (sk-admin-...), Organization ID (org-..., from Settings > Organization > General).

Collected: users and their roles, projects and their members, service accounts, API keys (name, owner, project, creation date, last use), and 30 and 90 day usage per key.

Slack

Create a Slack app at api.slack.com/apps, add the bot token scopes below under OAuth & Permissions, install it to the workspace, and copy the Bot User OAuth Token (xoxb-...):

users:read, users:read.email, usergroups:read, team:read, channels:read, groups:read

Installed apps and their scopes come from an admin endpoint available on Enterprise Grid only. To inventory them, provide a User OAuth Token (xoxp-...) from an org Owner or Admin instead, with the same scopes as user scopes plus admin.apps:read. Without it, GitGuardian skips installed apps.

Fields: Workspace ID (T..., the segment after /client/ in the browser URL of your workspace), OAuth token.

Collected: users with their admin status and 2FA state, user groups and memberships, bots and the apps they belong to, public and private channel names, and installed apps with their scopes on Enterprise Grid.

Snowflake

GitGuardian authenticates with key-pair authentication: you generate an RSA key pair, attach the public key to a Snowflake user, and paste the private key in GitGuardian.

1. Generate the key pair:

   openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake_key.p8 -nocrypt
   openssl rsa -in snowflake_key.p8 -pubout -out snowflake_key.pub

2. Create a dedicated user and role, and attach the public key (the base64 body of snowflake_key.pub, without the BEGIN and END lines):

   CREATE ROLE gitguardian_reader;
   GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE gitguardian_reader;
   GRANT MANAGE GRANTS ON ACCOUNT TO ROLE gitguardian_reader;
   
   CREATE USER gitguardian_service TYPE = SERVICE DEFAULT_ROLE = gitguardian_reader;
   GRANT ROLE gitguardian_reader TO USER gitguardian_service;
   ALTER USER gitguardian_service SET RSA_PUBLIC_KEY = 'MIIBIjANBgkqh...';

   IMPORTED PRIVILEGES on the SNOWFLAKE database gives read access to ACCOUNT_USAGE (login, access, query, and session history). MANAGE GRANTS lets the role list every user, role, and grant: SHOW commands only return objects the role has privileges on, so a narrower role produces a partial inventory.

   attention

   MANAGE GRANTS is not read-only: it also lets the role grant and revoke privileges on any object in the account, and Snowflake offers no read-only equivalent for a complete user and grant listing. Protect the private key like an administrator credential. If that is not acceptable, drop the MANAGE GRANTS line: the inventory then covers only the objects gitguardian_reader has privileges on.

3. Find your account identifier: SELECT CURRENT_ORGANIZATION_NAME() || '-' || CURRENT_ACCOUNT_NAME();

Fields: Account identifier (MYORG-MYACCOUNT), Username, Private key (full PEM content), Private key password (only if you encrypted the key).

Collected: users and their authentication methods, roles and hierarchy, grants, databases, schemas, warehouses, secrets and integrations (metadata), stages, network, masking, row access, and password policies, and recent login and access history.

Troubleshooting

• Nothing collected after creation: GitGuardian checks the credential on the first collection, not when you save the form. Verify the key, and that the organization ID, Datadog site, or Snowflake account identifier matches the one the key belongs to.
• Integration marked stale: no collection succeeded recently. The credential was revoked, expired, or lost a permission. Recreate it with the permissions above and update the integration.
• Objects missing from the inventory: the credential lacks the permission for that object type. Most integrations skip what they cannot read instead of failing, so compare your scopes with the list above.