Skip to main content
Keyring’s security objective is narrow: a reusable plaintext credential may exist only inside your Keyring process and in the approved provider request that consumes it. Composio stores encrypted credential data, not plaintext credentials or plaintext data-encryption keys.

​
Trust boundary

Keyring authenticates Composio with its published signing keys, uses your KMS for root-key operations, and applies a reviewed toolkit policy to provider destinations. It still treats every requested URL, encrypted credential, request instruction, and provider response as untrusted input.

​
What this guarantees

No reusable plaintext at Composio

Composio stores encrypted credentials that are unusable without your Keyring and KMS permission.

A kill switch you own

Stop Keyring or revoke its KMS access to stop all use. Reviewed policy can disable selected toolkits or operation classes while leaving others available.

Signed, time-limited requests

Keyring verifies every request against Composio’s published keys and your organization ID. Tokens are valid for no more than one hour.

Credentials stay toolkit-bound

A credential sealed for one toolkit cannot be relabeled and used for another provider.

A failed check stops the call

Authentication and provider policy run before decryption. A denial never falls back to broader access.

Stateless and replaceable

Keyring stores no credential database. Instances can restart or scale without moving plaintext credential state.

​
Authentication

Configure the production Composio issuer and your organization ID:
Keyring verifies the signature, issuer, organization audience, allowed algorithm, unique token ID, and time window on every authenticated request. Invalid or expired tokens receive a generic denial; tokens and decoded token payloads are not logged.
A valid Composio token identifies the caller and organization. It does not authorize every provider destination. Toolkit, destination, operation, redirect, and secret-placement policy are checked separately for each request.

​
A failed check stops the call

A token issued for another organization passes the signature and issuer checks but fails the audience check. Keyring returns a generic denial, makes no KMS call, and never creates plaintext.

​
Cryptographic controls

​
Customer controls

  • Global stop: stop the Keyring service or revoke its KMS permission.
  • Selective stop: use a reviewed policy to disable a toolkit, destination, or operation class.
  • Credential scope: connect Keyring only to the Composio projects that should use it.
  • Evidence: export every credential use and token operation to your audit collector.
With AUDIT_DURABILITY=required, a sensitive operation cannot report success unless your collector acknowledges its audit event. Composio therefore cannot successfully use or refresh a credential through Keyring without producing customer-visible evidence.

​
Process and container hardening

The official container runs as a non-root user in a distroless image with no shell or package manager. The Helm chart defaults to a read-only root filesystem, drops Linux capabilities, blocks privilege escalation, and applies the runtime-default seccomp profile. These defaults complement—but do not replace—your network policy, image controls, KMS IAM, TLS termination, and host or cluster hardening.

​
Residual risks

Keyring protects known credential fields in provider errors, but a provider could place a secret in an unexpected field. Treat provider error bodies and protected operational logs as sensitive.
Keyring blocks direct local and private destinations and requires a toolkit-approved origin. Add DNS and egress controls appropriate to your environment for defense in depth.
Streaming provider payloads pass through without body inspection. Credentials are injected only through approved structured request locations, not arbitrary streaming bodies.