Data retention

Composio stores audit logs for tool executions so you can observe and debug your agents. You control whether the request and response payloads for each call are stored.

Customer data vs. your end users' data

Throughout this guide, you are the Composio customer. Your end users are the people your agent acts on behalf of. Each end user is identified by the user_id you provide. Composio stores this value as supplied and uses it to associate connected accounts, sessions, and execution logs.

Tool requests and responses may contain additional end-user data. The Log storage setting controls whether these payloads are retained; it does not remove the user_id or other audit metadata.

What Composio stores

Composio creates logs for tool executions and trigger events. These logs contain:

• For tool executions, the toolkit and action, execution status, connection and auth-config IDs, supplied user_id, timing, and runtime/source.
• By default, the request arguments and response data for each tool execution.
• For trigger events, similar audit metadata and, by default, the trigger payloads.

How long logs are retained

Tool execution logs and trigger event logs are retained for up to one year, after which they are automatically deleted.

How long files are available

When a tool uses or returns a file (an attachment, image, document, export, and so on), Composio stages it in temporary object storage and shares it through a presigned URL. The URL is valid for 1 hour by default. You can configure this URL TTL per project in Project Settings, up to 24 hours.

Presigned URL expiry and file deletion are separate. When the URL expires, the link stops resolving, but that does not delete the underlying object. Files staged for tool execution are automatically deleted from temporary object storage after 24 hours.

Workbench storage has two separate lifecycles:

• Files written to /mnt/files are backed by temporary object storage and are automatically deleted after 24 hours.
• Other sandbox files, variables, and runtime state are temporary and may be cleared after approximately 12 hours of inactivity.

Choose what we store: the Log storage setting

You control whether call payloads are stored for each project in Settings → General → Log storage:

• Store all logs (default) — Composio stores the full request and response payloads in the execution log.
• Don't store data — Composio does not store the request arguments or response data from your tool calls. It keeps only the audit record: which tool ran, when it ran, whether it succeeded, the relevant IDs, and timing information.

With Don't store data, Composio keeps an audit trail but does not retain your tool-call payloads (including your end users' data) in its logs. This setting also applies to Proxy Execute. If Composio cannot retrieve your project's log-storage setting, Proxy Execute does not store the request or response payload.

Changing the setting affects new calls

You can switch between the two log-storage options at any time. Each change applies only to new calls:

• Selecting Don't store data stops Composio from storing payloads for new calls. It does not delete payloads that were already stored: existing logs stay available until they age out under the one-year retention window.
• Selecting Store all logs again resumes storing payloads for new calls. It does not backfill the period while payload storage was disabled.

Payloads for calls made while storage was disabled were never stored and cannot be recovered later.

Where your data goes

Choosing Don't store data stops Composio from persisting your payloads, but data may still pass through the following locations during execution:

• The destination provider that receives the tool call.
• Composio's execution infrastructure while the call runs.
• Temporary object storage for files used or returned by tool calls. Presigned URL expiry is configurable per project, while the underlying staged file is deleted after 24 hours. See How long files are available.
• Your configured trigger destinations, which receive trigger events in real time.
• An isolated third-party code sandbox, if you use Workbench or remote code execution. Ordinary Python or shell execution does not inherently send code or sandbox files to an LLM provider. Model-provider processing occurs only in the cases described below.

When Workbench uses an LLM

When a task requires advanced processing, the agent or MCP client may use Workbench and call invoke_llm from the submitted code—for example, to summarize, analyze, extract, or generate content. Only the information passed to invoke_llm is sent to the model provider; sandbox files and previous results are not sent unless the submitted code includes them.

There is one separate case: if submitted Python contains a syntax error and automatic repair is enabled, Composio may send the code and error details to the configured model provider to fix it before execution. Valid Python and ordinary shell commands do not trigger this repair.

So "Don't store data" controls what Composio retains, not whether data is processed during execution. For the current list of our sub-processors and our data-handling terms, see the Composio Trust Center.

Stronger guarantees

If your organization needs a contractual zero-data-retention arrangement or shorter retention windows, contact sales. For our data-handling policies and sub-processor list, see the Composio Trust Center.