Build a Data-Retention Matrix for Coding Agents Using CometAPI

Last reviewed: August 31, 2026

Direct answer

A CometAPI data retention matrix should be an executable allowlist, not a static policy memo. Give every approved coding-agent route its own row, keyed by the gateway route, model identifier, provider policy class, service tier, endpoint features, and local client behavior. Then associate that row with the classes of repository context it may receive.

The matrix must separate gateway handling from upstream-provider handling. CometAPI publicly states that it does not collect, store, or record prompts, inputs, outputs, or conversation content and does not save model communications to its servers or databases. That statement supports the gateway column in the matrix. It does not, by itself, answer how every selected model provider, service tier, endpoint feature, cache, or local coding-agent client handles the same content.

Before a request is assembled, classify the intended context and look up the complete route. Permit the request only when every required field is explicit, current, and compatible with that data class. If the provider, service tier, retention period, training treatment, or feature behavior is unknown, deny the request before proprietary code enters the prompt.

At minimum, each row should answer these questions:

Unknown values should never be interpreted as zero retention.

Who this is for

This guide is for platform engineers, security reviewers, developer-experience teams, and repository owners who let coding agents send nonpublic code through CometAPI. It is especially useful when one gateway can reach several model families or when automated fallback can change the effective provider without changing the agent task.

The matrix is an engineering control, not a substitute for legal review. Legal or privacy owners decide which documents constitute sufficient contractual evidence. Operators turn that decision into a deterministic preflight rule that an agent cannot bypass.

Key takeaways

• Classify content before building a prompt. A denial that occurs after prompt assembly may already leave sensitive material in local debugging output or exception traces.
• Treat gateway, provider, endpoint feature, and local client as separate retention layers.
• Key approval to an exact route and policy class, not only a marketing model name.
• Distinguish no model training from no storage. The provider documents checked for this guide show that those are different questions.
• Apply the same preflight to fallbacks. A safe primary route does not make an unreviewed backup route safe.
• Keep audit logs useful without copying source code, prompts, outputs, filenames, repository names, or developer identities.
• Expire evidence. A row with an old policy reference should move to review-required rather than remain approved indefinitely.

A practical operator workflow has eight steps:

1. Classify the task input. Inspect the requested files and tool outputs before prompt construction. Remove secret material entirely; use [REDACTED] in a diagnostic sample when a placeholder is necessary. Assign the highest applicable class to the whole request.
2. Resolve the route. Expand the agent’s friendly model alias into the gateway route, model identifier, provider policy class, service tier, endpoint mode, optional storage features, and fallback list.
3. Load the matrix row. Require an active row whose route tuple exactly matches the resolved request. Partial model-name matching is not sufficient.
4. Validate the evidence. Confirm that the gateway and upstream-provider documents are still reachable, the review date has not expired, and account-specific controls have been verified where a public document makes them conditional.
5. Minimize context. Send only the functions, tests, and error excerpts needed for the task. Exclude unrelated directories and production data.
6. Make the decision. Allow only when the data class is within the row’s approved scope and every mandatory field is known. Otherwise return a stable denial reason without transmitting the payload.
7. Record sanitized evidence. Log the decision metadata, not the content evaluated.
8. Recheck every fallback. If a route fails, run the full policy lookup for the next route. Never inherit the primary route’s approval.

A sanitized decision event can look like this:

event_time: 2026-08-31T10:00:00Z
run_ref: r-1042
policy_version: retention-v3
gateway: cometapi
route_alias: approved-code-route
provider_policy_class: commercial
data_class: confidential-source
decision: allow
reason_code: policy-match
evidence_reviewed_on: 2026-08-31
fallback_attempted: false
content_size_bucket: small

Do not add prompts, completions, source excerpts, full file paths, repository names, request headers, user email addresses, or raw tool output to this event.

Happy path: A task contains proprietary source code classified as confidential-source. The resolved route has a current matrix row, the applicable provider policy class is verified, the row permits that data class, optional persistence features are within policy, and every fallback is either separately approved or disabled. Preflight returns allow, the agent sends the minimum required context, and the system records only the sanitized event fields.

Error path: A deployment changes a model alias, but the new provider policy class or service tier cannot be proven. Preflight returns RETENTION_POLICY_UNKNOWN before prompt assembly. The agent does not send the request and does not retry through an unreviewed fallback. An operator either supplies current evidence and approves a new row or selects an already approved route.

Sources checked

• The CometAPI Privacy and Data Protection Policy states that CometAPI does not collect, store, or record model prompts, inputs, outputs, or conversation content and does not save model communications to its servers or databases. It also says the policy may change, which is a reason to attach a review date to the gateway row.
• OpenAI’s Data controls in the OpenAI platform says API data is not used to train or improve OpenAI models unless a customer explicitly opts in. It describes abuse-monitoring logs that may contain prompts and responses and are retained for up to 30 days by default, endpoint-specific application state, and approval-dependent retention controls.
• Anthropic’s Data usage documentation for Claude Code says commercial use, including API and third-party-platform use, is not used for generative-model training unless the customer opts in. It documents a standard 30-day commercial retention period, qualified zero-data-retention availability, and default local plaintext transcript storage for Claude Code clients for 30 days.
• The Gemini API Additional Terms of Service distinguishes unpaid from paid services. The terms say unpaid-service content and responses may be used to improve products and may be reviewed by people, while paid-service prompts and responses are not used for product improvement but may be logged for a limited period for safety, security, and required disclosures.

These sources are independently useful because each covers a different layer or provider policy. None should be stretched into evidence for a route, account class, or feature it does not explicitly cover.

Contract details to verify

Start with a row for each exact route tuple. Do not create one broad row named approved AI providers. A useful matrix records the following evidence boundaries:

Add these control fields to every row:

• An immutable internal route alias and the exact model identifier it resolved to at approval time.
• The provider policy class and service tier, including whether a conditional retention control has actually been approved and enabled.
• Allowed data classes and an explicit list of prohibited classes.
• Training treatment, monitoring-retention window, application-state behavior, cache behavior, and deletion behavior as separate fields.
• Feature exceptions for files, conversation state, background work, feedback, grounding, or other tools used by the agent.
• Local-client storage location, retention period, cleanup owner, and whether transcript sharing is enabled.
• Public evidence labels, retrieval dates, internal approval owner, next-review date, and row status.
• A fallback policy that names approved alternates rather than permitting any available model.

Your organization should define its own data classes. A workable baseline is public for already published material, internal for nonpublic operational context, confidential-source for proprietary code and designs, and restricted for regulated data, customer records, production secrets, or other material requiring formal approval. Default restricted data to deny unless a specifically reviewed route and workflow permit it.

A row should move to review-required when its evidence expires, its model mapping changes, a service tier changes, a new endpoint feature is enabled, or a provider announces a policy update. Keep the prior decision record for auditability, but do not let stale approval authorize new requests.

Failure modes

1. Treating gateway non-storage as end-to-end zero retention. This collapses gateway and provider layers into one claim. Keep separate columns and require evidence for both.
2. Equating no training with no storage. OpenAI, Anthropic, and Google describe training treatment separately from monitoring or operational retention. A no-training answer cannot populate the retention fields.
3. Losing the service-tier distinction. Google documents materially different unpaid and paid treatment, while OpenAI and Anthropic describe controls that depend on approval or account qualification. An unknown tier must produce a denial.
4. Allowing alias drift. A friendly alias can outlive the model mapping used during review. Bind approval to the resolved route tuple and invalidate the row when that tuple changes.
5. Letting fallback bypass policy. A timeout may send the same repository context to an unapproved provider. Re-run classification and matrix lookup before every fallback attempt.
6. Ignoring feature-specific state. A base completion request, stored conversation, file feature, cache, feedback submission, or background operation may not have identical persistence behavior. Record the exact feature set.
7. Forgetting local copies. Anthropic documents local Claude Code transcripts stored in plaintext by default for a defined period. Gateway policy cannot remove a transcript already written by the client.
8. Turning observability into a shadow archive. Full prompts, outputs, paths, and repository names in logs create another sensitive copy. Log policy decisions and coarse size buckets instead.
9. Keeping evidence forever. Public policies change. Rows without an expiry and event-driven revalidation become silent sources of policy drift.
10. Retrying an unknown denial. Automatic retries do not resolve missing evidence. A stable policy denial should stop the run and route the issue to the row owner.

FAQ

Is CometAPI’s public privacy policy enough to approve confidential code?

It is direct evidence for the gateway-layer statements it makes. Approval for confidential code still needs the applicable upstream-provider, service-tier, endpoint-feature, local-client, and organizational requirements. Your legal and security owners should decide whether public policy evidence is sufficient for each layer.

Does no model training mean prompts are immediately deleted?

No. The checked provider documents distinguish training use from abuse monitoring, safety logging, application state, or standard retention. Keep these as separate matrix fields.

Should the matrix have one row per model?

Use one row per exact route tuple: gateway route, model identifier, provider policy class, service tier, endpoint features, and relevant local-client behavior. Two requests to the same model family can require different rows if any of those conditions differ.

Should audit logs store the prompt so reviewers can reproduce the decision?

Not by default. Store the data classification, route tuple, policy version, decision, reason code, evidence date, and a coarse content-size bucket. If raw-content retention is genuinely required, treat it as a separate approved data system with its own access and deletion controls.

How often should the evidence be reviewed?

Choose a scheduled interval that fits your risk process and also trigger review on route, model, tier, feature, contract, or public-policy changes. The important control is that evidence expires rather than remaining approved indefinitely.

What should happen when one field is unknown?

Return a deterministic denial such as RETENTION_POLICY_UNKNOWN, transmit no repository content, and disable automatic fallback unless another route independently passes the same gate. Unknown is an evidence gap, not permission.

Reader next step

Create the first matrix row with synthetic, non-sensitive context. Implement the deny rule before the allow rule, test a known approved route, then change its model mapping and confirm that preflight blocks the request. Use the model-gateway setup guide to make route identities explicit, and review prompt-caching boundaries across models before treating cache behavior as settled.

Once the matrix, sanitized event, and error path work with synthetic inputs, Start with CometAPI and validate only the routes your policy explicitly allows.