> ## Content Index
> Fetch the complete content index at: https://www.ostering.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# ♣ Clubs: Privacy

- URL: https://www.ostering.com/taxonomies/ai-agentic-systems/eoa-privacy/
- Published: 2026-11-05T21:00:00.000Z
- Updated: 2026-11-05T20:37:23.239Z
- Description: Privacy threats to AI and agentic systems: 5 Elevation of Autonomy cards with prompts, mitigation principles, design measures and mappings.
- Author: Brett Crawley

[Taxonomies](https://ostering.com/taxonomies/) / [AI and Agentic Systems Threat Taxonomy](https://ostering.com/taxonomies/ai-agentic-systems/) / Clubs

# ♣ Clubs: Privacy

Privacy threats from T.R.I.M. and LINDDUN, framed for systems that generate personal data as well as process it: transfer, retention and removal, inference, minimisation and unintervenability.

This suit has 5 cards, EOA·CA to EOA·C10. In the game, high ranks (Ace, King) are the broader or more foundational threats and low ranks the more specific or variant ones; in the taxonomy the ID is a stable reference, not a severity. Each entry gives the card's threat and mitigation prompts, the mitigation principle a sound design follows, design measures, and mappings.

![Clubs at a glance: each card's ID, title, quote, threat and mitigation principle. The full text is below and in the downloads.](https://www.ostering.com/media/posts/128/ai-agentic-systems-privacy-taxonomy-table2x.png =3000x2306)

## The entries

<a id="eoa-ca"></a>
### EOA·CA Transfer

> *“The model creates personal data at the point of transfer.”*

**Threat.** The model manufactures personal data that is then transferred to a downstream system, log, or onward recipient. The data has no provenance and no consent chain.

**Mitigation prompts** (from the card)

- Does the data carry provenance tags?
- Can downstream consumers distinguish generated from collected data?
- Is onward transfer logged?

**Mitigation principle.** Mark generated personal data as generated, and transfer it only where a recipient can tell it apart from collected data.

**Design measures**

- Tag every record and field the model produces with its provenance (generated, retrieved, collected) and carry the tag through transfers.
- Make downstream schemas store generated personal data separately from collected data, or reject it.
- Log every onward transfer of personal data from model output: what, to whom and on what basis.
- Include model-generated data in the record of processing and in transfer impact assessments.

**Mappings**

- STRIDE: I
- LINDDUN: Data disclosure, Non-compliance
- Card references: T.R.I.M. Transfer. GDPR Article 5(1)(a), 5(1)(b).
- MITRE ATLAS: none
- CAPEC: none
- CWE: none

**Touches:** [EOA·DQ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-dq) Hallucinated Facts, [EOA·CK](#eoa-ck) Retention and Removal, [EOA·HJ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-autonomy/#eoa-hj) Cascading Failure

<a id="eoa-ck"></a>
### EOA·CK Retention and Removal

> *“Fabricated data persists the same as real data.”*

**Threat.** Personal data (real or hallucinated) is persisted in RAG, memory, logs, or fine-tuning datasets without a mechanism for surgical removal. Article 16 and Article 17 rights become unenforceable.

**Mitigation prompts** (from the card)

- For each persistent store: can you locate a specific individual's data?
- Can you delete it?
- Can you prevent recurrence?

**Mitigation principle.** Design every persistent store the system writes to for locating, deleting and suppressing one person's data.

**Design measures**

- Index personal data by data subject across RAG, memory, logs, caches and training sets, so one person's data can be found.
- Support deletion in each store, with a retention period, and keep personal data out of fine-tuning sets unless it can be removed and the model retrained.
- Add a suppression list applied at output for corrections and erasures that cannot be removed from model weights.
- Test the process end to end with synthetic subject access and erasure requests.

**Mappings**

- STRIDE: I
- LINDDUN: Non-compliance, Unawareness and unintervenability
- Card references: T.R.I.M. Retention. GDPR Articles 16, 17.
- MITRE ATLAS: none
- CAPEC: none
- CWE: none

**Touches:** [EOA·SJ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/#eoa-sj) Memory Poisoning, [EOA·C10](#eoa-c10) Unintervenability, [EOA·DK](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-dk) Vector and Embedding Weakness

<a id="eoa-cq"></a>
### EOA·CQ Inference

> *“The model derives personal data you never collected.”*

**Threat.** The model infers new personal data (including special-category data under Article 9) from partial or unrelated inputs. The act of inference is itself the privacy event.

**Mitigation prompts** (from the card)

- What does the model infer about people that it was not told?
- Does it ever touch special categories?
- What is the lawful basis for inferred data?

**Mitigation principle.** Do not let the system infer facts about people that it has no lawful basis to hold, and never special categories by default.

**Design measures**

- Constrain outputs about identifiable people to retrieved, authoritative facts (refuse-or-ground); no free-form biographical detail.
- Detect and block special-category inferences (health, religion, sexual orientation, political views and the like) at output.
- Record which inferences the product relies on and the lawful basis for each in the DPIA.
- Exclude inputs from the context that enable sensitive inference and that the task does not need (calendars, location history, free-text notes).

**Mappings**

- STRIDE: I
- LINDDUN: Identifying, Linking
- Card references: T.R.I.M. Inference. GDPR Article 9. LINDDUN Identifying.
- MITRE ATLAS: none
- CAPEC: none
- CWE: none

**Touches:** [EOA·CJ](#eoa-cj) Minimisation, [EOA·DA](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-da) Sensitive Information Disclosure, [EOA·C10](#eoa-c10) Unintervenability

<a id="eoa-cj"></a>
### EOA·CJ Minimisation

> *“You minimise what you collect. Now minimise what you generate.”*

**Threat.** The model generates more personal data than the task requires, producing unrequested claims that are both unminimised and hallucination-prone.

**Mitigation prompts** (from the card)

- Is the input minimal for the task?
- Is the output minimal?
- Are output schemas constrained to what was asked?

**Mitigation principle.** Apply data minimisation to what the model generates as well as to what the system collects.

**Design measures**

- Constrain output to a schema that has only the fields the task needs, with no free-text field for personal data.
- Minimise the input: pass identifiers or redacted text rather than whole records where the task allows.
- Cap response length for tasks that need short answers.
- Strip personal data from outputs that do not need it before they are stored or sent.

**Mappings**

- STRIDE: I
- LINDDUN: Data disclosure, Non-compliance
- Card references: T.R.I.M. Minimisation. GDPR Article 5(1)(c).
- MITRE ATLAS: none
- CAPEC: none
- CWE: [CWE-201](https://cwe.mitre.org/data/definitions/201.html) Insertion of Sensitive Information Into Sent Data

**Touches:** [EOA·CQ](#eoa-cq) Inference, [EOA·DQ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-dq) Hallucinated Facts, [EOA·CA](#eoa-ca) Transfer

<a id="eoa-c10"></a>
### EOA·C10 Unintervenability

> *“The subject cannot find out, cannot correct, cannot prevent recurrence.”*

**Threat.** Data subjects have no practical mechanism to discover what the system claims about them, no route to correct it, and no assurance that corrections persist.

**Mitigation prompts** (from the card)

- Is the processing disclosed in the privacy notice?
- Is there a subject access process that covers model outputs?
- Do rectifications persist across sessions?

**Mitigation principle.** Give people a working route to find out what the system says about them, correct it, and keep it corrected.

**Design measures**

- Disclose the AI processing, including generated and inferred data, in the privacy notice.
- Extend the subject access process to model outputs, memory, logs and RAG stores.
- Make rectification persistent: corrections stored in the system of record and applied at retrieval and output in every later session.
- Give people affected by a decision a route to human review, and record each request and its outcome.

**Mappings**

- STRIDE: R
- LINDDUN: Unawareness and unintervenability, Non-compliance
- Card references: LINDDUN Unawareness/Unintervenability. GDPR Articles 13, 14, 16.
- MITRE ATLAS: none
- CAPEC: none
- CWE: none

**Seen in the wild.** noyb filed a complaint with Norway's data protection authority after ChatGPT falsely described a Norwegian man as having murdered his children, mixing in real details of his life; noyb argued OpenAI offered no way to correct the output. March 2025. Source: [OpenAI faces European privacy complaint after ChatGPT allegedly hallucinated man murdered his sons (Euronews)](https://www.euronews.com/2025/03/20/openai-faces-european-privacy-complaint-after-chatgpt-allegedly-hallucinated-man-murdered-).

**Touches:** [EOA·CK](#eoa-ck) Retention and Removal, [EOA·T1](https://ostering.com/taxonomies/ai-agentic-systems/eoa-structural-hazards/#eoa-t1) Wrong Abstraction, [EOA·CA](#eoa-ca) Transfer

## Mappings at a glance

![Mappings for Clubs: STRIDE, the card's references, MITRE ATLAS, CAPEC and CWE for each entry. The full text is above and in the downloads.](https://www.ostering.com/media/posts/128/ai-agentic-systems-privacy-mapping-table2x.png =3000x1644)

STRIDE across this suit: Repudiation 1, Information disclosure 4. 0 of 5 entries map to MITRE ATLAS, 0 to CAPEC and 1 to CWE.

## Where this suit touches the others

- **[Diamonds: Data](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/)**: EOA·CA with [EOA·DQ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-dq); EOA·CJ with [EOA·DQ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-dq); EOA·CK with [EOA·DK](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-dk); EOA·CQ with [EOA·DA](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/#eoa-da).
- **[Hearts: Autonomy](https://ostering.com/taxonomies/ai-agentic-systems/eoa-autonomy/)**: EOA·CA with [EOA·HJ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-autonomy/#eoa-hj).
- **[Spades: Adversarial](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/)**: EOA·CK with [EOA·SJ](https://ostering.com/taxonomies/ai-agentic-systems/eoa-adversarial/#eoa-sj).
- **[Trumps: Structural Hazards](https://ostering.com/taxonomies/ai-agentic-systems/eoa-structural-hazards/)**: EOA·C10 with [EOA·T1](https://ostering.com/taxonomies/ai-agentic-systems/eoa-structural-hazards/#eoa-t1).

Previous: [♦ Diamonds: Data](https://ostering.com/taxonomies/ai-agentic-systems/eoa-data/) · [Overview](https://ostering.com/taxonomies/ai-agentic-systems/) · Next: [★ Trumps: Structural Hazards](https://ostering.com/taxonomies/ai-agentic-systems/eoa-structural-hazards/)

---

*AI and Agentic Systems Threat Taxonomy v1.0, the reference for the Elevation of Autonomy card deck. © 2026 Jonathan Brett Crawley. Licensed under [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) with additional permissions: see the [licence](https://ostering.com/taxonomies/ai-agentic-systems/#licence).*
