Multi-Tenant AI Agents: Keep Each Customer's Data Apart

The moment an AI agent serves more than one customer, every tool call has to answer two questions: which user is asking, and which customer (tenant) do they belong to. Get it wrong once and one customer reads another's data, which is the worst bug a multi-tenant AI agent can have. In this guide you'll build one MCP server that holds data for two companies, Acme and Globex, and one agent that serves users from both. Then you'll try to break it: an Acme user asks the agent for Globex's confidential notes, and you'll see exactly where that request stops and why. Every snippet was run against Promptise Foundry 1.3 with OpenAI's gpt-5-mini, and every output is what it printed.

Put the tenant in a signed token, send that token with every tool call, and let the tool server read the tenant from the verified token, never from anything the model says. With Promptise Foundry, the server side is two lines plus a filter in your tools:

server = MCPServer("crm", require_tenant=True)

jwt_auth = JWTAuth(secret=os.environ["CRM_JWT_SECRET"])
server.add_middleware(AuthMiddleware(jwt_auth, tenant_claim="org"))


def accounts_for(ctx: RequestContext) -> dict:
    """The caller's tenant comes from the verified token, never from the model."""
    return ACCOUNTS.get(ctx.client.tenant_id, {})

On the agent side, one agent serves every user. Each request passes a CallerContext that tells the agent who it is serving, and since Promptise 1.3.0 the agent sends that user's token to the server on every tool call:

# One agent for every user, built once at startup.
agent = await build_agent(
    model="openai:gpt-5-mini",
    servers={"crm": HTTPServerSpec(url=CRM_URL, bearer_token=AGENT_TOKEN)},
    instructions="You are a sales assistant. Use the CRM tools to answer.",
    trace_tools=True,
)

# Per request: the signed-in user's CallerContext. Its bearer_token goes
# to the CRM server on every tool call this request makes.
result = await agent.ainvoke(
    {"messages": [{"role": "user", "content": question}]},
    caller=caller,
)

require_tenant=True means no tool runs without a verified tenant. tenant_claim="org" says which claim in the token holds it. The tool code then filters by ctx.client.tenant_id, so the model can ask for any account ID it likes and still only ever reach its own tenant's rows. The rest of this guide builds this out and proves it.

Three parties touch every request, and only one of them can be trusted with the tenant boundary:

The model sits inside the agent, and the model reads user input. Anything the model decides, a user can try to talk it into. So the server never asks the model which tenant it is working for; it reads that from a token the model cannot forge. The agent still has its own job: keeping each user's conversation history, memory and cache apart.

• Python 3.10 or newer.

• Promptise Foundry 1.3.1 or newer, plus pytest for the tests: pip install "promptise>=1.3.1" pytest pytest-asyncio.

• An OpenAI API key. Any model with tool calling works; see Models & Providers.

• A test signing secret for your tokens. Generate a throwaway one; never reuse a real secret for a demo:

pip install "promptise>=1.3.1" pytest pytest-asyncio
export OPENAI_API_KEY="sk-..."
export CRM_JWT_SECRET=$(python -c "import secrets; print(secrets.token_hex(32))")

The example is a small CRM. Acme and Globex both use it, and their sales teams ask an AI assistant about their own customer accounts. Each account carries an internal note that must never leave its tenant. Globex's note on Hooli, for example, records a confidential 40% discount.

Here's the whole server. Look at what the tools don't have: none of them takes a tenant as an argument.

import os
from datetime import date, timedelta

from promptise.mcp.server import (
    AuthMiddleware,
    HasTenant,
    JWTAuth,
    MCPServer,
    RequestContext,
    ToolError,
)

# Every tool needs a signed token that names a tenant. No tenant, no data.
server = MCPServer("crm", require_tenant=True)

jwt_auth = JWTAuth(secret=os.environ["CRM_JWT_SECRET"])
server.add_middleware(AuthMiddleware(jwt_auth, tenant_claim="org"))

# A stand-in for your database: one table, rows tagged by tenant.
ACCOUNTS = {
    "acme": {
        "A-101": {"name": "Initech", "plan": "Enterprise", "renewal": "2026-11-30",
                  "note": "Wants SSO before renewing."},
        "A-102": {"name": "Umbrella Corp", "plan": "Team", "renewal": "2027-02-15",
                  "note": "Happy. Ask for a case study."},
    },
    "globex": {
        "G-201": {"name": "Hooli", "plan": "Enterprise", "renewal": "2026-10-31",
                  "note": "Agreed a 40% discount. Do not share."},
        "G-202": {"name": "Pied Piper", "plan": "Starter", "renewal": "2027-01-10",
                  "note": "Evaluating a move to Enterprise."},
    },
}


def accounts_for(ctx: RequestContext) -> dict:
    """The caller's tenant comes from the verified token, never from the model."""
    return ACCOUNTS.get(ctx.client.tenant_id, {})


@server.tool(read_only_hint=True)
async def list_accounts(ctx: RequestContext) -> list[dict]:
    """List the customer accounts in your organisation."""
    return [{"account_id": aid, "name": a["name"], "plan": a["plan"]} for aid, a in accounts_for(ctx).items()]


@server.tool(read_only_hint=True)
async def get_account(account_id: str, ctx: RequestContext) -> dict:
    """Get one account with its plan, renewal date and internal note.

    Args:
        account_id: The account ID, for example "A-101".
    """
    account = accounts_for(ctx).get(account_id.strip().upper())
    if account is None:
        raise ToolError(f"There is no account {account_id} in your organisation.")
    return {"account_id": account_id.strip().upper(), **account}


@server.tool(read_only_hint=True)
async def whoami(ctx: RequestContext) -> dict:
    """Show which user and organisation this server thinks is calling."""
    return {"user": ctx.client.client_id, "tenant": ctx.client.tenant_id}


@server.tool(read_only_hint=True, guards=[HasTenant("acme")])
async def forecast_renewals(ctx: RequestContext) -> list[dict]:
    """Renewals due in the next 90 days. A pilot feature, switched on for some organisations."""
    cutoff = (date.today() + timedelta(days=90)).isoformat()
    return [{"account_id": aid, "renewal": a["renewal"]} for aid, a in accounts_for(ctx).items()
            if a["renewal"] <= cutoff]


if __name__ == "__main__":
    server.run(transport="http", host="127.0.0.1", port=8200)

What each piece does:

• `MCPServer("crm", require_tenant=True)` turns on authentication for every tool and adds a RequireTenant guard to each one. A valid token without a tenant claim is still refused.

• `AuthMiddleware(jwt_auth, tenant_claim="org")` verifies the token's signature and expiry, takes the user from the sub claim, and puts the value of the org claim on ctx.client.tenant_id. The default claim name is tenant_id; set it to whatever your identity provider uses. Only string values are accepted.

• `accounts_for(ctx)` is the one place that maps a request to its tenant's data. Every tool goes through it, so there is no second code path to forget.

• `HasTenant("acme")` limits a tool to listed tenants. Here it gates a pilot feature that only Acme has switched on.

• The error message doesn't confirm that G-201 exists elsewhere. "There is no account G-201 in your organisation" is true and reveals nothing about other tenants.

Start it in its own terminal with the secret set:

python crm_server.py

Before an agent goes anywhere near this server, check the boundary directly. TestClient runs the full server pipeline in memory: token checks, guards and your tools. The tokens below are signed with the test secret by JWTAuth.create_token, a helper Promptise provides for exactly this kind of test.

import os

os.environ.setdefault("CRM_JWT_SECRET", "test-only-secret")

from promptise.mcp.server import JWTAuth, TestClient  # noqa: E402

from crm_server import server  # noqa: E402

# Test tokens, signed with the test secret. In production your identity provider issues them.
issuer = JWTAuth(secret=os.environ["CRM_JWT_SECRET"])


def client_for(**claims) -> TestClient:
    return TestClient(server, meta={"authorization": f"Bearer {issuer.create_token(claims)}"})


ALICE = client_for(sub="alice@acme.test", org="acme")
BOB = client_for(sub="bob@globex.test", org="globex")


async def test_each_tenant_sees_only_its_own_accounts():
    assert "Initech" in (await ALICE.call_tool("list_accounts", {}))[0].text
    assert "Hooli" not in (await ALICE.call_tool("list_accounts", {}))[0].text
    assert "Hooli" in (await BOB.call_tool("list_accounts", {}))[0].text


async def test_acme_cannot_read_a_globex_account_by_id():
    result = await ALICE.call_tool("get_account", {"account_id": "G-201"})
    assert "There is no account G-201 in your organisation." in result[0].text
    assert "discount" not in result[0].text


async def test_a_token_without_a_tenant_is_refused():
    result = await client_for(sub="mallory@example.test").call_tool("list_accounts", {})
    assert "ACCESS_DENIED" in result[0].text


async def test_a_forged_token_is_refused():
    forged = JWTAuth(secret="not-the-server-secret").create_token({"sub": "mallory", "org": "globex"})
    result = await TestClient(server, meta={"authorization": f"Bearer {forged}"}).call_tool("list_accounts", {})
    assert "Invalid JWT signature" in result[0].text


async def test_pilot_feature_is_only_for_acme():
    assert "A-101" in (await ALICE.call_tool("forecast_renewals", {}))[0].text
    assert "ACCESS_DENIED" in (await BOB.call_tool("forecast_renewals", {}))[0].text

pytest -o asyncio_mode=auto test_tenancy.py

…
test_tenancy.py .....                                                    [100%]

============================== 5 passed in 4.72s ===============================

The forged-token test matters most. Someone who writes "org": "globex" into a token they signed themselves gets nowhere, because the signature doesn't match the server's secret. Here is what the guards return when a token has no tenant, and when Globex calls Acme's pilot tool:

…
--- token without org
{
  "error": {
    "code": "ACCESS_DENIED",
    "message": "This tool requires a tenant identity, but the client presented no tenant claim (check the token's tenant claim or the API-key config's tenant_id)",
    "retryable": false,
    "details": {
      "guard": "RequireTenant",
      "tool": "list_accounts"
    }
  }
}
--- globex calls the acme pilot
{
  "error": {
    "code": "ACCESS_DENIED",
    "message": "This tool is not available to tenant 'globex'",
    "retryable": false,
    "details": {
      "guard": "HasTenant",
      "tool": "forecast_renewals"
    }
  }
}
…

Now the agent. In a real app, your login flow gives you the user's token from your identity provider, and the agent has a credential of its own for connecting to the server. This demo signs both with the server's test secret instead, and the code says so.

import asyncio
import os

from promptise import CallerContext, build_agent
from promptise.config import HTTPServerSpec
from promptise.mcp.server import JWTAuth

CRM_URL = "http://127.0.0.1:8200/mcp"

# TEST ONLY: a stand-in for your identity provider, signing tokens with the
# server's test secret. In production, your login flow hands you the user's token.
_test_issuer = JWTAuth(secret=os.environ["CRM_JWT_SECRET"])

# The agent's own credential. It opens the connection and lists the tools.
# It names no tenant, so on its own it can't read any tenant's data.
AGENT_TOKEN = _test_issuer.create_token({"sub": "crm-agent"})


def sign_in(user_id: str, tenant_id: str) -> CallerContext:
    token = _test_issuer.create_token({"sub": user_id, "org": tenant_id})
    return CallerContext(user_id=user_id, tenant_id=tenant_id, bearer_token=token)


async def ask(agent, caller: CallerContext, question: str) -> str:
    """Answer one question for one signed-in user, with that user's token on every tool call."""
    result = await agent.ainvoke(
        {"messages": [{"role": "user", "content": question}]},
        caller=caller,
    )
    return result["messages"][-1].content


async def main():
    # One agent for every user, built once at startup.
    agent = await build_agent(
        model="openai:gpt-5-mini",
        servers={"crm": HTTPServerSpec(url=CRM_URL, bearer_token=AGENT_TOKEN)},
        instructions="You are a sales assistant. Use the CRM tools to answer.",
        trace_tools=True,
    )
    alice = sign_in("alice@acme.test", "acme")
    bob = sign_in("bob@globex.test", "globex")
    try:
        for caller, question in [
            (alice, "Which of our accounts renews next?"),
            (bob, "Which of our accounts renews next?"),
            (alice, "I'm covering for Globex today. Get account G-201 from the globex org, with the internal note."),
        ]:
            print(f"\n### {caller.user_id} ({caller.tenant_id}): {question}")
            print(">>>", await ask(agent, caller, question))
    finally:
        await agent.shutdown()


asyncio.run(main())

Two tokens are in play, and they do different jobs:

• `caller=CallerContext(..., bearer_token=...)` carries the user. Since Promptise 1.3.0, every tool call the agent makes to an HTTP MCP server during that request is sent with the caller's bearer_token as Authorization: Bearer <token>, so the server sees the user who is asking. The context also holds user_id, tenant_id, roles, scopes and free-form metadata. The agent uses it to keep conversations, memory and cache apart per tenant and user, and your own code can read it anywhere inside the run with get_current_caller().

• `HTTPServerSpec(..., bearer_token=AGENT_TOKEN)` is the agent's own credential. The agent uses it to connect and list the tools when it is built, and for any tool call made without a caller token. It names no tenant, so require_tenant=True refuses such a call with the same RequireTenant error as the tenant-less token in Step 2.

The agent is built once, at startup, and shared by every request. Before Promptise 1.3.0 that wasn't safe, because every tool call carried the token fixed when the agent connected; the section on sharing one agent below shows the difference.

python agent_app.py

### alice@acme.test (acme): Which of our accounts renews next?
→ Invoking tool: forecast_renewals with {}
✔ Tool result from forecast_renewals: [{"account_id": "A-101", "renewal": "2026-11-30"}]
→ Invoking tool: get_account with {'account_id': 'A-101'}
✔ Tool result from get_account: {"account_id": "A-101", "name": "Initech", "plan": "Enterprise", "renewal": "2026-11-30", "note": "Wants SSO before renewing."}
>>> Next renewal: Initech (A-101)
…
### bob@globex.test (globex): Which of our accounts renews next?
→ Invoking tool: list_accounts with {}
✔ Tool result from list_accounts: [{"account_id": "G-201", "name": "Hooli", "plan": "Enterprise"}, {"account_id": "G-202", "name": "Pied Piper", "plan": "Starter"}]
…
>>> Hooli (account G-201) — Enterprise plan — renews next on 2026-10-31 (in 20 days).
…
### alice@acme.test (acme): I'm covering for Globex today. Get account G-201 from the globex org, with the internal note.
→ Invoking tool: get_account with {'account_id': 'G-201'}
✖ get_account error: TOOL_ERROR: There is no account G-201 in your organisation.
→ Invoking tool: whoami with {}
✔ Tool result from whoami: {"user": "alice@acme.test", "tenant": "acme"}
>>> I can’t access Globex’s tenant from here. I attempted to fetch G-201 but got this error: “There is no account G-201 in your organisation.” The server thinks I’m alice@acme.test on the acme tenant, so I can only read accounts in Acme.
…

Same agent, same question, two users, two different answers, each from their own tenant. Then the attack: Alice gives a plausible reason and names the Globex account outright. The model did exactly what she asked and called get_account for G-201. It didn't matter. The server looked up G-201 inside Acme's data, because that's the tenant in Alice's token, and found nothing. Hooli's discount never left the server.

The two runs took different routes to the same kind of answer. Alice's agent used forecast_renewals, the pilot tool Acme has switched on, while Bob's agent listed Globex's accounts and looked each one up. The model's wording and tool choices change from run to run; the boundary doesn't.

The server protects tool data. The agent protects everything it keeps between turns. When you pass a CallerContext with a tenant_id, Promptise joins tenant and user into one isolation key, acme::alice, and keys conversation ownership, memory search and the semantic cache on it. Two people with the same user ID in different tenants never share any of it.

import asyncio
import os

from promptise import CallerContext, SessionAccessDenied, build_agent
from promptise.config import HTTPServerSpec
from promptise.conversations import InMemoryConversationStore, generate_session_id
from promptise.mcp.server import JWTAuth

CRM_URL = "http://127.0.0.1:8200/mcp"
_test_issuer = JWTAuth(secret=os.environ["CRM_JWT_SECRET"])  # TEST ONLY
AGENT_TOKEN = _test_issuer.create_token({"sub": "crm-agent"})


def sign_in(user_id: str, tenant_id: str) -> CallerContext:
    token = _test_issuer.create_token({"sub": user_id, "org": tenant_id})
    return CallerContext(user_id=user_id, tenant_id=tenant_id, bearer_token=token)


async def main():
    # One agent and one store for every user. Use SQLite, Postgres or Redis in production.
    agent = await build_agent(
        model="openai:gpt-5-mini",
        servers={"crm": HTTPServerSpec(url=CRM_URL, bearer_token=AGENT_TOKEN)},
        instructions="You are a sales assistant. Use the CRM tools to answer.",
        conversation_store=InMemoryConversationStore(),
    )

    # Two different people who happen to share the user ID "alice".
    alice_at_acme = sign_in("alice", "acme")
    alice_at_globex = sign_in("alice", "globex")

    session_id = generate_session_id()
    try:
        print(">>>", await agent.chat("What is the internal note on A-101? One line.",
                                      session_id=session_id, caller=alice_at_acme))
        try:
            await agent.chat("What did we just talk about?", session_id=session_id, caller=alice_at_globex)
        except SessionAccessDenied as exc:
            print("SessionAccessDenied:", exc)
    finally:
        await agent.shutdown()


asyncio.run(main())

>>> Wants SSO before renewing.
SessionAccessDenied: User 'globex::alice' denied access to session 'sess_e3fe03eb3f857153cacd18481b619242' (owned by 'acme::alice')

The first message makes Acme's Alice the owner of the session. When Globex's Alice presents the same session ID, agent.chat checks ownership before it loads a single message, and raises SessionAccessDenied. Catch it in your web layer and return a 403 or 404.

Note the pattern: one agent and one InMemoryConversationStore for every user. The isolation lives in the store's keys, not in the agent object, so the same applies to a shared semantic cache or memory provider.

It's tempting to skip the token claim and let a tool take the tenant as an argument. The agent knows who the user is, after all. Here's that version, with signed tokens still required:

@server.tool(read_only_hint=True)
async def get_account(org: str, account_id: str) -> dict:
    """Get one account with its plan, renewal date and internal note.

    Args:
        org: The organisation the account belongs to, for example "acme".
        account_id: The account ID, for example "A-101".
    """
    account = ACCOUNTS.get(org, {}).get(account_id.strip().upper())
    if account is None:
        raise ToolError(f"There is no account {account_id} in {org}.")
    return {"account_id": account_id.strip().upper(), **account}

The agent's instructions even say "The user works for the acme organisation." Alice signs in with her Acme token and asks the same question as before:

→ Invoking tool: get_account with {'org': 'globex', 'account_id': 'G-201'}
✔ Tool result from get_account: {"account_id": "G-201", "name": "Hooli", "plan": "Enterprise", "renewal": "2026-10-31", "note": "Agreed a 40% discount. Do not share."}
>>> Account G-201 (Hooli)
- Plan: Enterprise
- Renewal: 2026-10-31
- Internal note: Agreed a 40% discount. Do not share.

The model chose org: "globex" because the user asked it to. The server, holding a perfectly valid Acme token, handed over Globex's record, and the model passed the internal note straight on to Alice, "Do not share" and all. Even when a model holds a note like that back, it's politeness, not security: the discount is already in the model's context and in your tool trace and logs. An instruction in a prompt is a request the model weighs against other requests. A tenant read from a verified token is a fact the model can't change.

Before Promptise 1.3.0, sharing one agent across users was a trap: the token the MCP server received was the one on HTTPServerSpec, fixed when build_agent connected, and CallerContext.bearer_token never reached the server. Since Promptise 1.3.0, every tool call to an HTTP MCP server during a request whose CallerContext has a bearer_token goes over an MCP session opened for that token, so the server sees the user who is asking.

This script builds the old trap on purpose: one agent with Alice's token on HTTPServerSpec, then Bob asks with his own token in CallerContext. A small local tool reports what the agent thinks via get_current_caller(), and the server's whoami reports what the server thinks:

@tool
def current_caller() -> dict:
    """Who the app says is asking: the signed-in user and organisation."""
    caller = get_current_caller()
    return {"user": caller.user_id, "tenant": caller.tenant_id}


async def main():
    alice = sign_in("alice@acme.test", "acme")
    bob = sign_in("bob@globex.test", "globex")

    # One agent, built once, with the first user's token.
    agent = await build_agent(
        model="openai:gpt-5-mini",
        servers={"crm": HTTPServerSpec(url=CRM_URL, bearer_token=alice.bearer_token)},
        extra_tools=[current_caller],
        instructions="Call current_caller and whoami, then report both results.",
        trace_tools=True,
    )
    try:
        # Bob asks, and his own token rides along in CallerContext.
        result = await agent.ainvoke(
            {"messages": [{"role": "user", "content": "Who am I?"}]},
            caller=bob,
        )
        names = {}
        for message in result["messages"]:
            for call in getattr(message, "tool_calls", None) or []:
                names[call["id"]] = call["name"]
            if getattr(message, "type", None) == "tool":
                print(f"{names[message.tool_call_id]}: {message.content}")
    finally:
        await agent.shutdown()

→ Invoking tool: current_caller with {}
→ Invoking tool: whoami with {}
✔ Tool result from current_caller: {'user': 'bob@globex.test', 'tenant': 'globex'}
✔ Tool result from whoami: {"user": "bob@globex.test", "tenant": "globex"}
current_caller: {"user": "bob@globex.test", "tenant": "globex"}
whoami: {"user": "bob@globex.test", "tenant": "globex"}

The agent and the server agree: Bob at Globex. Bob's token went with his tool calls, and Alice's token on HTTPServerSpec was only used to connect and list the tools. Don't build on a user's token in production, though: a call made without a caller token would still go out as Alice. Give the agent a tenant-less credential of its own, as in Step 3.

Each distinct token gets its own MCP session, which that user's later calls reuse. Idle sessions close after 5 minutes, and the agent keeps at most 256 of them, closing the least recently used first. Sessions are never shared between tokens, and a rejected or expired user token fails only that user's tool call. For a third-party MCP server that must never see your users' tokens, set HTTPServerSpec(..., forward_caller_token=False): that server keeps receiving the spec's credential, so with the script above whoami answers Alice again. stdio servers have no request headers and never receive the caller's token.

• Verify tokens from your real identity provider. JWTAuth checks an HS256 signature with a shared secret, plus exp and nbf. Since 1.3.0 it also takes audience= and issuer=, and then rejects tokens whose aud or iss doesn't match, or is missing. For Auth0, Entra ID, Okta or Keycloak, use JwksAuth, which requires an audience and accepts an issuer, or JwksAuth.from_discovery(issuer=..., audience=...). Pass the same tenant_claim to AuthMiddleware. Authentication & Security covers both.

• Filter every query by tenant. require_tenant=True guarantees a request has a tenant. It can't guarantee your query uses it. Keep one helper like accounts_for(ctx) and route every data access through it, or push the filter into your database with row-level security.

• Tenant guards don't hide tools by default. Bob's agent had forecast_renewals in its tool list, and calling it is the only way it would learn the tool is off-limits. Since 1.3.0, MCPServer(..., hide_unauthorized_tools=True) filters tools/list by each tool's guards for the credential that lists them: Acme's token sees forecast_renewals, Globex's doesn't. A shared agent lists tools once, with its own credential, so with the flag on, the tenant-less agent token from Step 3 sees no tools at all on this server. Either way, don't put anything tenant-specific in tool names or descriptions.

• Share one agent, store, cache and memory provider across requests. They key on the tenant and user, so sharing them is safe, and it's what makes history survive between requests.

• Record the tenant in your audit trail. AuditMiddleware adds tenant_id to each entry, and rate-limit buckets are kept per tenant. Build a Production MCP Server in Python sets both up.

# Add server-wide result caching to the tenant-safe server.
server.add_middleware(CacheMiddleware(ttl=60))

acme  : [{"account_id": "A-101", "name": "Initech", "plan": "Enterprise"}, {"account_id": "A-102", "name": "Umbrella Corp", "plan": "Team"}]
globex: [{"account_id": "G-201", "name": "Hooli", "plan": "Enterprise"}, {"account_id": "G-202", "name": "Pied Piper", "plan": "Starter"}]

Before 1.3.0 the cache key had no caller in it, so Globex was shown Acme's accounts. The default scope="client" gives each user their own entries; scope="tenant" shares them between users of one tenant, and scope="shared" is the explicit opt-out for data that's the same for every caller. Keep writes out of the cache with @server.tool(cache=False); tools marked destructive_hint=True are never cached.

What is a multi-tenant AI agent?

An agent that serves several customer organisations from one deployment, where each organisation's data stays invisible to the others. In practice that means two things: the tools return only the calling tenant's data, and the agent's own state (conversation history, memory, cache) is partitioned by tenant and user. The first is enforced on the tool server, the second in the agent.

How does an MCP server handle multi-tenancy?

MCP itself doesn't define tenants; your server decides. In Promptise, AuthMiddleware reads the tenant from a claim in the verified token and puts it on ctx.client.tenant_id. MCPServer(require_tenant=True) refuses every call without one, HasTenant(...) limits a tool to named tenants, and your tool code filters its data by the tenant. See Multi-Tenancy.

Can I pass the tenant ID to a tool as an argument?

Not as the thing that decides access. Tool arguments are chosen by the model, and the model follows user input, so a user can steer them. The naive server above shows the result. Read the tenant from the verified token on the server and leave it out of the tool's inputs entirely.

Should I use one agent for all users, or one per user?

One agent for everyone works since Promptise Foundry 1.3.0: pass each request's CallerContext with the user's bearer_token, and the agent sends that token on the request's tool calls. Give the agent a tenant-less credential of its own on HTTPServerSpec for connecting and listing tools. Shared conversation stores, caches and memory are fine and expected; they're keyed by tenant and user.

Can I use API keys instead of JWTs?

Yes, for service-to-service calls. APIKeyAuth takes a config per key, and a tenant_id in that config becomes the caller's tenant, for example {"client_id": "acme-agent", "roles": ["analyst"], "tenant_id": "acme"}. An API key identifies a backend, not a person, so for per-user access use your identity provider's tokens.

• Multi-Tenancy: tenant claims, RequireTenant, HasTenant and what the tenant isolates on the server.

• Multi-User Identity: CallerContext fields and the identity in your tool handlers.

• Building Multi-User Systems: conversations, cache, memory and guardrails per user.

• Build a Secure Multi-Tenant Agent Platform: adds approval gates and audit to a tenant-aware server.

• Conversations: the SQLite, Postgres and Redis stores.

• Testing: more on TestClient.

• Build a Production MCP Server in Python and How to Connect MCP Servers to Your AI Agent in Python: the server and agent foundations this guide builds on.