Multi-agent isolation

One agent is easy - the questions start with the second one: whether it can replay the first one's session, whether it shares the first one's rate limit and which tools it sees. The three agents below run against two MCP gateways, and each answer is a mechanism the platform enforces.

The layout

Three agents, three credentials, two gateways - support agents share the support tools, the billing agent alone reaches the billing ones:

security:
  - name: agent.support.alpha
    type: apikey
    username: support-alpha
    password: Zato_Enmasse_Env.Support_Alpha_Key

  - name: agent.support.beta
    type: apikey
    username: support-beta
    password: Zato_Enmasse_Env.Support_Beta_Key

  - name: agent.billing
    type: apikey
    username: billing-agent
    password: Zato_Enmasse_Env.Billing_Agent_Key

groups:
  - name: support-agents
    members:
      - agent.support.alpha
      - agent.support.beta

  - name: billing-agents
    members:
      - agent.billing

mcp_gateway:
  - name: support
    url_path: /mcp/support
    services:
      - example.support.get-ticket
      - example.support.list-tickets
    security_groups:
      - support-agents

  - name: billing
    url_path: /mcp/billing
    services:
      - example.billing.get-invoice
      - example.billing.find-invoices
    security_groups:
      - billing-agents

One credential per agent is the rule everything below builds on - a shared key is one identity, and one identity cannot be isolated from itself.

Tool visibility

Tool visibility is per gateway - every agent admitted to a gateway sees all of its tools. Isolating what agents see therefore means separate gateways, not separate credentials on one gateway:

The refusal happens at authentication, before any MCP processing - an agent outside a gateway's groups never learns what the gateway serves, not even the tool names.

Session isolation

If agent.support.beta somehow obtained alpha's Mcp-Session-Id - a leaked log, a shared proxy - replaying it is refused with HTTP 400, because sessions are bound to the identity that created them, and each identity has its own budget of live sessions per gateway.

Rate limits per credential

Alpha caught in a retry loop hits its own ceiling while beta's traffic flows on untouched - limits are per identity, which is also why an agent needing an independent budget needs its own credential, and the layout above already gives it one.

Audit per identity

Every audit log event names the identity the agent authenticated with, so listing everything the billing agent did yesterday is a filter, not an investigation.

Failure behavior

Offboarding one agent is one operation - remove its credential from the group, or delete the definition altogether. From that moment its requests answer with HTTP 403 and an auth-failed audit event, its live sessions are unusable since the identity no longer resolves, and no other agent is affected. There is no shared secret to rotate, because nothing was shared.

See also