How can I find the scope value

Question

How can I find the scope value

Mohamed, Rihan 60

I created a Foundry Agent and connected it to a Memory Store. I configured the memory scope as shown in screenshot. After chatting with the agent, memories were created successfully. I can see the Memories section in the Foundry Portal, but I do not know what value should be entered in the Scope field to view the memories created by my test. How can I find the correct scope value for my current agent session?

Mohamed, Rihan 60 Reputation points

2026-08-19T09:02:47.4333333+00:00

Please see the screenshot above.
saleha mubeen 10 Reputation points

2026-08-19T09:20:15.0833333+00:00

The key is usually to identify the exact scope value being passed when the agent creates or retrieves memories. I’d inspect the agent session/request details in the Foundry logs or SDK calls and look for the memory scope or session/user identifier being sent. The value configured in the Memory Store defines how memories are partitioned, so the portal’s Scope field generally needs to match that exact value. If the scope is dynamically generated, logging the resolved scope during the test session should make it easier to locate the corresponding memories.
Mohamed, Rihan 60 Reputation points

2026-08-19T09:25:00.07+00:00

Thanks for the response! I have tried exactly this — here's what I found:

Logs: I pulled two full container session logs directly from Foundry (via azd ai agent monitor) covering successful memory read/write turns, and grepped them for scope, memory_stores, and userId — zero matches. The actual REST call to the memory store happens inside the azure-ai-projects SDK (beta.memory_stores.search_memories/update_memories), which isn't wrapped by the same "Foundry storage" logger used elsewhere in the container (that one does log calls like storage/state_stores, storage/responses, etc., but never touches the memory store endpoint). So there's no log line to inspect for it, even at the verbosity these logs already show.

SDK calls: I inspected the agent_framework_foundry._memory_provider source directly — the client only ever passes the literal string "{{$userId}}" through as-is; there's no client-side substitution. So the resolution to a real identity happens entirely server-side, inside the Foundry memory store backend, based on the caller's auth context — never returned to the client or logged.

Headers: Even enabling DEBUG-level HTTP logging wouldn't help — Azure's SDK logging policy redacts any non-standard header (confirmed from the same logs — Authorization, Foundry-Features, etc. all show as <redacted>), so any identity-carrying header would be redacted too.

Direct testing: I also tried 27 different candidate scope values programmatically against the store via list_memories (raw object id, tenant+object id combinations, UPN variants, SHA-256 hashes, session/conversation ids, the agent's own identity, common literal placeholders) — all confirmed empty.

Given all that, my question is more specific: is there an official/supported API or portal feature to look up the resolved scope key for a given caller, rather than general guidance to "inspect logs" — since the resolution appears to happen entirely server-side with no client-observable trace? Is this intentionally non-discoverable for privacy/isolation reasons?
Mohamed, Rihan 60 Reputation points

2026-08-19T09:26:30.3433333+00:00

@saleha mubeen Thanks for the suggestion! I did try that already. I pulled the actual container logs from Foundry for successful memory read and write turns and searched them for any mention of the scope or user identifier, but nothing showed up. The call that actually resolves the user identity happens inside the underlying SDK and isn't logged at any level I have access to, and any identity-related headers are redacted by default in Azure's SDK logging. I also inspected the SDK source directly and confirmed the client only passes the literal placeholder through as-is, so the real value is resolved entirely server side and never returned to the caller. I also tried around two dozen different candidate values directly against the memory store (object id, tenant id combinations, username variants, hashes, session and conversation ids, and the agent's own identity), and none of them matched. So my question is really whether there's an official way to look up this resolved value, or whether it's intentionally not exposed for privacy reasons.

3 answers

Your answer

Mohamed, Rihan 60 Reputation points

2026-08-19T09:02:47.4333333+00:00

Please see the screenshot above.
saleha mubeen 10 Reputation points

2026-08-19T09:20:15.0833333+00:00

The key is usually to identify the exact scope value being passed when the agent creates or retrieves memories. I’d inspect the agent session/request details in the Foundry logs or SDK calls and look for the memory scope or session/user identifier being sent. The value configured in the Memory Store defines how memories are partitioned, so the portal’s Scope field generally needs to match that exact value. If the scope is dynamically generated, logging the resolved scope during the test session should make it easier to locate the corresponding memories.
Mohamed, Rihan 60 Reputation points

2026-08-19T09:26:30.3433333+00:00

@saleha mubeen Thanks for the suggestion! I did try that already. I pulled the actual container logs from Foundry for successful memory read and write turns and searched them for any mention of the scope or user identifier, but nothing showed up. The call that actually resolves the user identity happens inside the underlying SDK and isn't logged at any level I have access to, and any identity-related headers are redacted by default in Azure's SDK logging. I also inspected the SDK source directly and confirmed the client only passes the literal placeholder through as-is, so the real value is resolved entirely server side and never returned to the caller. I also tried around two dozen different candidate values directly against the memory store (object id, tenant id combinations, username variants, hashes, session and conversation ids, and the agent's own identity), and none of them matched. So my question is really whether there's an official way to look up this resolved value, or whether it's intentionally not exposed for privacy reasons.

Answer 1

Your investigation is correct: when the memory tool is configured with scope="{{$userId}}", the placeholder is resolved server-side. The client does not replace it locally.

The current Foundry Memory documentation now describes the resolution rule explicitly:

If the request contains x-memory-user-id, that header value is used as the user scope.

If the header is not present, Foundry falls back to the caller's Microsoft Entra identity, represented as:

{tenant-id}_{object-id}

So if your response call is authenticated directly as your Entra user and you are not sending x-memory-user-id, the scope you would expect is:

<TID>_<OID>

For an interactive Azure user, you can get the two values with:

az account show --query tenantId -o tsv
az ad signed-in-user show --query id -o tsv

Then combine them with an underscore.

However, there is an important distinction here: this only works if that Entra user is actually the identity used by the response call. If the hosted agent or another service identity is making the call, the OID will be different.

I also could not find a documented API in the current Memory Store surface that lists or reverse-resolves all existing scope keys. The memory APIs still require the caller to provide the scope when listing or searching memories.

Because of that, for application code I would avoid depending on discovering the automatically generated scope after the fact.

A more deterministic approach is to pass your own stable user identifier:

x-memory-user-id: user-123

while keeping the memory tool configured as:

scope="{{$userId}}"

Then user-123 becomes the known memory scope for that request, and you can use the same value when inspecting or querying that user's memories.

So for your current portal-created memories:

If no x-memory-user-id was supplied, verify the actual Entra identity used by the response call and try {tid}_{oid}.

If the portal does not expose which caller identity was used, I don't see a documented lookup endpoint that will recover the resolved key afterward.

For future tests, explicitly pass x-memory-user-id from the client/API so the scope is deterministic and observable.

This also explains why inspecting the literal {{$userId}} in the SDK source did not reveal the final key—the substitution is intentionally performed by the Foundry service, not by the client SDK.

References

Microsoft Foundry — Create and use memory in Foundry Agent Service https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/memory-usage

Microsoft Agent Framework — Microsoft Foundry provider https://learn.microsoft.com/en-us/agent-framework/agents/providers/microsoft-foundry

AI assistance disclosure: I used ChatGPT to help structure this response, and I reviewed the technical guidance against the current Microsoft Foundry Memory and Agent Framework documentation before posting.

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 3

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more