How the platform protects integration credentials

When you connect an access source to an API or OAuth key, you authorize the platform to call the provider on your behalf This page explains what happens to these credentials, what data the platform collects, and the existing controls on the ZebraByte CloudIf you are self-hosting the platform, see Self-hosted deployments for operator responsibilities.

What connects

Access reviews support three connection methods:

OAuth. When Add Source offers Connect for a provider, approve the platform on the provider’s consent screen. the platform stores the OAuth tokens needed for re-renewing access, not the provider’s password. the availability of OAuth depends on the provider and the deployment configuration.
API key. Create a token on the provider and paste it into the platform during Add SourceUse the least privileged token described by each connector guide.
CSV. No live credentials are stored; upload an export for instruments to which the platform cannot connect directly.

For OAuth and API key streams, the platform must hold credentials that can be used again with each synchronization or campaign. encrypted at rest, not hashed like a password.

Data flow

The sequence diagram below follows the same life cycle as the numbered steps that follow. CSV Storage credential skip loads; only the key pathways OAuth and API use connection, storage and synchronization.

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

Submission. Organizational administrators (and roles with equivalent connector permissions) can create connectors; viewers can see that a connector exists, but never receive secret values stored.
Encryption before storage. API keys, OAuth access and refresh tokens and client secrets are serialized and encrypted with AES-256-GCM using a implementation encryption key. Each row of connector stores the result in a encrypted credential blob Non-secret settings (for example, a Crisp site ID) remain in separate configuration fields.
No echo back. Listing connectors in UI or APIReturns only metadata: connector identifier, provider, OAuth domains, if applicable, and creation time.
Use on demand. the platform decrypts a credential within the application only when it needs to authenticate an authorized application to the provider, for example during an access review synchronization.
Disconnect and delete. Removing a source deletes the connector record and its encrypted credentials from the platform. Disconnecting also stops new recoveries from that integration. Revoke or spin the token on the provider side so that old credentials cannot be reused outside the platform.

Some integrations use a deployment-managed token (for example, the Crisp Marketplace plugin).In this model, the platform does not copy the shared plugin token into your organization’s stored connection; prove ownership of the resources separately.

Credential encryption

Integration credentials receive application-level field encryption using AES-256-GCM and a random nonce for each blob of encrypted credentials.

This corresponds to the guarantees described in Privacy Policy: transit encryption, resting encryption and row-level AES-256 for sensitive areas where appropriate.

The platform is not zero-knowledge: the service must process credentials to run integrations. minimize exposure (do not display secrets again, decrypt only when necessary, strict access control) and separate the encryption key from the encrypted data.

For network isolation, resting data encryption, keeping keys and backups, see ZebraByte Cloud Infrastructure Security.

Access control and tenant isolation

Your connector belongs organizationAccess to databases and authorization checks are directed to the tenant.
Owners and administrators can create, reconnect and delete connectors. Viewers You can list connectors, but you can’t manage credentials.
Successful connector changes are subject to the same organization audit logging Engineering standards treat credentials and tokens as data that should not appear in the log; report a concern securitate@the platform.com if you believe a secret was exposed.

What the platform collects from suppliers

For access assessments, the platform collects membership metadata the provider discloses: name, email address, role, administration flag, account status, MFA status and last login where available. What the platform collects on the presentation 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 generalized artificial intelligence modeling. Privacy Policy (Integration Data section).

Recommendations before connecting

Prefer OAuth when Add Source Provide this to the provider.
Create a dedicated, scoped APItoken on provider (read only where the guide allows). Avoid global or personal keys when there is a token with scope.
Store the token in a password manager until you paste it once into the platform; do not share it in chat or email.
Rotate or revoke to the provider when someone leaves or integration is not used, then delete the source from the platform or reconnect with a new token.
Review who has administrator access to the platform organization; these users can manage connectors.

Some providerAPIs do not offer a credential only for reading or with a restricted scope for listing accounts. Their login guides explicitly exclude this. When a broad credential is required, use a dedicated account if the provider allows this, spin the credential onto a program and remove the source when review is no longer needed.

Network Restrictions

Some providers may restrict API credentials to certain source IP addresses. ZebraByte Cloud, leave this restriction disabled unless the platform has provided fixed egress addresses for your environment. self-hosted deployment, you can permit list of fixed egress addresses configured by your infrastructure operator.

An IP restriction that does not include the deployment output address causes the login test or campaign to fail, even when the credential itself is valid.

Self-hosted deployments

When you run the platform, you to operate the encryption key, HTTPS input, database, object storage, backup and access to production systems. Configure ___ZBT_I18N_RUNTIME_BLOCK_178__ in probod settings; it encrypts sensitive data in rest in the same way as the ZebraByte Cloud application layer Configuration file and Architecture & Migration Reference.

The Connector OAuth app IDs and secrets for each provider are also deployment configurations in self-hosted settings, not past values by the client in each case.