Enforce scoped memory access and lifecycle

Learning objective

Enforce memory authorization, tenant isolation, compliance, and consistency boundaries

Core idea

Memory is stored application data that later becomes model input. An architect must enforce who can read and write it, how tenants remain isolated, when it expires or is deleted, and when a completed write is safe to rely on. Prompt instructions alone cannot implement those controls.

Foundry Agent Service memory is preview. It provides store partitioning through scope, identity resolution for the memory search tool, direct memory APIs, retention settings, and deletion operations. These mechanisms support governance, but the application must still bind requests to trusted identities and distinguish asynchronous extraction from completed state changes.

See 1.2.4 for the broader compliance control mapping and 2.2.5 for persistence selection. This lesson concerns the controls at memory ingestion, storage, retrieval, and correction.

How it works

Bind scope to a trusted principal

Use the memory tool’s scope="{{$userId}}" and x-memory-user-id identity mapping described in 1.2.5; the enforcement decision here is which trusted principal may select the scope.

The header path is useful when a backend calls the service for an end user. It also means the application must control the header value. Derive it from the authenticated tenant and user mapping, reject unauthorized substitutions, and avoid forwarding a caller-supplied scope or user ID unchanged. A backend that authenticates with one service principal but omits the end-user mapping can place different customers under the same calling identity.

Low-level memory APIs do not perform that automatic identity extraction. Supply scope explicitly for each operation, using a stable key derived by trusted code. Carry the same mapping through updates and searches. A typo can make valid memory disappear; an unauthorized substitution can select another collection.

Both paths take their scope from the same trusted mapping, and a caller-supplied value is never forwarded unchanged.

The documented RBAC setup assigns Foundry User to the project’s managed identity on the containing resource. The usage page states that this role was named Azure AI User before the Foundry role rename; role IDs and core permissions are unchanged. Use the full role name and verify the resource scope. Authentication and a project-level role do not replace the application’s end-user authorization checks.

Keep tenant and retrieval isolation explicit

Make tenant membership part of the trusted identity-to-scope mapping and maintain separate stores or operational partitions where the isolation requirement calls for them. A scope string supplied by application code is not evidence that the caller is entitled to that scope. Enforce the mapping before every read, write, item operation, and deletion.

Foundry memory does not support virtual network integration for memory stores, according to its conceptual page. A workload that requires memory traffic to remain inside that network arrangement cannot assume the feature satisfies the requirement. Choose a compatible persistence architecture rather than substituting a naming convention for a network control.

When remembered context links to documents, apply the group_ids/any(g:search.in(...)) security-filter pattern from 1.2.4 on every retrieval query, deriving permitted groups from a trusted identity source.

Microsoft documents native ACL and RBAC-scope enforcement, Purview sensitivity labels, and SharePoint ACL integration as preview document-access approaches. Native token-based queries use x-ms-query-source-authorization and permission metadata in the index. Do not present ordinary string filters as Microsoft Entra token validation, or assume native access metadata instantly follows changes in the source system.

Enforce minimization, retention, and deletion

Foundry’s user_profile_details guides the extraction of useful information and can instruct the memory system to avoid sensitive data. Treat this as guidance to an extraction model. Apply deterministic redaction or exclusion before ingestion for content that policy prohibits storing; do not depend on wording alone to prevent credential retention.

For supported stores, MemoryStoreDefaultOptions.default_ttl_seconds sets default retention. The documented value 0 means no expiration. TTL applies to direct commands, extraction and consolidation, and item-level CRUD. When memory is updated and consolidated, the service resets its last-updated time. A rolling retention policy can therefore differ from a requirement to expire data a fixed period after original collection.

The usage page says TTL affects stores created after TTL support was introduced and does not affect existing stores. It also warns that some default options are creation-time settings in the preview. Verify your API version’s update support before claiming an existing store has acquired retention merely because a configuration file changed.

Python’s project_client.beta.memory_stores.delete_memory() deletes an item by memory_id; delete_scope() removes a scope’s memories while retaining the store. Authorize item-level deletion against the item’s permitted ownership, because possessing an item ID is not a grant to delete it. Record deletions in the application’s tamper-evident audit trail, as Microsoft’s best practices recommend.

Deletion from a memory store is one lifecycle action. Trace associated conversation records, caches, exported evidence, and application-owned provenance separately. Do not tell a user that every copy is erased merely because one memory item was removed.

Observe write completion and stale permissions

The memory search tool’s update_delay debounces ordinary updates; its documented default is 300 seconds. Low-level begin_update_memories() is a long-running operation that can take about a minute. update_delay=0 triggers processing immediately, but the application still needs to wait for completion, such as through the returned poller’s result().

previous_update_id chains updates from an earlier update operation. It is a continuation identifier; the cited page does not establish a cross-agent transaction or a universal concurrency-control guarantee. Serialize conflicting writes through a designated owner when the business state requires deterministic ordering, then verify the resulting memory or authoritative record.

Explicit remember-or-forget requests with the memory tool apply immediately and return memory command items. Inspect the documented memory_command_call status rather than interpreting fluent response text as proof of completion. Direct commands still obey configured TTL.

For native Search permission enforcement, results depend on permission metadata synchronized into the index. Source permission changes require the appropriate indexer run, push update, or refresh. A stale index can therefore disagree with the source. If revocation must take effect before synchronization, use an additional authoritative access check or suspend retrieval until the update is verified.

Key distinctions and trade-offs

Scope partitioning, RBAC, network isolation, and document permissions solve different problems. A broad service role can coexist with per-user scope partitioning; the application still enforces which scope the backend selects. Shared memory increases reuse while requiring stronger rules for who promotes and corrects records.

Extraction delay improves batching but weakens immediate read-after-write assumptions. Waiting for completion improves predictability but adds latency. For high-value commitments, retain authoritative application state and pass the confirmed value directly rather than relying on semantic memory to settle a business transaction.

Architecture / decision scenario

A two-tenant support service uses one backend identity. A customer changes a contact preference, requests deletion of a prior sensitive note, and loses access to a team document during the same interaction.

The backend derives a tenant-and-user scope from authenticated claims and controls x-memory-user-id for the tool path. Direct APIs use that same trusted scope mapping. It authorizes the sensitive note’s item ID before delete_memory(), records the deletion, and separately checks whether the note exists in retained conversations.

The preference update uses begin_update_memories() with update_delay=0, waits for the poller’s completion, and verifies the result before claiming it is remembered. Conflicting updates pass through the designated writer. The team document is not retrieved solely because an earlier memory mentioned it: document access is checked against the revoked entitlement while index permissions synchronize.

Acceptance includes attempts to substitute another tenant’s scope, retrieval immediately after an unfinished update, deletion of an unauthorized item ID, and recall after access revocation. Each test exercises an enforced decision rather than a model’s willingness to follow instructions.

Common exam traps

• Treating a caller-controlled scope or header as an authenticated identity.
• Using one backend identity as the memory owner for every customer.
• Equating update_delay=0 with a completed update.
• Assuming TTL retroactively changes every existing store.
• Treating memory deletion as deletion of every associated record.
• Assuming indexed permissions reflect source revocation instantly.

What to remember

Derive scope from trusted identity, enforce access before each memory operation, and distinguish partitioning from authorization. Verify retention applicability, observe update and deletion outcomes, and account for stale permissions. Semantic consolidation cannot replace deterministic ownership of consequential business state.

Knowledge check

References

• Microsoft, Create and use memory in Foundry Agent Service
• Microsoft, Memory in Foundry Agent Service
• Microsoft, Document-level access control
• Microsoft, Security filters for trimming results