When you add a credential
The Dashboard handles this flow automatically for credentials added through Composio Connect URLs and the Composio web flow.- Composio requests the active public transfer key from your Keyring. The matching private key never leaves your KMS.
- The Dashboard seals the credential in the browser and binds it to its toolkit before sending it to Composio.
- Composio sends the sealed credential to Keyring. Keyring opens it through your KMS and immediately encrypts it under your customer-controlled credential key hierarchy.
- Composio stores only the encrypted credential and its wrapped data-encryption key. Using it later still requires your running Keyring and its KMS authorization.
Encryption detail
Encryption detail
The Dashboard uses compact JWE with
RSA-OAEP-256 and A256GCM. Keyring validates the algorithm,
encryption mode, transfer-key ID, and toolkit binding before opening the payload.One tool call, end to end
1. Your application requests a Composio tool
Your application uses Composio exactly as it does without Keyring. It does not call Keyring directly and does not need to understand the credential envelope.2. Composio sends an authenticated request
Composio sends the tool instructions and encrypted credential to your Keyring. The request carries a signed token that Keyring verifies against Composio’s published keys and your configured organization ID. Tokens are time-limited to no more than one hour. The token proves who sent the request; it does not grant unrestricted credential access.3. Keyring checks policy before decryption
Keyring checks the toolkit, provider destination, operation type, redirect behavior, and allowed secret placement before asking your KMS to open the credential. A failed authentication or policy check stops the call without touching plaintext. This per-call verification is the core of Keyring’s zero-trust request model: network location alone is never enough to use a credential.4. Plaintext exists only for the provider call
After the checks pass, your KMS authorizes Keyring to decrypt the credential. Keyring places the credential only in the approved provider request and does not persist it. Provider responses return through Keyring. New access tokens, refresh tokens, and other credential fields are encrypted before they leave your environment. If Keyring cannot safely protect a successful response, it fails closed instead of returning plaintext. See Credential refresh and exchange for a field-by-field walkthrough of how Keyring obtains a new provider token without returning its plaintext value to Composio.5. Every credential use is auditable
Tool calls, token issuance, OAuth refresh, and revocation all pass through Keyring. Each operation produces a customer-owned audit event describing what used the credential, the destination, the policy result, and how the response was handled—without recording the credential itself. With required audit durability, Keyring does not return a successful sensitive operation until your collector acknowledges the audit event.Who holds what
Composio does not hold your KMS keys or reusable plaintext credentials. Stopping Keyring or revoking
its KMS permission makes the encrypted credentials held by Composio unusable.