Label before retrieval: securing data before AI touches it

A retrieval-augmented generation pipeline can convert a well-controlled document into an embedding, split it into chunks, copy it into a shared index, place it inside a prompt, and retain part of the interaction as agent memory.

At each transformation, security context can be weakened or lost.

The source repository may know that a document belongs to Finance, contains restricted acquisition information, expires after seven years, and is readable by only three groups. A vector store will not automatically understand those obligations. Unless the pipeline carries them forward and enforces them at query time, semantic similarity can become an unintended path around source-system authorization.

1. Classify before embedding

Classification needs to happen before content enters the embedding pipeline—not after the model has already processed it.

For every source object, establish at least:

• Authoritative owner
• Business purpose
• Sensitivity classification
• Tenant or organizational boundary
• Source-system identifier
• Access-control policy or ACL reference
• Retention and deletion requirement
• Geographic or regulatory restrictions
• Integrity and trust status
• Permitted AI uses

Sensitivity labels are useful because they express how an organization handles information without requiring every downstream system to inspect the original content. Microsoft documents that Purview labels can extend across files, data assets, SharePoint, Teams, Power BI, and SQL, although implementation behavior differs between services. Microsoft Purview sensitivity labels ↗

A label, however, is not an authorization decision.

Confidential describes handling requirements. It does not prove that the current user can read every confidential document. The ingestion pipeline must preserve both classification and resource-level authorization.

Do not accept a model-generated classification as authoritative. Classification should originate from the source system, a governed data catalog, a deterministic policy, or a reviewed detection process. AI-assisted classification may recommend a label, but ambiguous or high-impact decisions need an accountable owner.

2. Make ownership operational

“Owned by Security” is not enough metadata.

The owner must have responsibility for approving the data source for AI use, defining permitted user populations, reviewing classification exceptions, responding to access disputes, revalidating stale content, authorizing derived datasets and embeddings, and approving retention or deletion changes.

The pipeline should quarantine content when the owner is unknown, inactive, or outside the tenant responsible for the AI application.

Ownership must also survive chunking. A paragraph extracted from a policy does not become ownerless because it no longer resembles the original file. Each chunk should retain a stable reference to the source object, owner, policy version, and access-control material.

3. Carry policy through the data flow

The most important controls are the two gates:

1. The ingestion gate decides whether the organization permits the content to be used by this AI system.
2. The retrieval gate decides whether this identity may receive this content for this purpose at this moment.

Neither decision belongs to the model.

4. Preserve authorization at chunk level

RAG systems often retrieve chunks rather than complete documents. Authorization must therefore remain resolvable for every chunk.

{
  "tenant_id": "tenant-blue",
  "source_id": "sharepoint:item:8f27",
  "source_version": "2026-08-03T14:22:11Z",
  "owner_id": "finance-risk",
  "classification": "restricted",
  "permitted_groups": ["finance-ir", "legal-investigations"],
  "ai_use": ["incident-analysis"],
  "retention_until": "2033-08-03",
  "legal_hold": false,
  "policy_version": "rag-access-2026.08",
  "content_digest": "sha256:..."
}

At retrieval time:

1. Authenticate the human or workload identity.
2. Establish the tenant from trusted identity context.
3. Determine groups, roles, purpose, and environmental conditions.
4. Apply tenant and authorization filters before semantic results are returned.
5. Revalidate the selected results against current policy.
6. Reject chunks with missing, stale, or malformed security metadata.
7. Record why each chunk was released.

Azure AI Search documents security-filter and identity-based approaches for document-level result trimming. Its security-filter pattern stores identities with indexed documents and filters results using the caller's identity. Some native ACL and RBAC integrations remain preview capabilities and should be evaluated accordingly. Azure AI Search document-level access control ↗

Google similarly supports access-controlled data sources for Agent Search and notes that access control must be configured when the data store is created rather than added later to an existing store. Google Cloud data-source access control ↗

5. Enforce tenant boundaries independently

Authentication and tenant isolation are related but different controls.

A user can be properly authenticated and authorized for an application while a query, cache key, vector namespace, tool credential, or memory identifier accidentally points to another tenant. AWS guidance makes the same distinction: authorization does not inherently guarantee that one tenant cannot access another tenant's resources. AWS tenant-isolation guidance ↗

• Derive tenant_id from trusted identity claims, never from prompt text.
• Bind the tenant to the request at the application edge.
• Use tenant-scoped credentials where supported.
• Partition indexes, namespaces, collections, encryption keys, or accounts according to risk.
• Include tenant scope in cache and memory keys.
• Reject a result whose stored tenant differs from the authenticated tenant.
• Test cross-tenant queries intentionally.
• Monitor zero-result and denied cross-tenant attempts.

For high-sensitivity environments, separate vector stores or accounts may be more defensible than metadata-only separation. Shared infrastructure can still be appropriate, but the isolation control must exist below the model and be tested independently.

AWS's agentic-AI guidance illustrates tenant-specific knowledge stores and tenant-scoped credentials as enforcement options. AWS agentic-AI tenant isolation ↗

6. Treat embeddings and vector stores as sensitive data

An embedding is not automatically anonymous, harmless, or exempt from data handling rules.

Vector and embedding systems introduce risks including unauthorized retrieval, cross-context leakage, poisoning, and the possibility of recovering information about source content. OWASP recommends fine-grained access control, logical partitioning, source validation, and review when combining datasets with different restrictions. OWASP vector and embedding weaknesses ↗

The embedding service also sees the content. Confirm provider data handling, residency, retention, abuse-monitoring, and training terms before sending restricted material.

7. Keep retention and deletion attached to derivatives

Retention is not satisfied by deleting only the original file.

A single source can produce parsed text, extracted tables, OCR output, chunks, embeddings, search caches, prompt logs, model traces, evaluation datasets, conversation summaries, agent memory, and backups.

The deletion process needs a derivation map from the source object to each downstream copy. Retention metadata should drive an event-based workflow when the source expires, an owner deletes it, a label or ACL changes, a tenant relationship ends, consent is withdrawn, a legal hold changes, or an integrity issue invalidates the source.

Microsoft supports automatically applying retention labels using sensitive information, keywords, searchable properties, and classifiers, but AI pipelines must still propagate and enforce the resulting requirement across their own derivative stores. Microsoft Purview automatic retention labels ↗

A nightly rebuild is rarely enough for urgent revocation. High-risk systems need deletion and authorization-change events that invalidate vector records, caches, and memory promptly.

8. Control what enters the prompt

Permission-aware retrieval is necessary, but the prompt assembly layer remains a security boundary.

• Recheck the current identity and tenant.
• Limit the number and total size of chunks.
• Remove fields that are not required for the task.
• Apply masking or tokenization where appropriate.
• Preserve citations and source identifiers.
• Mark retrieved text as untrusted data, not executable instructions.
• Reject content whose source changed after retrieval.
• Detect unusual combinations of classifications or owners.
• Prevent retrieved content from changing system policy or tool authority.

A user's permission to read a record does not automatically justify placing the entire record in a third-party model context. Purpose, minimization, provider terms, and application risk still matter.

9. Treat agent memory as another governed data store

Agent memory often begins as a convenience feature and quietly becomes a new system of record.

Memory can contain user prompts, retrieved confidential passages, model conclusions, tool results, credentials or identifiers, personal preferences, incident details, and incorrect model-generated assertions.

Memory should carry an owner and subject, tenant, conversation or agent scope, sensitivity, source provenance, creation and expiration times, permitted future uses, integrity status, and deletion reference.

Do not allow one user's memory to enter another user's context. Do not let shared agents merge tenant memories. Do not promote temporary conversation material into long-term memory without a defined policy.

OWASP's LLM Verification Standard calls for segregation of conversational and long-term memory, authenticated storage, least privilege, leakage controls, and protection against unauthorized knowledge-base updates. OWASP LLM Verification Standard ↗

10. Log the security decision—not the sensitive content

For each ingestion and retrieval event, record the request and trace ID, human and workload identity, tenant, purpose, source and chunk identifiers, classification and owner, policy revision, filters, allow or deny outcome, prompt-assembly decision, model and embedding versions, memory-write decision, and retention events.

Avoid copying complete prompts or retrieved passages into general-purpose logs. Logs can become a less protected duplicate knowledge base. Use identifiers, hashes, structured decisions, and tightly controlled forensic capture when full content is genuinely required.

11. Test the boundary as an attacker would

• Cross-tenant semantic searches
• Users removed from an authorized group
• Documents relabeled after embedding
• ACL changes after indexing
• Deleted documents still present in caches
• Chunks missing ownership or tenant metadata
• Forged tenant IDs in prompts or request bodies
• Retrieval filters omitted by an alternate API path
• Prompt injection inside an authorized document
• Poisoned documents from a compromised source
• Memory retrieval across users or sessions
• Expired content included in a prompt
• Backup restoration that resurrects deleted vectors
• Administrative keys used from an untrusted workload

Test both expected denials and the telemetry produced by them.

Field checklist

• Data has an accountable owner before ingestion.
• Classification and AI-use approval are separate decisions.
• Every chunk retains source, tenant, owner, ACL, retention, and integrity context.
• Tenant identity comes from trusted authentication.
• Retrieval applies authorization before content reaches the model.
• Missing or stale policy metadata fails closed.
• Vector storage, caches, prompts, and memory inherit source protections.
• ACL, label, retention, and deletion changes propagate downstream.
• Agent memory is isolated and expires deliberately.
• Logs preserve decision evidence without unnecessarily duplicating content.
• Cross-tenant, stale-access, poisoning, and deletion scenarios are continuously tested.

Closing position

The important question is not, “Can the model find this document?”

It is, “Should this identity, operating for this tenant and purpose, receive this exact information now—and can the system prove why it allowed that?”