Skip to main content
Every provider request passes through layered policy before Keyring decrypts a credential. A valid Composio signature is necessary, but it is not enough on its own.

​
Bundled provider policy

The official image includes a reviewed Composio policy that defines, per toolkit:
  • approved provider origins;
  • token issuance, refresh, and revocation destinations;
  • where credentials may be placed in structured provider requests; and
  • which response fields must be encrypted before leaving Keyring.
Standard deployments should omit origin_policy.manifest_url. Omitting it selects the bundled policy; it never disables policy enforcement.

​
Inbound access

At your public edge, allow HTTPS only from the Composio production egress addresses. Keyring also requires a valid Composio JWT for every credential operation, so possession of an allowed source IP is not sufficient. The Composio Dashboard receives only the public transfer key through Composio and does not need a direct network path to Keyring.

​
Outbound destination controls

In staging and production, provider targets must use HTTPS. Keyring rejects local hostnames and direct loopback, link-local, private, reserved, or otherwise non-public IP destinations. The target must also belong to the requested toolkit’s approved origins. Unknown toolkits and unmatched destinations are denied before decryption.

​
Token operations are isolated

Provider token issuance, refresh, and revocation are handled as protected token operations rather than ordinary provider forwarding. Their destinations must match the toolkit policy, and sensitive response fields are encrypted before returning to Composio. This separation prevents an ordinary tool request from calling a token endpoint and returning a new plaintext credential. See Credential refresh and exchange to follow an OAuth refresh through authentication, KMS authorization, the provider token endpoint, response encryption, and audit delivery.

​
Request and redirect controls

Credentials can be inserted only into reviewed request locations for the toolkit and destination. Arbitrary or nested credential placement in provider bodies is denied. Redirects are not trusted automatically. When following is permitted, Keyring checks the new destination against the same HTTPS, public-address, toolkit, and token-endpoint rules before continuing. Keyring also removes transport-specific and untrusted internal headers before forwarding requests or returning provider responses.

​
Customer controls

You have three levels of shutdown:
  1. All credential use: stop Keyring or revoke its workload identity’s KMS access.
  2. Selected projects or auth configs: disable Keyring routing for that Composio scope.
  3. Selected toolkits or operation classes: apply a reviewed custom policy that removes those destinations or capabilities while preserving the rest.
Use a custom policy only when it has been reviewed for your deployment. Broad wildcards increase the risk of credential exfiltration; prefer the narrowest provider hosts and operation patterns possible.

​
Private and self-hosted providers

Self-hosted services and per-connection endpoints may not have stable public origins. They remain denied until an appropriate network path and reviewed custom policy are configured. Do not use production APP_ENV=local to bypass private-address protection.