Skip to main content
Every tool call and credential lifecycle operation—including token issuance, OAuth refresh, and revocation—passes through Keyring and produces a structured audit event. Events describe the use without logging the credential, token, or decrypted provider payload.

Durable audit path

Set AUDIT_DURABILITY=required and configure OTEL_COLLECTOR_URL in production. With this mode, Composio cannot successfully use a credential through Keyring without the customer audit path recording the attempt. Use the telemetry delivery guide to deploy the recommended collector or evaluate a compatible direct OTLP endpoint. For ECS, a collector sidecar keeps the acknowledgment path local to the task while the collector owns batching, retries, and vendor authentication. Other deployments can use a nearby or remote OTLP/HTTP collector that meets the required availability and latency.

When the collector does not acknowledge

Keyring posts the event to <collector>/v1/logs and treats a 2xx reply as the acknowledgment. It makes up to three attempts of two seconds each, so an unreachable collector adds at most about six seconds before the request fails. If no attempt is acknowledged, Keyring does not release the provider response. It cancels the withheld response and returns HTTP 500 to Composio, so the operation is never reported as an unrecorded success. The provider may already have performed the action; what Keyring refuses to do is hand the result back without evidence. Denials and errors, which carry no secret material, are still exported but do not wait for the acknowledgment.

What is recorded

Each acknowledged audit.operation event records:
  • request ID, Composio’s request ID, time, method, route, and environment;
  • the toolkit whose credential was used, with the Composio project, user, and connected-account attribution the request carried;
  • the operation (tool call, token issuance, refresh, revocation, or key operation), its outcome, and the HTTP status;
  • the failure class when something went wrong—never the error message, which can quote request data;
  • the Composio issuer and token ID; and
  • the client IP.
Keyring’s logs and traces add the per-request detail around each event: the provider host, the policy decision, and whether each response field left Keyring encrypted, as plaintext metadata, or blocked. They are exported to the same collector, but they are not part of the acknowledged audit record. Keyring does not log raw credentials, access or refresh tokens, authorization headers, sealed browser payloads, plaintext data-encryption keys, or collector credentials.

Request correlation

Every Keyring response includes X-Composio-Keyring-Request-Id. Use it to join Keyring logs, traces, audit events, and the corresponding Composio operation during investigation.

Log levels

The default is info. Use debug only in a protected environment; it excludes credential values but still contains sensitive operational context.

Collector authentication

OTEL_COLLECTOR_HEADERS is a comma-separated list of percent-encoded Name=value headers:
Store collector credentials in your deployment platform’s secret manager. Keyring exports OTLP/HTTP traces, logs, and metrics to the configured collector base URL.
The Helm chart defaults to best_effort so a new installation can start without a collector. Set required and provide a reachable collector before handling production credentials.