Most SaaS products already know how to separate customers.
The database knows which records belong to which tenant. Authentication knows who the user is. APIs check permissions before returning data or allowing an action.
AI agents introduce another layer that has to respect those same boundaries.
AWS highlighted this problem in a new implementation published on August 7, showing how Cohere Health built a multi-tenant agentic architecture for its Policy Studio product. The architecture combines isolated agent runtimes, controlled tool access, agent memory, and modular skills while maintaining human oversight and version control.
The interesting part is not simply that the system uses AI agents. It is how tenant isolation has to continue across everything the agent does.
Tenant Isolation Now Extends Beyond the Database
In a traditional SaaS application, a user makes a request and the backend checks their identity before accessing the right customer data.
An agent works differently.
It may receive a request, retrieve previous context, inspect data, choose a tool, call an API, interpret the result, and then take another action. A single user request can therefore move through several different systems before the task is complete.
That means tenant isolation cannot stop at tenant_id in the database.
The user's tenant identity needs to remain attached to the entire execution path. Context retrieved for the agent must belong to the correct tenant. Memory must remain scoped to the right customer and user. Credentials used for downstream actions must carry the correct permissions.
AWS's AgentCore documentation provides one example of runtime-level isolation. Individual sessions run inside dedicated microVM environments with isolated CPU, memory, and filesystem resources.
The broader principle matters regardless of the infrastructure being used: an agent should never have to infer which customer's environment it is operating inside.
Knowing About a Tool Is Not Permission to Use It
This becomes more important when the agent can take actions.
Imagine a SaaS platform exposes APIs for creating accounts, changing subscriptions, sending messages, processing claims, updating appointments, or modifying customer records.
The agent may technically know that all of these capabilities exist. That does not mean every user, tenant, or agent session should have access to them.
There are three different questions:
- An API may exist in the product.
- The API may be exposed as a tool to the agent.
- The current user may actually be authorized to execute that tool.
Those are not the same thing.
Cohere Health's architecture uses AgentCore Gateway as the controlled access point for tools, including policy APIs exposed through MCP. This illustrates a useful implementation pattern: tool availability and tool authorization should be controlled outside the model's reasoning whenever possible.
The model can decide what action would help complete the task. The surrounding system still needs to decide whether that action is allowed for this tenant, user, and workflow.
Multi-Tenancy Becomes Part of Agent Architecture
The important shift is easy to miss.
When SaaS products add agents, multi-tenancy is no longer only a database and authentication problem. It becomes part of the agent's context architecture and execution architecture.
Identity has to remain trustworthy while the agent reasons. Memory needs explicit tenant boundaries. Tools need scoped access. Credentials need to represent the user or service that is actually allowed to act. Traces and audit records also need to show which tenant, user, agent, and action were involved.
Cohere Health's recent implementation is useful because it shows these concerns appearing together in a real agentic system: isolated runtime sessions, controlled tool access, memory, modular agent skills, version management, and human oversight.
For SaaS teams moving from AI features toward agents that can operate the product, this is becoming an important architecture question.
Your application may already be multi-tenant.
The next question is whether the entire agent execution path is multi-tenant too.
At SaaStoAgent, we pay close attention to this layer because turning product APIs into agent capabilities creates responsibilities that do not exist in a simple AI assistant. The agent needs the right context, the right tools, the right permissions, and a clear execution boundary before it should be trusted to act inside a customer's product environment.
