How should security teams bind each agent tool call to the signed-in user in multi-user applications?

Why This Matters for Security Teams

Binding each agent tool call to the signed-in user is a tenant-safety problem before it is an AI problem. In multi-user applications, the risky part is not whether the model can read a username, but whether it can influence which identity is used when a tool executes. If that identity is passed as user-controlled input, prompt injection and malformed requests can shift actions across accounts. Guidance in the OWASP Agentic AI Top 10 and NHIMG’s OWASP NHI Top 10 both point to the same control principle: the model should never be the source of truth for identity.

Security teams often miss that tool-call identity is a runtime authorization boundary, not just an application design choice. Once an agent can invoke tools, the question becomes who is being authorized at the moment of action, with what session, and against which tenant context. NHIMG’s research on The State of MCP Server Security 2025 shows how weak tool scoping becomes a practical exposure when credentials and permissions are loosely handled. In practice, many security teams discover cross-tenant drift only after a tool call has already executed against the wrong account, rather than through intentional authorization testing.

How It Works in Practice

The safest pattern is to construct the tool surface per request, capture the authenticated user in server-side state, and keep that identity out of the model-visible parameter space. The application resolves the signed-in user from the session, access token, or request context, then injects that identity into a closure or server-side execution context that the agent cannot alter. That means the model can request an action, but it cannot nominate a different tenant, account, or principal.

This approach aligns with current guidance from the NIST AI Risk Management Framework, which emphasizes governed, traceable AI operation, and with NHIMG’s analysis of CoPhish OAuth Token Theft via Copilot Studio, where token misuse becomes the practical failure mode. A robust implementation usually includes:

• Server-side identity resolution from the authenticated session, not from prompt text or tool arguments.
• Per-request tool binding so the available tools inherit the active user context automatically.
• Tenant-scoped authorization checks on every tool execution, even if the request came from a trusted session.
• Short-lived, least-privilege tokens or delegated credentials for tools that reach external systems.
• Audit logs that record the human user, agent run, tool name, and resulting side effect.

For teams implementing MCP-style or agentic toolchains, this also reduces the blast radius of compromised prompts because the model only controls intent, not identity selection. The same logic applies whether the tool reads data, changes records, or triggers downstream automation. These controls tend to break down when applications share a global tool registry across tenants because identity and authorization state can leak between concurrent sessions.

Common Variations and Edge Cases

Tighter tool binding often increases implementation overhead, requiring organisations to balance isolation against developer ergonomics and latency. There is no universal standard for this yet, so current guidance suggests choosing the narrowest identity propagation model that still supports the user experience. In regulated or high-risk workflows, that usually means explicit per-request authorization and immutable server-side context rather than convenience-driven global agent state.

Edge cases appear when one signed-in user delegates work to another user, when service accounts act on behalf of a person, or when the agent chains multiple tools across internal and external systems. In those cases, the system should distinguish between the actor, the delegate, and the resource owner. A closure-based identity capture still works, but the authorization policy must understand delegation, approval, and scope. NHIMG’s The State of Non-Human Identity Security is useful context here because it highlights how over-privileged accounts and weak visibility drive real-world compromise.

Where this guidance is weakest is in distributed agent architectures that hand off work between services without a single authoritative session source, because identity can become fragmented across hops. In those environments, security teams should pair server-side identity capture with strong workload identity and explicit request tracing, using the model as a planner and the backend as the final decision maker.

Related resources from NHI Mgmt Group

• How should security teams govern multi-agent workflows that call external APIs?
• How should security teams test applications for multi-user authorization bugs?
• How should security teams implement scheduled agent access to third-party apps when no user is signed in?
• How should security teams decide whether JIT access is safe for non-human identities?