> ## 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. # Audit and observability > Record every credential use, tool call, and token operation in customer-owned telemetry. export const RequestIdDiagram = () =>
x-composio-keyring-request-id 8c1f2e4a-…-9b7d
Composio response header 8c1f2e4a-…-9b7d
Keyring log line 8c1f2e4a-…-9b7d
Trace 8c1f2e4a-…-9b7d
Audit event 8c1f2e4a-…-9b7d
; export const AuditPathDiagram = ({scenario}) => { const labels = { acknowledged: "With AUDIT_DURABILITY=required, a tool call reaches the provider through Keyring. Keyring holds the provider's response, sends the audit event to your collector, waits for the acknowledgment, and only then releases the response to Composio.", unreachable: "With AUDIT_DURABILITY=required and the collector unreachable, Keyring holds the provider's response, fails to store the audit event, cancels the withheld response, and returns a 500 to Composio instead of an unrecorded success." }; return
; }; export const AuditEventDiagram = () =>
audit.operation
; 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 | Mode | Behavior | Use | | ------------- | ------------------------------------------------------------------- | --------------------------------- | | `required` | Sensitive success waits for your collector to acknowledge the event | Recommended for production | | `best_effort` | The operation does not wait for durable acknowledgment | Local evaluation or accepted risk | 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](/deployment/observability) 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 `/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 | `LOG_LEVEL` | Typical events | | ----------- | --------------------------------------------------------------------------- | | `debug` | Detailed KMS, encryption, cache, and policy steps | | `info` | Authentication, credential use, provider calls, token operations, and audit | | `warning` | Invalid requests, policy denials, and blocked destinations | | `error` | Provider, runtime, startup, and audit persistence failures | 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: ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} OTEL_COLLECTOR_HEADERS=Authorization=Bearer%20example-token,X-Tenant=customer-123 ``` 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.