Retention gap

What mcp-scan saw

This runs only after data-controls-pii fired. The scanner then searched the lowercased serialized server config for ttl, expire, cleanup, retention, auto-delete, 'auto delete', or purge. None present means this finding. Substring matching over the whole JSON, so an env key such as CACHE_TTL counts as evidence.

Why it fires

Data with no retention bound accumulates for the life of the deployment, which turns a small exposure into a large one over time. The config is the only surface the scanner has, so it treats the absence of any retention vocabulary as the absence of a policy, and grades it MEDIUM because the failure is gradual rather than immediate.

When this is a false positive

• The server holds nothing across calls. A stateless server has no retention window to configure, and no reason for the word ttl to appear in its config.
• Retention is enforced by the storage layer: an S3 lifecycle rule, a database partition drop, or a managed service's own policy. None of those appear in a client config.
• The gate rule may have been a keyword match. If data-controls-pii fired on 'api_key' in a description, there is no retained personal data for this gap to describe.

How to fix it

1. Read the data-controls-pii finding to confirm whether any real data is retained.
2. If nothing is retained, this is not actionable. Fix the gate rule instead.
3. If data is retained, set an explicit window and express it in the config, for example a CACHE_TTL or RETENTION_DAYS env var. That both satisfies the check and makes the policy visible.
4. Where retention lives in the storage layer, document which rule enforces it so the next reviewer does not have to rediscover it.
5. To suppress the whole family for one server, add its config key to .mcp-scan-ignore.