How should sensitive information be handled in agent memory?

Sensitive information in agent memory should be minimized, protected, tightly scoped, and retained only when there is a clear reason to keep it.

A memory system should not store sensitive data simply because it appeared in a conversation.

Start with data minimization

The safest sensitive memory is information that was never stored unnecessarily.

Before persisting information, the system should ask:

• Is this information actually needed later?
• Can the task work without storing it?
• Can a less sensitive summary be stored instead?
• How long does it need to remain available?

For example, an agent may need to remember that a user prefers email communication, but it may not need to store the full contents of every email.

Avoid storing secrets in memory

Credentials and authentication secrets generally should not become normal agent memory.

Examples include:

• passwords
• API keys
• access tokens
• private keys
• session secrets

These belong in dedicated secret-management systems with controlled access.

The agent can reference a credential indirectly when needed without placing the secret itself into conversational or semantic memory.

Classify sensitive information

Different information may require different controls.

Examples include:

• personal information
• financial information
• health information
• confidential business data
• authentication data
• internal security details

Classification helps determine whether the information may be stored, who can access it, and how long it should be retained.

Use the narrowest possible scope

Sensitive memories should be attached to the exact scope where they are valid.

For example:

• user
• session
• project
• tenant
• organization

A user-specific sensitive memory should never become globally searchable.

The narrower the scope, the lower the risk of accidental exposure.

Enforce access control before retrieval

The memory system should determine what the current user or agent is authorized to access before performing relevance search.

A safe retrieval flow is:

1. Identify the authenticated user and tenant.
2. Apply authorization rules.
3. Restrict the allowed memory set.
4. Search only within that set.
5. Return the minimum information needed.

Authorization should not depend on the model remembering to apply a filter.

Encrypt sensitive memory

Sensitive memory should normally be protected:

• in transit
• at rest

For particularly sensitive fields, systems may also use field-level encryption or tokenization.

Encryption reduces exposure if storage or backups are accessed improperly, although it does not replace access control.

Redact unnecessary details

Sometimes the agent needs the meaning of sensitive information without needing the exact raw value.

For example, instead of storing:

Full card number: 4111 1111 1111 1111

the system should generally avoid storing the number at all and use a safe reference such as:

Payment method: card ending in 1111

Similarly, logs and traces should avoid copying sensitive memory unnecessarily.

Limit retention

Sensitive information should not remain in memory forever by default.

Retention controls may include:

• expiration time
• review date
• automatic deletion
• session-only storage
• purpose-based retention

When the information is no longer needed, it should be removed or made inaccessible according to the applicable policy.

Separate memory from audit history

Operational memory and audit records serve different purposes.

The agent may no longer need a sensitive fact for reasoning even if the organization must retain a controlled audit record for compliance.

Keeping these systems separate allows normal memory retrieval to remain minimal while audit data remains protected under stricter access rules.

Do not send sensitive memory to every model call

Even authorized information should only be added to context when it is necessary for the current task.

For example, a stored billing address should not be included while the agent is answering an unrelated coding question.

Selective retrieval reduces unnecessary exposure.

Be careful with embeddings

Sensitive text can also be exposed through vector-search systems if embeddings and their source data are not scoped correctly.

A vector memory system should use:

• user or tenant isolation
• metadata filters
• access controls
• protected source records

Embedding-based similarity must never bypass authorization.

Support correction and deletion

Users or administrators may need to:

• correct stored information
• revoke consent
• delete memory
• update outdated information
• change retention preferences

A memory system should support these operations rather than treating memory as permanent.

Protect backups, logs, and traces

Deleting a memory from the primary store is not enough if the same sensitive information remains copied into:

• application logs
• model traces
• caches
• analytics systems
• backups

Sensitive-data handling should consider the full data lifecycle.

Monitor access

For important memory stores, access may be logged with information such as:

• who accessed the memory
• when it was accessed
• what operation occurred
• which tenant or project was involved
• whether access was allowed or denied

This helps detect misuse and investigate incidents.

Use stronger controls for higher-risk data

The more sensitive the information, the stricter the handling should be.

For highly sensitive memory, a system may require:

• explicit consent
• shorter retention
• stronger encryption
• narrower access
• additional approval
• fresh verification before use

Not every memory should receive the same treatment.

A useful principle

Before storing sensitive information, ask:

Do we need to remember this exact data, or only enough information to complete future tasks safely?

Often the safer answer is to store less.

In short

Sensitive information in agent memory should be minimized, explicitly scoped, access-controlled, encrypted, selectively retrieved, and removed when no longer needed.

Secrets should generally stay in dedicated secret stores, while agent memory should retain only the smallest amount of sensitive information required for legitimate future use.