By Adam Wolf
Multi-tenancy is one of the most mature concepts in enterprise software. Two decades of SaaS, cloud, and platform engineering have produced well-tested patterns for partitioning shared infrastructure across customer organizations, internal teams, and engineering departments. All of those patterns rest on an assumption that has gone largely unexamined: that a tenant is a group of humans.
In 2026, that assumption no longer holds. The fastest-growing class of resource consumers inside the enterprise is not a team of people. It is a population of agents. Klique’s position is that those agents need the same isolation, quota, and policy machinery that humans get, applied per agent, and the right architectural commitment is that every agent is its own tenant.
This piece walks through why, what changes when you treat agents that way, and what the alternative looks like in practice.
The assumption multi-tenancy was built on
To see why agents break multi-tenancy, we need to understand exactly what multi-tenancy has historically meant. In the context of SaaS, a tenant is a customer organization with its own users, its own data, and its own contract. The isolation boundary is the customer. The shared infrastructure is the SaaS provider’s. Patterns for separating customers (row-level security, schema-per-tenant, database-per-tenant, namespace-per-tenant in vector stores) have matured over twenty years.
In Kubernetes, a tenant is typically a team or business unit, separated from other teams by namespaces, RBAC, network policies, and resource quotas. The shared infrastructure is the cluster. The isolation primitives are well-documented and widely deployed.
In IAM, a tenant maps to an identity provider, a directory, or an organization, with roles and policies attached to human users and the service accounts they manage.
Across all three cases, the unit of isolation is a group of humans. The behavior the isolation primitives are designed for is human behavior: a user logging in, a team running jobs, a customer organization issuing requests through an application. The rates of resource consumption, the failure modes, the lifecycle (employment, contract renewal, departmental reorganization), and the policy granularity are all sized for the way humans use systems.
What agents do that the assumption did not anticipate
An AI agent does not behave like a human user, a team, or a customer organization. It behaves like a process. That distinction has consequences for every isolation primitive multi-tenancy is built on.
Programmatic consumption rates
A human knowledge worker sends a few dozen LLM requests on a busy day. An agent in a reasoning loop can send hundreds per minute. A documented incident from November 2025 involved four LangChain agents coordinating via the A2A protocol, two of which (an Analyzer and a Verifier) began ping-ponging requests between themselves with no termination condition. The loop ran for 264 hours. The bill was $47,000. The team had observability. They did not have enforcement. A multi-tenancy design that assumes human consumption rates is sized for the wrong order of magnitude.
Failure modes that compound silently
Humans fail loudly. They submit a ticket, file a bug, page on-call. Agents fail quietly. Magicrails documented an agent that made 14,000 redundant list_files calls overnight before hitting a token quota, costing $437 for what should have been one operation. The agent did not crash. Every individual call was valid. The aggregate was pathological. An isolation primitive that assumes humans-notice-when-things-break is the wrong shape for this.
Fan-out amplification
A single human request to a multi-agent system can produce dozens of downstream calls. Industry analysis of agent runaway costs notes that an agent fanning out to four sub-agents who each fan out to four more produces 16× token spend per planning step. By step 20 in a loop with file reads, the input on each call can exceed 50,000 tokens. The unit of cost is no longer “what does this user generate” but “what does this agent’s reasoning tree generate,” and the two can differ by orders of magnitude.
Lifecycle decoupled from employment
A human user’s access ends when they leave the company. An agent’s access does not, unless something explicit revokes it. The agent runs on credentials that were issued by a human, often a personal API key, and those credentials can outlive the human’s relationship with the company. The traditional multi-tenancy lifecycle (provisioning, deprovisioning) does not have a story for the dependent population of agents that the departing human created.
Autonomous behavior under uncertainty
Humans escalate when uncertain. Agents retry. In one widely discussed incident from late 2025, a market research pipeline of four agents locked into a loop, an analyzer and a verifier trading requests for 11 days with no budget cap or termination condition, until the team found the $47,000 bill in its billing data. Every individual call was valid. The aggregate behavior was unbounded. A multi-tenancy design that assumes “the user will stop when they have what they need” is not modeling the right actor.
What “every agent is its own tenant” actually means
Klique’s architectural position is that the right unit of isolation for agentic workloads is the agent itself, not the team that built it or the user who runs it. Every agent gets its own tenant in the platform, with the same machinery that has historically been allocated to human-shaped tenants. That commitment shows up in five places.
Identity
Each agent receives a first-class identity in the same identity model that governs human users, federated through the enterprise identity provider. The agent is registered, named, and governable through the same surface that already manages employees. When a human invokes the agent, the call carries the agent’s identity alongside the human’s through end-to-end token pass-through, so audit logs show both the agent that did the work and the human on whose authority it acted.
Quotas and policy scope
Each agent has its own resource quota, its own access policies, and its own permission boundary. The quota is set per agent, enforced by the platform, and is the architectural answer to runaway costs. An agent that hits its ceiling stops at the platform layer rather than continuing to make calls that no one capped. The policies attached to the agent define what data and tools it can access, scoped per agent rather than inherited wholesale from whoever created it.
Audit trail
Each agent has its own audit boundary. Every model call, every tool invocation, every state mutation, every cross-agent handoff is logged against the agent’s identity, with the requesting human’s identity attached. The audit trail is per-agent, queryable, and exportable. Reconstructing what an agent did, why it did it, and on whose authority is a single query, not a cross-system investigation.
Lifecycle
Each agent has its own lifecycle managed by the platform. When a human user is offboarded, the agents they created do not automatically inherit orphan status; the platform tracks the dependency. Agents can be retired, replaced, or transferred to new owners through workflows the platform exposes, rather than being entangled in the credentials of a single human who may or may not still be at the company next year.
Isolation from other agents
Each agent runs within enterprise boundaries that the platform enforces, sharing infrastructure with other agents but isolated from them at the policy, quota, and runtime layers. One agent’s runaway behavior does not consume another agent’s budget. One agent’s misconfiguration does not exfiltrate data from another agent’s scope.
What changes operationally
Treating each agent as its own tenant changes a set of operational concerns that, under the human-tenant model, are either unaddressable or handled through workarounds.
RBAC works the same for agents and humans
The same role-based access control system that governs human users governs agents, because both are first-class identities in the platform. There is no parallel access control surface for AI workloads. The security team does not have to maintain two policy engines. The auditor does not have to reconcile two audit logs. The compliance answer to “who has access to what” is one query against one model.
Agent runaway costs become bounded
A per-agent quota with platform-level enforcement is structurally different from a per-team alert or a per-account budget. The $47,000 LangChain loop ran because no enforcement existed at the agent layer; the team had monitoring, and the bill arrived after the fact. A per-agent quota stops the loop at the agent boundary, before the next API call. The blast radius of a single misbehaving agent is bounded by what that agent was allocated, not by what the team’s aggregate budget could absorb.
Per-agent cost attribution becomes a primary key
When each agent is a tenant, every cost line item maps back to a specific agent, on a specific human’s authority, in a specific tenant context. Cost attribution stops being a tagging convention that engineers forget to follow and becomes a property of the platform. The finance team can answer “which agents are expensive and why” without a forensic exercise.
Offboarding becomes deterministic
When a human user is offboarded, the platform has the dependency graph: this user created these agents, these agents have these quotas and policies, these agents are currently running these workloads. Offboarding produces a structured set of decisions (retire, transfer, retain) rather than a manual investigation. The agents the departing human created either get assigned new owners or get shut down, but they do not silently continue running on credentials that should have been revoked.
Multi-agent systems become observable at the agent layer
When a planner agent fans out to sub-agents, each sub-agent is its own tenant, with its own quota, its own audit trail, and its own identity. The 16× fan-out amplification that drives runaway costs in multi-agent systems is visible per-component, attributable per-component, and bounded per-component. The aggregate behavior of the system is the sum of behaviors of agents that each have their own enforceable envelope.
How agent-as-tenant interacts with the four-tier governance model
Klique’s four-tier governance model (cluster admin, tenant admin, AI builder, AI consumer) is what makes agent-as-tenant operationally workable rather than a flat list of millions of independent tenants.
The cluster admin manages the underlying compute and the platform-level policies that govern what any tenant in the cluster can do. They set the ceiling on how much resource any single tenant can consume in the worst case, regardless of who that tenant is.
The tenant admin (typically a team lead, business unit owner, or platform owner) manages a logical tenancy, which can contain both human users and agents. They allocate quotas to the agents that operate under their tenancy, define the policies those agents have to follow, and approve the lifecycle decisions (creation, retirement, transfer) that apply within their scope.
The AI builder is the person who creates an agent. They define what the agent does, what tools it needs, and what data it accesses. The agent inherits its tenant context from the builder’s tenant, with the builder’s tenant admin approving its quota and policies.
The AI consumer invokes the agent. Their identity flows through the agent’s execution via end-to-end token pass-through, so the agent can act on the consumer’s behalf within the agent’s permission scope. The agent cannot exceed what the consumer is allowed to do, but neither can the consumer escalate the agent’s permissions beyond what its tenant admin approved.
The structure means that “every agent is its own tenant” does not mean “every agent is a free-standing organization.” Each agent is a tenant within a hierarchical governance model where humans in three different roles set the boundaries that agents operate within. The model preserves the human accountability that the enterprise actually wants while giving the agents the isolation primitives they actually need.
What this requires of the platform
The architectural commitment of agent-as-tenant is straightforward to state and substantial to implement. The platform has to provide several capabilities that most current AI infrastructure does not provide together in one place.
It has to maintain a first-class identity for every agent, federated with the enterprise identity provider so the agent shows up alongside human users in the same directory.
It has to enforce per-agent quotas synchronously, at the point of resource consumption, not as an alert that fires after the fact. The difference between “we got paged at 2am about a runaway agent” and “the agent stopped at its quota at 2am and we triaged in the morning” is the difference between observability and enforcement.
It has to provide per-agent audit trails that are integrated with the rest of the platform’s audit surface, so the agent’s actions are queryable from the same place the human’s actions are.
It has to maintain the dependency graph between humans and the agents they create, so offboarding is deterministic rather than improvised.
It has to expose the four-tier governance model in a way that makes the boundaries between roles enforceable, not just documented.
Klique’s position is that all of these capabilities belong together in one platform, because the alternatives (separate identity surfaces for agents, separate quota systems for AI workloads, separate audit logs for tool calls) reproduce the parallel-system problem that multi-tenancy was supposed to solve in the first place.
The question worth asking
Most enterprise platforms running agents in production today are doing so under one of two implicit models. Either agents share their creator’s identity and permissions (which means the runaway-cost incidents that have now been documented at $437, $4,200, $47,000, and $48,000 happen against the creator’s budget, with the creator’s permissions, in the creator’s audit trail), or agents share a service account that nobody is responsible for in particular (which means cost attribution and offboarding are organizationally unsolvable). Both models are extensions of the human-tenant assumption that multi-tenancy was built on, applied to a class of resource consumer that no longer fits the assumption.
The question worth asking is not whether to add more guardrails to the existing model. It is whether the existing model is the right model. Agent-as-tenant is the architectural answer to that question. It says that the unit of isolation, quota, policy, and audit for an agent should be the agent, not the human who created it or the team that operates it, because the agent is the actor doing the work, and the existing isolation primitives were not designed for the actor agents are.
Klique’s commitment to agent-as-tenant is what lets the rest of the platform’s machinery (identity federation, four-tier governance, end-to-end token pass-through, and per-tenant quotas) compose a coherent system. The pieces work together because the underlying assumption (every agent is its own tenant) is consistent across them. Anything less and the pieces compose a parallel access control surface for AI workloads, which is what most enterprises now have and what most enterprises are now realizing is not the durable answer.
If you would like to discuss how Klique’s agent-as-tenant architecture fits into your AI infrastructure roadmap, get in touch.
