Known gaps in 0.6.0

Section 18 · From docs/MCP_PRIVACY.md on GitHub

These are behaviours of the current code that a policy author should know about. Each was reproduced against the code while writing this document; the earlier list of problems (alias ordering, names under asset_name and relation keys, completions, mangled strategy tables, the projection budget, audit_size: 0, vault saving, unaudited refusals and hidden calls, PolicyConfig with extends, embedded resources, the collector categories, the echoed token field) has been fixed.

1. strict still lets some names and identifiers through. The key rules cover asset-like objects, relation and finding references, URIs and dataset names, and the name-mention pass rewrites names that were pseudonymised elsewhere in the same result. What remains:

   • organization_topology: account and OU display names (name without asset-like siblings), the organization id (o-...), OU ids (ou-...) and the names in ou_path. Twelve-digit account ids are caught by the content detector.
   • Dependency results (depends_on, dependents, blast_radius): the parent_id of each tree node keeps the real asset id.
   • ontology_neighbourhood: the asset object (it has only id, name and type, so the asset-like sibling condition fails) and the triples' subject, object, subject_id and object_id, which also embed tag keys and values in IRIs such as cmr:tag_owner_web-team.
   • rag_chunks: the chunk content text (Resource: <name>, relation lines) and chunk_id (entity::<asset id>). Names inside free text are only replaced when the same result also carries them under a key rule.
   • Free text with no space, comma or ->, such as a one-node attack path whose summary is just a name, is skipped by the name-mention pass.

   With readable asset ids (as in the test estate) these expose names; with real UUID ids the parent_id, subject and chunk_id values expose only ids. Account numbers made of one repeated digit (111111111111) are treated as placeholders by the content detector and are only caught under account keys. 2. The generic pipeline does not apply the alias reordering. _generic_pipeline in cloudg/mcp/policy.py builds the policy's own transforms without moving alias or substitute steps after redact. With transforms: [{type: alias, ...}, sanitize, {type: redact, ...}], preview_transform without a tool returned {"arn": "arn:aws:ec2:us-east-1:prod:instance/i-0abc1234def567890", "account_id": "acct-b7955d8854"} while the tool pipeline returned {"arn": "arn:aws:ec2:us-east-1:prod:instance/i-ccc5e66b39a18abd0", "account_id": "prod"}. Only policies that list an alias before redact in their own transforms are affected (rule transforms are not part of the generic pipeline); privacy_status and list_detectors use the same pipeline. 3. The content_annotations hints (audience, priority) are only written to the transform report, not onto the MCP content items. 4. Custom key rules cannot set defer, so they always apply their own entity even when a detector matches the whole value. 5. A vault with a path is saved at shutdown and at interpreter exit, but not when the process is killed with SIGKILL or crashes hard. Set autosave: true if that matters. 6. Pseudonyms of public CIDRs and of the public addresses inside them are not consistent, and a real private address that equals an issued pseudonym is read back as the value it stands for (section 13.7).