Origin allowlist

Keyring only allows credentials to be used with approved destinations and defends against exfiltration attempts. A valid Composio token proves who is calling, but it does not decide where a credential may go. Before Keyring asks your KMS to open a credential, the destination must match the policy for that credential’s toolkit.

​

Each credential stays with its toolkit

Every credential is sealed for one toolkit. Keyring checks a Gmail credential against Gmail’s approved origins, even if the request names a destination approved for another toolkit. A Gmail tool call to gmail.googleapis.com passes the destination checks, so Keyring can ask your KMS to open the credential and forward the request. A Gmail tool call to slack.com is denied. Slack may be approved for the Slack toolkit, but it is not an approved destination for a Gmail credential. Keyring makes no KMS call.

​

Ordinary tool calls cannot reach token endpoints

Keyring separates ordinary provider requests from token issuance, OAuth refresh, and revocation. A tool call to oauth2.googleapis.com/token is blocked on the forward route even though it is a Google destination. Only the exchange route can reach that endpoint. This separation matters because a token endpoint can turn a refresh token into a new credential. The exchange route encrypts fields such as access_token, refresh_token, id_token, and client_secret before returning the response to Composio. If Keyring cannot safely apply those rules, it fails closed. See Credential refresh and exchange for the complete refresh flow.

​

Checks applied to every provider request

A failed check ends the request before decryption. Keyring never falls back to a broader rule.

​

The policy manifest

The official image includes a reviewed manifest with one entry per toolkit. Standard deployments use this bundled policy automatically. Most providers accept a credential in a header or query parameter. When a provider requires a secret inside a JSON body, body_secrets limits it to reviewed endpoints and fields. Keyring rejects placement anywhere else. Do not set origin_policy.manifest_url for a standard deployment. A custom policy is useful when you want to block specific toolkits or operations, or when a provider uses a private or customer-specific destination. Custom policies should be reviewed before use and should prefer exact provider hosts over broad wildcards. See Network and request policy for inbound access, redirect handling, and the controls you can customize in your deployment.