How Probo Protects Integration Credentials

When you connect an access source with an API key or OAuth, you authorize Probo to call the provider on your behalf. This page explains what happens to those credentials, what data Probo collects, and the controls in place on Probo Cloud. If you self-host Probo, see Self-hosted deployments for operator responsibilities.

What you connect

Access reviews support three connection methods:

• OAuth. When Add Source offers Connect for a provider, you approve Probo on the provider’s consent screen. Probo stores OAuth tokens needed to refresh access, not your provider password. OAuth availability depends on the provider and deployment configuration.
• API key. You create a token on the provider and paste it into Probo during Add Source. Use the least-privilege token each connector guide describes.
• CSV. No live credential is stored; you upload an export for tools Probo cannot connect to directly.

For OAuth and API key flows, Probo must hold credentials that can be used again on each sync or campaign. That is why credentials are encrypted at rest, not hashed like a password.

Data flow

The sequence diagram below follows the same lifecycle as the numbered steps that follow. Messages read top to bottom within each section. CSV uploads skip credential storage; only OAuth and API key paths use connect, store, and sync.

sequenceDiagram
  actor Admin as Organization admin
  actor Member as Organization member
  participant Console as Probo console
  participant App as Probo application
  participant KeyStore as Encryption key custody
  participant DB as PostgreSQL
  participant Provider as Third-party provider

  Note over Admin,Provider: Connect with OAuth or API key (CSV uploads skip stored credentials)

  Admin->>+Console: Submit credential over HTTPS
  Console->>+App: Create connector
  App->>App: Authorize owner or admin
  App->>KeyStore: Read deployment encryption key
  App->>DB: Store AES-256-GCM encrypted credential blob
  App-->>-Console: Connector metadata only
  Console-->>-Admin: Connected (secret not shown again)

  Note over Member,DB: List sources

  Member->>Console: View Sources
  Console->>App: List connectors
  App->>DB: Read rows without decrypting credentials
  App-->>Console: Ids and providers only
  Console-->>Member: No stored secrets returned

  Note over App,Provider: Access review sync

  App->>KeyStore: Read deployment encryption key
  App->>DB: Decrypt credential in memory
  App->>+Provider: Authorized HTTPS API call
  Provider-->>-App: Membership metadata
  App->>DB: Save review data in your organization

  Note over Admin,Provider: Disconnect

  Admin->>Console: Delete source
  Console->>App: Delete connector
  App->>DB: Remove encrypted credential row
  Admin->>Provider: Revoke or rotate token at provider

Credential lifecycle

1. Submission. You connect a source over HTTPS from the Probo console. Organization administrators (and roles with equivalent connector permissions) can create connectors; viewers can see that a connector exists but never receive stored secret values.
2. Encryption before storage. API keys, OAuth access and refresh tokens, and client secrets are serialized and encrypted with AES-256-GCM using a deployment encryption key. Each connector row stores the result in an encrypted credential blob with its own random nonce. Non-secret settings (for example a Crisp website ID) stay in separate configuration fields.
3. No echo back. Listing connectors in the UI or API returns metadata only: connector id, provider, OAuth scopes where relevant, and creation time. Stored keys and tokens are not shown again after setup.
4. Use on demand. Probo decrypts a credential only inside the application when it must authenticate an authorized request to the provider, for example during an access review sync. Listing connectors for display does not decrypt credentials.
5. Disconnect and delete. Removing a source deletes the connector record and its encrypted credential from Probo. Disconnecting also stops new fetches from that integration. Revoke or rotate the token on the provider side as well so the old credential cannot be reused outside Probo.

Some integrations use a deployment-managed token (for example the Crisp marketplace plugin). In that model Probo does not copy the shared plugin token into your organization’s stored connection; you prove ownership of the resource separately. Check the connector guide for your provider.

Credential encryption

Integration credentials receive application-level field encryption using AES-256-GCM and a random nonce for each encrypted credential blob. The encryption key is stored separately from application data.

This matches the safeguards described in our Privacy Policy: encryption in transit, encryption at rest, and row-level AES-256 for sensitive fields where applicable.

Probo is not zero-knowledge: the service must process credentials to run integrations. The design goal is to minimize exposure (no re-display of secrets, decrypt only when needed, strict access control) and to separate the encryption key from the encrypted data.

For network isolation, data-at-rest encryption, key custody, and backups, see Probo Cloud Infrastructure Security.

Access control and tenant isolation

• Connectors belong to your organization. Database access and authorization checks are scoped to your tenant.
• Owners and administrators can create, reconnect, and delete connectors. Viewers can list connectors but cannot manage credentials.
• Successful connector changes are subject to the same organization audit logging model as other sensitive actions. Engineering standards treat credentials and tokens as data that must not appear in logs; report a concern to security@probo.com if you believe a secret was exposed.

What Probo collects from providers

For access reviews, Probo collects membership metadata the provider exposes: name, email, role, admin flag, account status, MFA state, and last login where available. It does not aim to copy full account dumps or unrelated product data. See What Probo Collects on the overview page.

Integration Data is used only to operate the features you enable. We do not use it for advertising, resale, credit decisions, ad profiles, or training generalized AI models. Details are in the Privacy Policy (Integration Data section).

Recommendations before you connect

• Prefer OAuth when Add Source offers it for the provider.
• Create a dedicated, scoped API token per provider (read-only where the guide allows). Avoid global or personal keys when a scoped token exists.
• Store the token in a password manager until you paste it once into Probo; do not share it in chat or email.
• Rotate or revoke at the provider when someone leaves or the integration is unused, then delete the source in Probo or reconnect with a new token.
• Review who has administrator access in your Probo organization; those users can manage connectors.

Some provider APIs do not offer a read-only or narrowly scoped credential for listing accounts. Their connector guides call this out explicitly. When a broad credential is required, use a dedicated account where the provider permits it, rotate the credential on a schedule, and remove the source when the review is no longer needed.

Network Restrictions

Some providers can restrict API credentials to specific source IP addresses. For Probo Cloud, leave that restriction disabled unless Probo has supplied fixed egress addresses for your environment. For a self-hosted deployment, you can allowlist the fixed egress addresses configured by your infrastructure operator.

An IP restriction that does not include the deployment’s outbound address causes the connector test or campaign fetch to fail even when the credential itself is valid.

Self-hosted deployments

When you run Probo yourself, you operate the encryption key, HTTPS ingress, database, object storage, backups, and access to production systems. Configure the required encryption-key in probod settings; it encrypts sensitive data at rest the same way as Probo Cloud’s application layer. See Configuration file and Self-hosting.

Connector OAuth application IDs and secrets for each provider are also deployment configuration in self-hosted setups, not customer-pasted values in every case.

Related documentation

• Access Reviews overview
• Connector directory
• Probo Cloud Infrastructure Security
• Privacy Policy
• Compliance Portal