On this page
Connecting an AI to email looks like one decision: grant permission and the assistant can act. That screen does not describe every place the data may be processed or retained. Permission, credential custody, execution logs, and model inputs are separate events.
Composio supplies the infrastructure between AI agents and connected applications. Its tools manage authentication and execute requests against services such as Gmail, GitHub, and Slack. For a person using an agent built on Composio, the practical question is less whether an integration can be authorized than what happens after authorization.
This reading uses Composio's Privacy Policy, effective November 18, 2025, and its Terms of Service, both read October 9, 2026. The current terms page does not display an effective date, although its modification clause refers to one. An older terms URL displays January 1, 2024; that date should not be silently assigned to the current page. The analysis also uses Composio's data-retention documentation, zero-data-retention guide, token custody guide, and Data Processing Addendum, last updated September 2, 2026.
There are two people to keep distinct. Composio calls the developer or organization buying the infrastructure its customer. The person whose mailbox or workspace that developer connects is an end user. The two may have different access to settings, contracts, and deletion controls. Most people encounter the connection; the developer operates the project.
The connection gives Composio a role in the transaction
The privacy policy's collection section covers information a user supplies, including “name, email address,” and technical information collected when the platform is accessed: IP address, browser type, operating system, identifiers, and usage patterns. It also names session, performance, analytics, and certain third-party cookies. This is the account and device layer, distinct from mailbox content.
The more consequential layer is authentication. Composio's token custody guide states that, in its default hosted deployment, Composio holds the provider credentials. It exchanges or refreshes them and authenticates tool requests on the person's behalf. The developer's app generally works with identifiers and tool arguments rather than holding the underlying provider token. Composio documents encryption at rest and in transit, plus token masking on connected-account API responses.
The credential can remain masked while a request and its result still pass through Composio's execution service.
The Data Processing Addendum, in Attachment 2, explicitly describes authentication credentials, information that agents read from or write to connected applications, and tool-call metadata and payloads as categories of data involved in processing. Its examples encompass communications, calendar entries, files, and business records. They may also contain information about people who never installed Composio: correspondents, meeting attendees, and contacts. A person granting access to an inbox cannot grant those third parties a separate consent through the connector screen.
The request, result, and log follow different paths
The diagram follows documented hosted execution. A model need not receive a credential, but a developer may supply it with the retrieved content.
Diagram: Composio's documented authorization, credential custody, tool execution and retention paths. · View the original cover illustration
Person -> developer's agent -> Composio execution -> connected app
^ | ^ |
| | | result |
+----- result ------+------+<--------------+
|
+-> chosen AI model (if the agent sends content)
Composio: execution logs by default
Optional: file staging, triggers, sandbox
Others: provider, model, developer's own logs
The data-retention guide says execution logs contain metadata identifying the tool and associated connections, the user ID supplied by the developer, status, timing, and runtime. It also lists, under what is stored, “By default, the request arguments and response data for each tool execution.” In a mail-reading operation, request arguments may identify a message or search; response data may include its contents. A masked OAuth token does not remove those contents from a log.
According to that guide, execution and trigger logs are retained for “up to one year”. This is a maximum retention window, not a statement that every record survives for exactly twelve months. The broad privacy policy uses the phrase “only as long as necessary” for personal and usage data. The technical document gives a more useful number for the execution-log category.
Files have another lifecycle. Composio describes staging files used or returned by tools in temporary object storage. A download URL ordinarily expires after one hour and can be configured for up to twenty-four hours; link expiry is not deletion of the underlying file. Staged files are deleted “after 24 hours”; certain non-file sandbox state may clear after approximately twelve hours of inactivity. Those windows concern temporary execution material. They do not convert the one-year log window into a twenty-four-hour rule.
The privacy policy separately sets a maximum thirty-day retention and refresh-or-deletion cycle for YouTube API data. It would be inaccurate to read that YouTube-specific promise as the retention rule for every connected app.
What zero retention covers
Composio has a Zero Data Retention (ZDR) setting. The current ZDR guide says covered tool calls and Proxy Execute requests can run without retaining their arguments, returned data, or error text in execution logs. Audit metadata remains. The option is available as a paid add-on and included on Enterprise. It is not available for new activation on the Hobby plan. On paid plans other than Enterprise, newly created projects start with ZDR disabled even when other projects have it enabled.
The wording also sets a boundary: “ZDR applies only to new calls.” Turning it on does not erase earlier execution payloads. These retain the standard window of up to one year. Further, the documentation states, “ZDR covers calls through Composio Managed apps only on the Enterprise plan.” Hosted accounts behind Instant Tools may be subject to a separate provider's retention; triggers continue to hold events for delivery; files are staged; the sandbox has its own state; search queries may be cached. Even under ZDR, Composio keeps audit logs and service telemetry. Its supplied user ID, account association, and tool/timing information remain important operational metadata.
The question for a developer is therefore which project issued the call, which authentication configuration it used, whether ZDR covered that call, and which optional features handled its material. The question for an end user is harder: the person who authorized Gmail may never see the project settings that answer it.
| Data or operation | Standard Composio Cloud | ZDR for covered calls | Distinction for the person |
|---|---|---|---|
| OAuth credentials | Held and used by Composio in hosted mode | Still needed for hosted authentication | Encryption and masking do not mean local custody |
| Tool request and result | Payloads logged by default, with audit metadata | Payloads omitted from covered new logs | Existing logs are not retroactively erased |
| Execution and trigger logs | Up to one year | Audit metadata remains; trigger events still processed and stored | Content and metadata have different rules |
| Uploaded or returned files | Temporary object storage; deletion after 24 hours | File staging is outside ZDR coverage | A short-lived download link is not immediate deletion |
| Model and destination provider | Receive data supplied to them in execution | Governed by their own policies | One vendor's switch does not set another vendor's retention |
The table describes Composio's mechanisms, not every agent built on it. Developers separately decide what results reach a model and what their own systems retain.
The sharing promise has a specific subject
Composio's privacy policy makes explicit commitments about Google user data. In Section 3 it says it does not “Use Google user data to build or improve machine learning or AI models.” It also restricts advertising, sale, and sharing, while allowing transfers necessary for providing the platform's core functionality. These are meaningful restrictions, and they should be read as written: the section is expressly about Google user data.
The same policy says Google data is processed for the integration service. It does not follow that no service ever processes a result or that an AI agent can work without receiving relevant content. In the token custody guide, Composio states that the model sees tool definitions and the results the application or client chooses to supply. In the data-flow documentation, the destination provider, execution infrastructure, optional third-party sandbox, configured trigger destinations, and selected model provider appear as possible participants. A provider's own privacy policy governs what happens within that provider.
The distinction becomes clearer in Composio's compliance guidance, last verified August 12, 2026: “Do not infer a blanket no-training guarantee.” The guidance directs customers needing end-to-end contractual terms on training and retention to the Enterprise track. This is not an assertion that Composio trains on people's Gmail messages; the Google-specific prohibition says otherwise. It means that the published material does not warrant an unconditional claim about every app, model provider, hosted account, or downstream execution path.
Composio's DPA offers a separate restriction on secondary processing. It describes the developer customer as controller and Composio as processor, limits use to service provision and documented instructions, and provides a framework for subprocessors. Its public page says, “This DPA is not binding unless and until accepted by Customer through the Composio dashboard.” The DPA is available for acceptance by Pro and Enterprise Developer customers. A consumer using somebody else's agent should not assume that consumer personally accepted the DPA or chose the model provider. Subprocessor information is directed to Composio's Trust Center; the list can change and is separate from the privacy policy's Google-specific language.
The terms grant a license; they do not settle every data question
The Terms of Service, Section 8, first say that users retain ownership of User Content. They then give Composio a “worldwide, non-exclusive, royalty-free, sublicensable, and transferable license” over the User Content submitted, posted, or displayed on or through the platform, for uses “in connection with the platform and Composio’s business.” These are broad legal permissions, even though ownership remains with the user. For covered User Content, the license permits copying, distribution, adaptation, display, and performance, as well as sublicensing or transfer.
It is important not to extend the clause beyond its defined subject. The terms' phrase User Content does not expressly explain whether every byte read from an outside account counts as content submitted or displayed by the person using the service. Nor does a license to perform platform-related acts, by itself, prove sale of mail data or AI training. The privacy policy's Google provisions and, when accepted, the DPA place more specific constraints on some processing. The scope of the general license remains a question worth distinguishing from how any one tool actually operates.
Section 9 permits suspension or termination “without prior notice or liability” at Composio's discretion and says provisions that by nature survive termination will survive. Section 13 gives Composio co-marketing rights to identify a Customer, including its name and logo. That refers to the business customer, not necessarily to every individual whose connected accounts it handles. Neither clause describes an automatic deletion timetable for all copies held by different providers.
The current page promises notice of material changes but displays no effective date. The review date consequently matters.
Deletion is a sequence, not a single button
The privacy policy lists rights to access, correction, deletion, withdrawal of consent, and a copy of personal data. Section 8 gives support@composio.dev as the contact for requests; it does not publish a universal turnaround time in that section. For YouTube-related data it also describes immediate deletion on request.
A developer can delete a connected account through Composio's v3.1 API. That stops the connection from being used for further API calls. The same reference provides an optional revoke_on_delete=true parameter to begin upstream token revocation, defaulting to false. Deleting the connector record and cancelling the authorization at Google, GitHub, or another app are therefore separate actions. Revoking the provider grant in the provider's own settings is a useful independent step.
An organization administrator can also use the organization deletion control. Composio's help page says its warning covers permanent removal of projects, connected accounts, keys, and logs. That is a different scope from deleting one connected account. Composio recommends handling upstream grants separately when necessary. A person connecting through another company's product may not have administrator access to the Composio organization.
When the DPA applies, Section 2.5 requires Composio to “delete or return” personal data after services end, subject to legal retention obligations. Meanwhile, the technical ZDR page explains that switching off payload storage affects new calls, leaving previous logs for their existing retention period. None of those mechanisms gives an end user direct control over material already delivered to a model provider, an external app, or the developer's own log store. Requests to those parties may require separate procedures.
For someone deciding whether to authorize a connection, the questions are concrete: Who holds the credentials? Which tool arguments and results are recorded, under whose project settings? What remains after the connection is revoked? The documents provide answers to parts of that journey, but no single document is the whole journey.
What changes when the person keeps the context
A privacy-first architecture starts by reducing the number of custodians. It can keep the durable model of a person's work on that person's device and send a chosen AI only the minimum context needed for a task. The person selects the assistant and the scope of access; a calendar lookup need not become permission for an unrelated model to search a mailbox. Retention of local history and revocation of per-AI access can be exposed to the owner rather than hidden in a developer dashboard.
The boundary is specific. A third-party application sees requests addressed to it. A cloud model sees content sent to it. If remote execution is enabled, somebody must process the request. Local-first design does not erase those interactions. It changes what is retained by default, how much has to leave the person's computer, and who can inspect or end an authorization.
The test is observable at the end of an ordinary session. After a message is retrieved and used, is there now a durable copy in an intermediary's execution log? Does the next model get the entire message or a limited answer? When the person disconnects the account, can they see what has been removed, what has merely stopped being accessible, and what is still held elsewhere? Those are the boundaries a privacy policy should make legible.
Source review: October 9, 2026. Quoted clauses are drawn verbatim from the linked Composio policies and technical documentation.
