> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getunbound.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Data Retention and Deletion
> How long Unbound keeps what it records, what expires on its own, and what you can delete yourself
Unbound records what your AI tools do so you can read it later — a prompt from three months ago, the command that was blocked in April, the MCP call behind an incident. Very little of it expires on a timer.
This page states what that means, so you can answer a security review from it.
## The short version
**Nothing in the product expires your activity data with age.** Prompts, terminal commands, MCP tool calls, task rows, analytics, discovery inventory, policy decisions, spend records and webhook delivery history have no retention window. They stay available until you delete the object they belong to. One derived rollup is the exception, noted below.
**Five things do expire on their own:**
| What | How long |
| -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A generated **export file** | **6 hours** after it finishes, then the file is deleted and the export must be run again |
| A device's **install report**, once it has finished processing | **5 days** after it arrived, for reports that completed or failed. One still pending or in flight is not deleted |
| A parked **telemetry span** from a tool that exports them, such as Copilot | Deleted once it is matched to the activity row it fills. One that never matches is turned into a usage row of its own after **18 hours**, and deleted then. A parked span carries ids, token counts, a model name and two timestamps — never prompt text |
| A **discovered tool** that stops being reported | Marked removed, and kept as history rather than deleted |
| The derived **Observed Autonomy** figure | Derived from a rolling **30-day** window and refreshed daily. A device with no activity in the window drops out of the figure. The activity records it is derived from are untouched |
Those five are what the product itself applies. The storage behind exports and parked telemetry carries its own lifecycle rules; if a review needs a stated figure for those, ask support and we will put it in writing.
## What you can delete yourself
| Delete | And this goes with it |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A **webhook endpoint** | Its entire delivery history, including the payload of every attempt |
| A **saved query** | The query. Charts built from it elsewhere stop resolving |
| A **dashboard** | The dashboard. The queries on it survive |
| A **user group** | The group and its memberships. Mind the policies: a policy scoped *only* to that group is left with no scope, and a policy with no scope is org-wide — so re-scope those before you delete the group |
| A **provider API key** | The stored credential |
| An **integration connection** | The stored credential, and any further sync |
A **policy** you delete stops applying immediately and leaves the list, and the record of what it did while it was live stays in your analytics and logs — so deleting a policy does not erase the evidence of an action it blocked.
**Disconnecting an integration removes the credential, not the data.** Removing the Anthropic connection stops further imports; the claude.ai chats already imported remain in Logs. Removing an MDM connection stops serial lookups; the devices already attributed stay attributed. Treat disconnecting as revoking access, not as a delete.
## Where the sensitive content actually sits
Prompt and command text is the part a reviewer will ask about. It lives in three places:
| Place | Behaviour |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Logs and Analytics** | Kept. This is the record you bought |
| **A generated export** | Carries prompt text. Deleted after **6 hours** rather than left in storage |
| **A webhook payload** | Events carry the prompt that led to an action. Your receiver holds its own copy, on your retention terms, and Unbound's copy goes when you delete the endpoint |
Every delivery carries the payload documented on [Webhooks](/integrations/webhooks). Where a receiver is out of scope for your retention policy, narrow what reaches it: subscribe it to the per-action events rather than `*.logged`, and point it at a destination whose retention you control.
## Closing an organization
Unbound can deactivate an organization on request: access is revoked, and traffic stops being accepted and recorded. That is a support operation, not a dashboard control, so it cannot happen by accident and can be confirmed in writing.
Purging the data already recorded is a separate request, handled the same way. Email [support@unboundsecurity.ai](mailto:support@unboundsecurity.ai) from an Admin account on the organization and say which of the two you need.
If your obligations require a fixed retention window — 90 days, a year, anything — say so to support rather than assuming one applies. There is no per-organization retention setting in the product today.
## Related
| Page | For |
| ---------------------------------- | ------------------------------------------------------------------ |
| [Webhooks](/integrations/webhooks) | What each event carries, and deleting an endpoint with its history |
| [Exports](/cli/exports) | The 6-hour window on a generated file |
| [Settings](/dashboard/settings) | Connecting and removing integrations |