# No user ID in any tool.

> The model can only pass what you let it.

- **Format:** short video, 9 steps, ~51 seconds
- **Topic:** Securing a Microsoft Foundry agent: never put a user ID in a tool schema, resolve identity from the validated JWT in the executor, check roles before tools run, and defend against prompt injection in tool output.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Published:** 2026-05-23
- **Tags:** microsoftfoundry, azureai, aiagents, dotnet, flutter, azure, aicoding, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/foundry-no-user-id-in-any-tool/

---
## What you'll learn

- How prompt injection arrives through tool output
- Why identity must never be a tool parameter
- Where role checks belong

## Understand it one step at a time

### 1. One edited dish

A partner can edit their menu, and the menu comes back inside a tool result.

### 2. Into the context

The tool result carries that text straight into the model.

### 3. If tools take IDs

get_user_profile(userId) lets a fooled model ask for anyone.

### 4. Remove the parameter

get_user_profile() takes no ID at all.

### 5. Identity from the token

The executor resolves the caller from the validated JWT.

### 6. Role check first

Each tool has the roles allowed to call it, checked before it runs.

### 7. Layers, not one fix

Harmless tools, instruction separation, sanitising, content filters.

### 8. Even fooled, it is contained

A fully compromised model still gets only the caller’s own data.

### 9. No user ID in any tool

Resolve identity in the executor, so even a fooled model cannot reach another user.

---

## The takeaway

**No user ID in any tool.**

Design so that a fully compromised model still cannot reach another user’s data.