GUIDE · 03 OF 03App. A–C · §1–§12 · pp. 8–105 · 46 terms
Glossary
TL;DR — The report uses ordinary words in narrow senses. "Context" means a social domain like healthcare, not the model's context window. "Privacy" means appropriate information flow, and "security" covers every other action. A norm has five parameters, and the transmission principle carries most of the weight. Most of the report's own coinages name open problems, not working mechanisms.
The report spends real effort on vocabulary. It argues that drift in how people describe Contextual Integrity has produced work only loosely tied to the theory (§4.1), so it puts a glossary in Appendix A, separates four senses of "context" in Appendix B, and lists CI's known weak spots in Appendix C. This page collects those terms, adds the agent basics from Part I, and adds the phrases the report coins along the way. Each entry is in our words, cites where the report defines it, and links the page of this map that uses it. For CI terms the authoritative, current source is privaci.info/glossary, which the report itself points to.
Contextual Integrity terms (Appendix A)
Appendix A is the report's attempt to pin down CI vocabulary, because it argues that loose use of these words has produced benchmarks only weakly tied to the theory (§4.1). The appendix credits the definitions to Nissenbaum and Shvartzshnaider and points to privaci.info/glossary as the full, up-to-date version (App. A, footnote 10, p. 100). Treat that site as the living reference; what follows is a working engineer's paraphrase.
| Term | In plain words |
|---|---|
| Context (social domain, sphere) | A recognizable area of social life, such as healthcare, school, commerce or family, defined by what it is for, who plays which roles, how power is arranged, and what rules people follow there. It is an abstraction, not a specific room, app, platform or industry. Unless the report says otherwise, "context" means this. |
| Norm | A rule of behavior, whether written down (law, a professional code) or simply what nearly everyone does. Norms can be ethical, aesthetic, formal or informal, and can stand alone or sit inside a larger rule system. Defined: App. A.2, p. 100 · Used in: Contextual Integrity |
| Contextual informational norm | A norm about personal information moving between parties: who may send what, about whom, to whom, under what condition. Also called an informational norm, privacy norm or CI norm. A complete one fills in all five parameters. Whether a norm exists is an empirical question; whether it is legitimate is a separate one (see legitimacy below). |
| Personal information | Any information about a person. Where it came from does not matter: the person said it, someone else said it, or a model inferred it. Defined: App. A.3, p. 100 · Used in: Contextual Integrity |
| Contextual information flow | One concrete movement of information from one actor to another. To describe it properly you name all five parameters, using the roles and information types of the context it happens in. Defined: App. A.4, p. 100 · Used in: Contextual Integrity |
| CI parameter (the CI-tuple) | The five slots of a norm or a flow: three actors (sender, recipient, data subject), the attribute (information type), and the transmission principle. The report calls the filled-in five the CI-tuple and uses it both to describe a flow and to state what should happen. |
| Actor | Shorthand for the three party slots: sender, recipient, data subject. The values are roles (teacher, doctor), and can be organizations or governments. A person or an agent counts as an actor only insofar as it is acting in one of the context's roles. Defined: App. A.5.2, p. 101 · Used in: Contextual Integrity |
| Contextual role (capacity) | A position in a context that comes with functions, expectations and responsibilities. Contexts have no fixed number of roles, and roles change, vanish and appear over time. Defined: App. A.5.3, p. 101 · Used in: Shared norms, delegation, composition |
| Information (data) type / attribute | What the information is about: its meaning, not its format. A diagnosis, a grade, a bank balance. Each context has its own vocabulary of types. Appendix C flags a known weakness here: the same fact means different things depending on what else it is combined with, and granularity can matter as much as category. |
| Transmission principle (TP) | The condition under which a flow is allowed: with consent, in confidence, reciprocally, with notice, as required by law, with a warrant. TPs are not tied to any one context. Appendix C notes that although TPs carry most of CI's normative weight, the original theory offers no clean list of them; one proposed refinement (GKC-CI, which the report cites) splits a TP into aims, conditions, modalities and consequences. |
| Privacy expectation | The US legal idea of a "reasonable expectation of privacy", meaning a widely shared expectation. CI links it to informational norms: a norm is, as a matter of fact, a commonly held view about which flows are appropriate. The report leans on this link when it discusses where norms come from (§12). Defined: App. A.6, p. 101 · Used in: Governance |
| Contextual integrity | The state of affairs CI aims for: flows respect justified norms, or, where they depart from them, they still serve and do not undermine the context's purposes and values. Privacy, in this theory, is appropriate flow, not secrecy and not individual control. |
| Contextual values (ends, purposes) | Why a context exists at all: health for healthcare, learning for education. Everything else (roles, norms, practices) is organized around these, and a norm is legitimate to the extent it advances them. That also means an entrenched norm can be beaten by an alternative that serves the purpose better. |
| Contextual functions, practices, activities | The behaviors that are normal or expected in a context, either through habit and culture or because they serve the context's higher goals. Defined: App. A.7.2, p. 102 · Used in: Contextual Security |
| Legitimacy of informational norms | An entrenched norm is presumed legitimate, but only presumed. To be justified it has to pass three tests: a fair balance of wellbeing among the affected parties, consistency with core ethical and political principles, and support for the context's ends and values. |
| Contextual ontologies | The vocabularies of roles and information types a context uses. Each context has its own, though roles and categories overlap across contexts. The report's tension (App. C): extending CI to agents pulls toward new vocabulary, while meaningful evaluation needs a standard one. Defined: App. A.7.4, p. 102 · Used in: Policy engines, OP 6.3 |
| CI heuristic (decision heuristic) | A procedure for judging a new system: describe its flows as five-parameter tuples, identify the context, and compare against existing norms. Conforming flows are fine. A breach is a presumptive violation. If no norm covers the flow, you have a gap. Breaches and gaps go through three further evaluations: effects on the affected parties, effects on broad moral and political principles, and effects on the context's own purposes. Ambiguous results call for more data, more deliberation, or keeping the status quo. |
Four meanings of "context" (Appendix B)
The word does four jobs in this field, and the report insists they not be confused (§4.1.1, App. B, p. 103). Its Figure 3 draws them as nested layers, explicitly not a Venn diagram: the model context sits inside the system context, which is deployed into a physical situation, which may operate inside a social context. Only the last one is where CI locates privacy norms.
"In this paper, the default meaning of context is social domain, per CI. Other uses will be signaled with qualifiers."— the report, §4.1.1, p. 16
| Term | In plain words |
|---|---|
| Model context | Whatever unstructured material the model can see right now when generating output: instructions, conversation, retrieved content, tool outputs, in-context memory. Bounded by the context window. Orchestration that swaps the model context repeatedly (sometimes called multi-agent reasoning) is, in the report's framing, a system-level workaround for a model-level limit. |
| System context | Information the agent system can reach beyond the current window: memory, knowledge bases, pipelines, tools. §2.1 describes it as short-term history plus longer-term distilled memories. Both model and system context describe the software, not the world. |
| Physical context (situation) | The concrete deployment environment: devices, infrastructure, physical surroundings. The report traces this sense to early "privacy in context" work, with a building's heating and lighting controller as the prototype, and notes that Benthall et al. (2017) call it a situation. Defined: App. B, p. 103 · Used in: Contextual Integrity |
| Social context (sphere) | CI's sense: an established field of social activity with shared purposes and norms, understood abstractly in terms of goals and values. It lives outside the software. The report's framing of the whole agentic privacy problem is aligning system behavior with this layer, partly by representing it in the system context, while warning that norms written down as policies may not be enough, because privacy has to be enacted in behavior. |
Agent and system terms
These are the report's own working definitions from Part I. It gives its own definition of "AI agent" in §1.1, p. 8, refines it in §2.1, and notes in a footnote that many other definitions exist. Our reading: it is deliberately broad, so the same terms cover a simple email-to-calendar tool and a self-evolving agent. System context, which §2.1 lists as an agent component, is defined with the other senses of context above.
"A trustworthy agentic system must provide utility while acting appropriately under both benign and adversarial conditions."— the report, §1.1, p. 8
| Term | In plain words |
|---|---|
| AI agent | Something that (i) accepts unstructured inputs and instructions, (ii) uses a model, usually an LLM, to plan a response on the fly, and (iii) carries it out by calling tools or APIs, talking to people, or dealing with other agents. Often has memory, skills and a sandbox. A general-purpose one moves across many social contexts. |
| Agentic system | Any software system that uses one or more AI agents. Defined: §1.1, p. 8 · Used in: Three dimensions |
| Trustworthy agentic system | One that delivers three properties under both attack and ordinary operation: utility (does the task reliably), privacy (information-sharing actions are appropriate), security (non-sharing actions cause no harm). Note the split: the report assigns information-sharing to privacy and everything else to security. Benign failures such as hallucination or misread instructions count, not only attacks. Defined: §1.1, p. 8 · Used in: Three dimensions |
| Harness | The developer-written software between the model and the world: it passes messages to and from the model and executes the tools. Defined: §2.1, p. 10 · Used in: AI as the last-mile developer |
| Policy engine | In §2.1, an optional harness component that enforces desired behavior, for example input and output filters. §6.4 sharpens this into the contextual policy engine (below). Defined: §2.1, p. 10 · Used in: Policy engines |
| Agent harm | An action by an agent, such as sharing data or changing state, that goes against the interests of some party: the user, the model or harness developer, or a third party. Harm is always relative to a party. An agent attack is whatever produces one. The report's footnote notes a fuller definition would weigh harms and benefits to everyone affected. Defined: §3, p. 12 · Used in: Three dimensions |
| Indirect prompt injection | Instructions an adversary plants in content the agent processes (a web page, a document, a tool output) that steer it toward the adversary's goals: exfiltration, policy bypass, tool misuse, manipulated output. Two points the report stresses: the injected task often runs alongside the user's task, so finishing the task proves nothing; and what defines an injection is that it did not come from a direct input source like the user or developer, not that external instructions are inherently bad. One reframing the report cites treats injections as inputs that flip the model's judgment of what is appropriate, in either direction. Defined: §3, p. 13 · Used in: Three dimensions |
The report's coinages and key phrases
Terms the report introduces, adopts from cited work, or uses as handles for an open problem. Several are named in a single sentence and left open; where that is the case the entry says so. None of these are settled mechanisms.
| Term | In plain words |
|---|---|
| Contextual security | CI stretched from personal information to all behavior: enforcing appropriate actions (personal flows, non-personal flows, and actions that are not flows at all) that serve the context's purposes. The key move: a system is not secure just because it enforces its own specification. If the boundary it enforces violates social norms, it is contextually insecure. The report notes other works also use the term for agents and that its own version is the CI-grounded one (§5.3). Defined: §5, p. 19 · Used in: Contextual Security |
| Contextual behavior norm | The behavioral counterpart, and superset, of a privacy norm: a legitimate boundary on what may be done in a context. The open part is which parameters describe a behavior; a behavior like constructing a building has no data subject or attribute. Defined: §5, OP 5.1, p. 19 · Used in: OP 5.1 |
| Contextual security norm | A pair: the system's functionality plus its security goal, both judged appropriate against an accurate threat model for the context. How to derive and judge the pair is OP 5.3. Defined: §5.2, OP 5.3, p. 21 · Used in: OP 5.3 |
| Contextual policy engine | A design pattern the report names after seeing it across several systems. Two jobs: generate a formal, machine-checkable policy from context and norms (escalating to the user when it cannot), and enforce it at runtime by allowing, denying, modifying or escalating each proposed action. Keeping it separate from the planner model is what lets designs like Conseca, which the report cites, stop untrusted inputs from influencing policy generation. The report is explicit that no standard policy language exists and the ideal architecture is open. Defined: §6.4, p. 26 · Used in: Policy engines, OP 6.4 |
| Intent-execution separation | A term the report borrows from IETF work: the gap between what a user consents to up front ("plan a trip") and the chain of actions the agent decides on at runtime (calendar, flights, hotels, bank balance). Consent given once cannot cover a plan that does not exist yet. The report's direction: least privilege via context-aware authorization, plus just-in-time grants. Defined: §7.2, p. 32 · Used in: OP 7.3 |
| Intent-binding artifact | A proposed tamper-evident record tying together the user's authenticated instruction, the agent's interpretation (plan or reasoning trace), and the actions taken, verifiable by third parties. Posed as a question, by analogy to signed append-only logs like Certificate Transparency. Defined: §7.3, OP 7.5, p. 35 · Used in: OP 7.5 |
| Functional revocation | Called an emerging concept: deleting the source record is not enough, so revocation should mean the agent can no longer use the information, whether by retrieval, reasoning, or leakage through derived forms. Defined: §7.4, OP 7.8, p. 37 · Used in: OP 7.8 |
| Ghost representations | Personal data that survives deletion as derived knowledge: embeddings, summaries, memories. The report's example: an agent reads a private email, summarizes it, and stores the summary in a vector database. Defined: §7.4, OP 7.8, p. 37 · Used in: OP 7.8 |
| Model context contamination | Data minimization failing inside the agent: one flat context window carries everything, so details from a private subtask (parsing medical records) are visible while the agent does an unrelated, less privileged one (a public web search). For self-evolving agents it extends into persistent memory and reusable tools. Defined: §7.4, OP 7.7, p. 37 · Used in: OP 7.7 |
| Tool over-privilege | Agents exposing more state to external APIs, and holding broader permissions, than the task needs, because nobody knows the exact requirements up front and tool interfaces are loose by design. Defined: §7.4, OP 7.7, p. 37 · Used in: OP 7.7 |
| Last-mile developer | The report's framing of what makes an application agentic: the developer hands part of the job of writing the application to the model, from parsing an email up to discovering and running new code. The more is handed off, the more agentic, and the less the developer's intent is pinned down in code. Defined: §7.5.1, p. 39 · Used in: AI as the last-mile developer |
| Knowing–doing gap | A term from cited work: agents whose actions diverge from the reasoning they state. The report's example: an agent that says it must never expose API keys, then pastes a stack trace with keys into a public tracker during a multi-turn debugging task. The point for CI: test what agents do, not only what they say. Defined: §8.1.2, p. 46 · Used in: OP 8.1 |
| Contextual handshake | A metaphor for two agents negotiating the parameters of an exchange (roles, information types, transmission principles, task language) before doing the task. If it succeeds, the agreed principles could propagate down a delegation chain. Whether the other side then complies is a separate, verification problem. Defined: §11.1, OP 11.1, p. 66 · Used in: OP 11.1 |
| Semantic downgrade attack | A risk raised in one sentence: a hostile counterparty claims it cannot agree on norms, to push the exchange onto a weaker fallback channel, like protocol stripping on the early web. Defined: §11.1, p. 66 · Used in: OP 11.1 |
| Trust attenuation | How constraints should be kept or changed as data and authority pass from agent to agent. Often the user's original constraints live only in the first agent's window and get lost or escalated on each hop. The report asks for a formal model; none is given. Defined: §11.2, p. 67 · Used in: OP 11.3 |
| Behavioral attestation | An open question, not a technique: remote attestation can prove which binary runs, but an agent's behavior depends on its inputs, so an attested agent can still be steered into harm. The report asks what attesting behavior would even mean, and notes nearby work attests the deterministic parts instead (policy engine, environment, evaluation results). Defined: §11.3, OP 11.7, p. 70 · Used in: OP 11.7 |
| Norm repository | A proposed public, structured catalog of context-specific informational norms, built from forward-looking empirical research, that agents could query and that developers and regulators could share. Defined: §12.1, OP 12.2, p. 73 · Used in: OP 12.2 |
| Circuit breaker | A deterministic, system-level stop that actually halts the agent: no new actions, kill signals to every spawned process and sub-agent, and ideally a report of what was and was not stopped. The report notes current stop messages carry no guarantee the model obeys, and suggests the idea for multi-agent platforms too, by analogy to stock exchanges. Defined: §9.3.3, OP 9.5, p. 57 · Used in: OP 9.5 |
"Dynamic policy generation that maps context and norms into a formal policy on (formally modeled) agent actions, expressed in a machine-checkable language."— the report, the first of two responsibilities in its contextual policy engine definition, §6.4, p. 26
The two confusions that cause the most trouble: reading "context" as the prompt, and treating a transmission principle as an access-control flag. In this report, context is the social setting the agent is acting in, and a transmission principle is the condition that makes a particular flow appropriate there. Get those two right and most of the coinages follow.
Connections
The CI terms are worked through, with examples, on Contextual Integrity, applied to agents, including the critiques from Appendix C. The agent definitions and threat models are on Three dimensions, four threat models. The contextual policy engine is unpacked on the policy engine page, and contextual security on Contextual Security. For the CI vocabulary applied to agent memory, the sibling CIMemories field map covers the benchmark the report reviews in Appendix D.
Further reading, verified
- Privacy in Context: Interactive CI Glossary — privaci.info · the full, current CI glossary the report names as the up-to-date version of Appendix A
- Position: Contextual Integrity is Inadequately Applied to Language Models — Shvartzshnaider & Duddu (2025) · cited for the claim that some CI benchmarks rest on weak readings of the theory, the motivation for standardizing terms
- Contextual Agent Security: A Policy for Every Purpose — Tsai & Bagdasarian (2025) · Conseca, an instance of the contextual policy engine pattern and an earlier use of "contextual security"
- Defeating Prompt Injections by Design — Debenedetti et al. (2025) · CaMeL, cited as a system that generates dynamic policies as execution plans
- Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection — Greshake et al. (2023) · cited for describing and evaluating indirect prompt injection
Next: All 51 open problems · Back to the map.