Safeguard Docs
Compliance Connectors

Compliance connectors

Connect the systems you run so Safeguard can collect compliance evidence from them, and keep those connections healthy.

Compliance connectors

A compliance connector links Safeguard to a system you run, such as your identity provider, cloud account, code host or ticket tracker. Safeguard reads from it with read-only access and turns what it reads into evidence for your controls.

Where to connect

Open Compliance › Connectors. Search for the system, or filter by category, by Automated evidence or Connection record only, and by Connected or Not connected. Click Connect on a card to open its connect form.

Admins decide which connectors members of the organization can use, under Settings › Connector access or with Manage connectors on the Connectors page. A connector that is switched off there does not appear for members, and the server refuses to connect it.

Can't find a system? Use Request integration on the Connectors page.

Three ways to connect

The connect form offers up to three methods. Which ones appear depends on the connector.

MethodHow it worksUse it for
OAuthYou approve read access on the vendor's own consent screen. There is no secret to copy, and you can revoke access at the vendor at any time. Offered where Safeguard has an OAuth app for that vendor.Evidence collection and automated compliance tests, unless the connect form says the tests need the API token method
API tokenYou paste an API token or key, plus any account details the form asks for. The form lists the read-only grant to create at the vendor and links to the vendor's documentation. Always available.Evidence collection and automated compliance tests
MCP serverYou connect the vendor's Model Context Protocol server by URL. This is the method Search (Griffin AI) uses, because Search works by calling a connector's tools.Asking Griffin AI about the system

Some vendors' OAuth sign-in connects their MCP server rather than their API. Those connections serve Search but cannot feed the compliance tests; the guide for such a connector tells you to use the API token method instead.

What happens to your credential

  • Credentials are encrypted at rest with authenticated encryption. Safeguard never shows a saved secret again: the card only says that a credential is stored.
  • Every guide asks for the narrowest read-only grant the vendor offers. A few vendors have no read-only option; their guide and connect form say so. Safeguard only makes read calls with the credential either way.
  • A self-hosted server (for example your own GitLab, SigNoz, StackRox or Logto) must be reachable at a public https:// address. Safeguard refuses private, loopback and cloud-metadata addresses before it sends anything.
  • If a vendor restricts API access by IP address, allow Safeguard's outbound address. Ask Safeguard support for it.

Card statuses

After you connect, Safeguard checks the credential with the vendor and shows the result on the card.

StatusMeaningWhat to do
VerifiedThe provider confirmed this credential.Nothing.
Not workingThe provider rejected this credential, or a setting is wrong. The card shows the reason, for example a missing grant or a wrong region.Reconnect, or fix the setting the reason names.
UnverifiedThe credential is stored but not confirmed yet: the provider did not answer the last check.Use Re-check to try again.

Admins can Re-check one connection, or Re-check all. Collect evidence now on the Connectors page starts a collection immediately instead of waiting for the next scheduled run.

Managing a connection

Open a connected card to manage it:

  • Test connection asks the provider whether the stored credential still works.
  • Reconnect lets you enter the credential again, for example after you rotate a key or change a setting such as the region.
  • Re-authorize runs the sign-in again, for an expired token or a rotated key.
  • Rename changes the label that tells one account apart from another account of the same provider.
  • Disconnect clears the credential. The connection's tests stop and its earlier results stay as history.
  • Remove deletes the connector entirely.

Several accounts of one provider

Some providers can be connected more than once, one connection per account: OVHcloud, AWS (including GovCloud), Google Cloud (including Cloud Storage), Microsoft Azure (including Azure Government), Cloudflare, GitLab Self-Managed and Jira. When multiple accounts are switched on for your workspace, a connected card offers Add another account: give the account a label (for example "OVHcloud US" and "OVHcloud EU") and enter that account's credentials. Each account gets its own card, every test runs against each account, and each result names the account it came from.

Automated tests

Most connectors feed automated compliance tests, which check a setting in the connected system against a control and record the evidence. Tests for a provider are switched on per workspace by the Safeguard team, so a new connection may show Verified before its tests run.

A newly added test starts in a preview period, typically 14 days. During preview its results show on the Tests page, but they do not change any control's status or your readiness score, and they open no tasks. After the preview the test counts like any other.

Tests run on a schedule, about every six hours, and each test runs as often as it is due (daily by default). To run them sooner, use Run now or Run all tests on Compliance › Tests.

Setup guides

Every other connector has setup steps on its category's page under Setup by category, for example Identity & SSO or Version Control: the methods that work for it, the OAuth scopes Safeguard asks for, the credential and permissions to create at the vendor, and what to enter in the connect form. The setup reference lists every connector in one table, and the Connectors page lists every connector by category with the evidence it produces.

On this page