> ## Documentation Index > Fetch the complete documentation index at: https://keyring.docs.composio.dev/llms.txt > Use this file to discover all available pages before exploring further. # Security model > Trust boundaries, customer controls, cryptography, fail-closed behavior, and residual risks. export const TrustBoundaryDiagram = () =>
; export const AuthGateDiagram = ({scenario}) => { const AUTH_GATE_CHECKS = [{ key: "signature", label: "Signature · Composio JWKS" }, { key: "issuer", label: "Issuer · backend.composio.dev" }, { key: "audience", label: "Audience · your organization ID" }, { key: "expiry", label: "Expiry · under one hour" }, { key: "jti", label: "Token ID · not seen before" }, { key: "policy", label: "Toolkit + destination policy" }]; return
; }; 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 Composio stores encrypted credentials that are unusable without your Keyring and KMS permission. Stop Keyring or revoke its KMS access to stop all use. Reviewed policy can disable selected toolkits or operation classes while leaving others available. Keyring verifies every request against Composio's published keys and your organization ID. Tokens are valid for no more than one hour. A credential sealed for one toolkit cannot be relabeled and used for another provider. Authentication and provider policy run before decryption. A denial never falls back to broader access. 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: ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} AUTH_JWKS_URL=https://backend.composio.dev/.well-known/jwks.json AUTH_ISSUER=https://backend.composio.dev AUTH_AUDIENCE= AUTH_JWT_ALGORITHMS=RS256 ``` 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 | Control | Protection | | ------------------ | ----------------------------------------------------------------------- | | Stored credentials | AES-256-GCM envelope encryption | | Data keys | Wrapped by customer-owned AWS KMS, GCP Cloud KMS, or Vault Transit keys | | New credential | Browser-side JWE with RSA-OAEP-256 and A256GCM | | Context binding | Credential purpose and toolkit are cryptographically bound | | Key selection | Explicit key allowlists; unknown or retired key references fail closed | | Key separation | Credential, authorization-gate, and transfer keys must remain distinct | ## 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.