Agent Data Retention: Review the Actual Terms

Do not approve access to proprietary code or customer tickets on the strength of a no-training statement alone. Record four separate answers for the actual account and product surface: training use, retention, vendor human access and onward transfers. The documented OpenAI API training default and Anthropic commercial training restriction below are useful evidence, but neither should be treated as a universal deletion promise.

This is a contract-and-data-flow review, not a per-product training-defaults census. The cited evidence supports a detailed OpenAI API review and part of an Anthropic commercial review. Leave Copilot plan-specific defaults and personal-account defaults unresolved until you obtain their governing documents.

Source-check date: 29 September 2026, using the sources linked in this guide. The OpenAI and GitHub pages are undated in this evidence; retrieval is not publication. Anthropic’s Commercial Terms display “Effective June 17, 2025”. No account settings were inspected or account-level steps exercised by the publisher. This guide provides documentation-based education, not legal advice, a view on enforceability or certification of safety or compliance.

Start with the actual account, not the brand

Before reading a promise, write down the vendor, product, plan, account owner, organization or project, endpoint, model provider and connected tools. Include the proposed inputs and outputs: repository files, ticket text, attachments, generated patches and session records.

Do not assume that only a signed enterprise agreement can take effect: Anthropic’s published terms say, “These Terms are effective on the earlier of the date that Customer first electronically consents to a version of these Terms and the date that Customer first accesses the Services (‘Effective Date’).” The source uses double quotation marks around Effective Date. Commercial Terms, introduction.

For this review, reserve claims about negotiated customer-specific protections for the signed agreement and its amendments. No such agreement was supplied. Do not use a public summary to fill that gap.

OpenAI API: separate training, logs and application state

The following statements come from OpenAI’s undated developer documentation, retrieved 29 September 2026. Its March 2023 date belongs to the training statement, not to the whole page.

OpenAI states: “As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us).” Data controls, introduction. Record this for the API only; request separate evidence for any consumer account or other surface.

For abuse monitoring, OpenAI states: “By default, abuse monitoring logs are generated for all API feature usage and retained for up to 30 days, unless longer retention is required by law, or is reasonably necessary to protect our services or any third party from harm.” Data retention controls for abuse monitoring.

For Responses application state, OpenAI states: “Except as noted below, the Responses API has a 30 day Application State retention period by default, or when the `store` parameter is set to `true`. In those cases, response data will be stored for at least 30 days.” Responses endpoint notes.

Interpretation: preserve both “up to” and “at least” in your record. They describe different storage categories, not a single maximum retention period. Read the endpoint table together with its exception notes rather than treating a table cell as the complete policy.

For Assistants API objects, OpenAI states: “Objects related to the Assistants API are deleted from our servers 30 days after you delete them via the API or the dashboard. Objects that are not deleted via the API or dashboard are retained indefinitely.” Assistants, threads and vector stores. Assign an owner to deletion rather than assuming an abuse-log deadline deletes persistent objects.

Who can change retention—and what remains outside the control?

OpenAI says Zero Data Retention and Modified Abuse Monitoring require prior approval and additional requirements, and approved customers may choose between them for an API organization or project. Eligibility and approval. Record the approval evidence and applicable project, then obtain the authorized setting-changing roles for your deployment; this review does not establish them.

OpenAI cautions: “Besides those specific behavior changes, the endpoints and capabilities listed as No for Zero Data Retention Eligible in the table below may still store application state, even if Zero Data Retention is enabled.” Zero Data Retention.

For human access, OpenAI states: “If the classifier detects potential CSAM content, the image will be retained for manual review, even if Zero Data Retention, Modified Abuse Monitoring, or Private Retention with PSP is enabled.” Image and file inputs.

The Safety Retention section also reserves a right to make models ineligible for Zero Data Retention or Modified Abuse Monitoring for specific customers when reasonably necessary to investigate or prevent severe risk activity, with advance written notification. Safety Retention. Review that section and Private Retention with Private Safety Processing separately; do not equate encryption, no training and no human review.

For independent destinations, OpenAI states: “Data transmitted to third-party services over network connections is subject to their data retention policies.” Responses endpoint notes.

OpenAI also documents using sub-processors to provide its services. Sub-processors and regional request processing. Keep vendor sub-processors separate from independently connected services such as an MCP destination; request the relevant recipient list and processing terms rather than assigning every recipient the API’s policy.

Open approval questions: your governing agreement, actual opt-in status, endpoint and feature combination, approved controls, authorized roles, complete human-access conditions and downstream recipients’ terms. None should be filled from an assumed account configuration.

Anthropic: a training restriction is not a retention schedule

The following quotations are from the Commercial Terms effective June 17, 2025, retrieved 29 September 2026.

Section B states: “Anthropic may not train models on Customer Content from Services.” Customer Content.

Section E.4 states: “Recipient will destroy Discloser’s Confidential Information promptly upon request, except where retained to comply with law or copies in Recipient’s automated back-up systems, which will remain subject to these obligations of confidentiality while maintained.” Destruction Request.

Interpretation: record a destruction-on-request clause with exceptions, not a numerical default retention period. For this approval file, the numerical abuse-monitoring period, backup-deletion schedule and configurable retention authority remain unresolved. Request the applicable product documentation.

On human access, section E.2 permits sharing Confidential Information with employees, agents and advisors who need to know it and are bound by confidentiality obligations at least as protective as the terms. Obligations of Parties. Treat that as a confidentiality provision, not an exhaustive operational procedure for vendor review.

Section C states: “Data submitted through the Services will be processed in accordance with the Anthropic Data Processing Addendum (‘DPA’), which is incorporated into these Terms by reference.” The source uses double quotation marks around DPA. Data Privacy. The DPA itself was not supplied; obtain it and the applicable sub-processor evidence before completing those fields.

Section M.3 permits Anthropic to update the terms with a 30-day effectiveness rule, except changes responding to law or regulation take effect immediately upon posting or notice. Amendment and Modification. This is a terms-change mechanism, not an administrator’s retention setting.

GitHub Copilot: map the destination before assigning defaults

The following evidence comes from the undated GitHub Copilot Agents application card, retrieved 29 September 2026.

For Copilot CLI, GitHub states: “Your input is combined with relevant contextual information to form a prompt. That prompt is sent to a large language model for processing.” Copilot CLI input processing. Interpretation: local execution is not evidence that code context stays local.

For a user-configured model provider, GitHub states: “When you configure Copilot CLI to use your own model provider, your prompts, code context, and generated responses are sent directly to the provider you configure. They are not routed through GitHub.” Data handling when using your own model provider.

GitHub separately states: “When you use your own model provider without offline mode, Copilot CLI continues to send telemetry to GitHub as usual. This telemetry does not include your prompts or code, but it does include usage metadata.” Telemetry. Record this metadata route separately from the content route.

For the approval file, leave plan-specific training use, numerical retention, vendor human-review conditions and setting-changing roles unresolved. Obtain the applicable Copilot plan terms and data-handling documentation, plus the configured model provider’s terms where relevant. Do not substitute descriptions of temporary execution environments, foundation-model training data or evaluation datasets for customer-content retention terms.

Hypothetical worked example: enterprise approval, personal account

Suppose a team has approved an enterprise Claude deployment. A developer proposes using a personal Claude account for customer-ticket excerpts, assuming the enterprise restriction follows the product name. This is a hypothetical review, not an observed account or incident.

Anthropic’s Commercial Terms state: “Services under these Terms are not for consumer use. Our consumer offerings (e.g., Claude.ai) are governed by our Consumer Terms of Service instead.” Consumer-use boundary.

Recommended decision: defer proprietary-content access through the personal account until this two-document comparison is complete; use synthetic material for any interim evaluation. This evidence does not establish a difference in the two accounts’ defaults—it establishes why the comparison is necessary.

If the intended requirement is enterprise protection for that route, ask for explicit written coverage of the relevant account and surface, training restrictions, retention and deletion triggers, human-access exceptions and onward processing. That is the coverage gap a negotiated agreement would need to close. Do not assume an existing agreement already does so.

Create and maintain the approval record

1. Engineering: inventory every content destination, including attachments, logs and connected services. Separate training use, abuse monitoring, application-state storage, human review and onward transfer.
2. Legal reviewer: locate the actual plan’s governing documents and signed amendments. Preserve exact quotations, scope, document dates and retrieval dates.
3. Account owner: identify who can opt in, change storage controls, request deletion or authorize a different provider. Obtain configuration evidence separately from this guide.
4. For each vendor and surface, list what the reviewed document does not settle. Give every missing item an owner and a request for evidence.
5. Record an approve, restrict or defer decision for that specific route. Do not treat “not established” as permission.

Vendor / product / plan / account:
Surface / endpoint / content categories:
Governing document / version / signed amendments:
Training default / who can change it:
Abuse-log period / exceptions:
Application-state period / deletion trigger:
Human-access conditions:
Sub-processors / independent destinations / metadata routes:
Who can change each control / supporting evidence:
Exact quotation / section / URL:
Document date, or undated / retrieval date:
Not stated / missing document / owner:
Decision / restrictions / next review:

Maintenance policy: recheck weekly, with the next review due 6 October 2026. Compare saved wording and scope rather than merely advancing the date. Treat an undated first observation as a baseline, not a newly announced change. A relevant source change triggers review of affected approval records and correction of this same guide; do not wait for a separate announcement.

This revision adds the documented Copilot CLI telemetry route and uses the current OpenAI Private Retention terminology. It does not assign an effective date to either documentation difference or claim a newly announced policy change.

Sources

• OpenAI: Data controls in the OpenAI platform — developer documentation; undated page; retrieved 29 September 2026. platform.openai.com
• Anthropic: Commercial Terms of Service — standard commercial terms; displayed effective date June 17, 2025; retrieved 29 September 2026. anthropic.com
• GitHub: Application card: GitHub Copilot Agents — application documentation; undated page; retrieved 29 September 2026. docs.github.com