> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data retention, deletion & export

> What KAOP keeps as operating history, what archive and deletion mean, and how to request an account-level export or deletion.

The Komodor Agentic Operation Platform (KAOP) keeps the records needed to explain what an agent saw,
what it did, and who changed its operating boundaries. Retention preserves that evidence for review;
archiving, deleting a configuration object, and deleting an account are different operations with
different effects.

## What is retained

| Record                | Why KAOP keeps it                                                                                           |
| --------------------- | ----------------------------------------------------------------------------------------------------------- |
| **Runs and evidence** | To reconstruct an execution from its input through its tool and model calls to its output, status, and cost |
| **Chats**             | To preserve the conversation and the runs created from it                                                   |
| **Audit entries**     | To show governed changes, sensitive reads, rejected attempts, and the identity responsible                  |
| **Approvals**         | To show which proposed action was approved or rejected, by whom, and when                                   |

These records can contain customer data. Prompts, inputs, tool arguments and results, logs,
messages, outputs, and artifacts are retained as the worker reports them. Stored secret values are
masked before that evidence leaves the worker, but general personal or sensitive data is not
automatically classified. See
[Data handling & redaction](/security-and-governance/architecture-considerations/data-handling-redaction)
before deciding what an agent may read or emit.

Retention periods are not configured from the KAOP console. For the retention terms that apply to
your account or deployment, contact your Komodor representative.

## Archive is not deletion

Archiving an agent retires it from active use without erasing its history. Existing runs and evidence
remain available so an earlier conclusion does not lose its context. You can review archived agents
separately from the active fleet and restore one when needed.

The same distinction applies to access. Revoking an API key, worker token, or credential prevents
future use; it does not rewrite records that show how the identity or credential was used before it
was revoked.

<Note>
  An append-only audit log cannot be edited or selectively cleared from the console. Its entries
  remain immutable while retained; expiry under the applicable retention policy and account-level
  deletion are lifecycle operations, not edits to individual entries.
</Note>

## Export account data

KAOP does not expose a self-service, whole-account export in the console. To request one, contact
your Komodor representative and include the account id from **Settings → Account**. State what you
need exported and the reason or date range that defines the request; Komodor will confirm the
available scope and delivery method.

The runs API and OpenTelemetry export serve narrower operational use cases. They let you read run
records or send new telemetry to your own backend, but they are not a substitute for an
account-level data export.

## Delete data

Delete individual configuration objects from their own product page or API where KAOP offers that
action. Some objects are archived instead because their historical relationship to runs and audit
records must remain understandable.

Account-level deletion is not self-service. Request it through your Komodor representative and
include the account id. Komodor will confirm the scope and next steps before the account and its
tenant data are removed.

<Warning>
  Account deletion is irreversible. Request any export you need before asking for deletion, and do
  not send credentials, API keys, worker tokens, or other secret values with the request.
</Warning>

## Next steps

<CardGroup cols={2}>
  <Card title="Data handling & redaction" href="/security-and-governance/architecture-considerations/data-handling-redaction">
    Which run fields can contain customer data and what is masked automatically.
  </Card>

  <Card title="Audit log" href="/security-and-governance/controls/audit-log">
    The immutable record of governed actions while each entry is retained.
  </Card>

  <Card title="Runs & evidence" href="/manage-your-agents/run/runs-evidence">
    Read the execution record stored for a run.
  </Card>

  <Card title="Support" href="/reference/support">
    What to include when you contact Komodor.
  </Card>
</CardGroup>


## Related topics

- [Data handling & redaction](/security-and-governance/architecture-considerations/data-handling-redaction.md)
- [Audit log](/security-and-governance/controls/audit-log.md)
- [Support](/reference/support.md)
- [Observability & OTel export](/manage-your-agents/optimize/observability-otel-export.md)
- [Observability Cost](/modules-and-workflows/cost-optimization/observability-optimization.md)