Module 2: Bind Identity, Tools, and Data

Bound Retrieval, Memory, and Sensitive Data

Decide what the agent may retrieve, what can persist, and which evidence is sufficient without building a second uncontrolled copy of sensitive information.

Approx. 4 min reading · Includes diagrams; allow extra time for reflection and linked resources.

Start reading ↓
About this learning content and editorial review
About this learning content: Courses, lessons, assessments, explanations and illustrations may be created with the help of artificial intelligence. We review and check the material and do our best to avoid incorrect or outdated information, but mistakes, omissions or ambiguous questions may remain. Please verify information before relying on it for professional, security, legal or operational decisions. Read the full notice or report an issue.

Your focus

What you’ll learn

  • Define distinct trust, authorization, and retention rules for retrieval, transient context, memory, and logs.
  • Preserve enough evidence for a security decision without collecting every prompt, document, or output.

Connects retrieval authorization, tenant isolation, memory poisoning, provenance, minimization, retention, and privacy-safe security evidence.

Retrieval expands context, not authority

The support agent searches a knowledge base and customer history before drafting an answer. Retrieval improves relevance, but it creates two separate questions: may this workflow access the source, and should this source influence the current action? A document returned by search is not trusted instruction merely because the user may read it.

Enforce source authorization before retrieval and again when results cross tenant, case, or sensitivity boundaries. Filter using the requesting and executing identities, not a broad index credential whose results are trimmed only after generation. Preserve source identifiers and access decisions so a later reviewer can tell which material grounded the response.

Treat retrieved content as untrusted data in tool-capable context. A poisoned knowledge article can carry instructions, false facts, or misleading links. Use provenance, ownership, change history, content classification, and ingestion controls. When a source is not needed for a consequential action, keep it out of that action’s context rather than hoping the model ignores it.

Memory is a write operation with future consequences

The team wants the agent to remember customer preferences. If every conversation can write durable memory, a malicious ticket can influence later sessions after the original content disappears. Memory poisoning is therefore not only a model-quality problem; it is an integrity and authorization problem across time.

Define who may write which memory, for which subject and purpose, with what evidence, expiry, and review. Separate user preferences from security policy and never let remembered text redefine tool permissions. Expose memory to the user or responsible operator where appropriate, record its provenance, and provide correction and deletion paths. High-impact memories may require confirmation before use, not only before storage.

Isolate memory by tenant, user, agent purpose, and environment. Test whether identifiers can be confused or reused. A staging agent should not learn from production conversations, and one customer’s preference should never ground another customer’s action.

Collect evidence without copying the entire interaction

Full prompts, retrieved documents, tool arguments, outputs, and memory may contain credentials, legal material, health information, or customer records. Logging everything can create a second sensitive corpus with broader access and longer retention than the source systems.

Start with the security decision. To detect an unauthorized refund, you may need the agent and sponsor identities, case and customer identifiers, amount band, policy and confirmation result, tool version, target receipt, and time—not the complete conversation. Protect content retrieval behind purpose, access, and retention controls when a deeper investigation genuinely requires it. Hashes do not anonymize small or guessable values, and redaction can leave sensitive meaning behind.

The site’s Privacy-Safe Logging for Prompts, Retrieval, Memory, and Outputs provides the detailed minimization model. For Microsoft environments, Purview DSPM for AI shows how AI exposure, data posture, and governance relate without treating a dashboard as proof of safety.

Resources

  • NIST Generative AI Profile — Use NIST AI 600-1 to connect information security, privacy, measurement, governance, and generative-AI risk management.