Skip to main content
BonData handles credentials in a way that minimizes plaintext exposure and removes long-lived credentials from any place they could be exfiltrated. All sensitive material, database credentials, message-broker credentials, model-provider API keys, application-layer encryption keys, and customer-supplied integration credentials, is stored in a managed secrets vault encrypted at rest, with access scoped to the specific service that needs it.

​
Where secrets live

In Cloud SaaS, BonData stores all platform secrets in AWS Secrets Manager, encrypted at rest with AWS KMS. In Cloud-Prem, the same model applies inside the customer’s own AWS account, secrets live in the customer’s AWS Secrets Manager, under the customer’s KMS keys, accessible only to the BonData services deployed in the customer’s account. Each secret has its own version history. Rotation is managed per secret; rotation events are picked up by the running services without restart.

​
Customer integration credentials

When a user connects an integration, Salesforce, Snowflake, HubSpot, and so on, the OAuth tokens or API keys provided during connection are encrypted at the application layer using a key drawn from the secrets vault, then stored in the operational database. Cleartext credentials exist only inside the running process that performs the integration call, and only for the duration of that call. Each integration credential is scoped to a single tenant. Credentials are never shared across tenants and are not accessible to any service other than the one performing the integration call. Users with the appropriate role can rotate or revoke an integration credential through the user interface at any time; revocation takes effect on the next call.

​
CI/CD

BonData’s build and release pipeline authenticates to AWS via OpenID Connect federation into a scoped IAM role, rather than a long-lived access key. No durable AWS credentials exist in CI, in source control, or in the codebase.