Most Claude pilots start life inside a single company. The moment you package that pilot as a product and sell it to more than one customer, the questions change. Who can see whose data. What happens when one tenant sends ten thousand requests in an hour. How the token bill for a Melbourne logistics client gets separated from the bill for a Perth retailer on the same plan. This is the point where a lot of Australian SaaS teams building on Claude get stuck, not because the model is hard to use, but because multi-tenant plumbing was never designed in.
Why isolation has to be designed, not bolted on
A single-tenant Claude integration can get away with one API key, one system prompt, and one conversation history table. Add a second paying customer and every one of those assumptions becomes a liability. Prompt injection from Tenant A's uploaded document should never be able to reach Tenant B's context window. A support ticket about Tenant A's data should never surface an example drawn from Tenant B's account. None of this is exotic, but it has to be a deliberate layer in your architecture, not a side effect of how you happened to structure the database.
For Australian SaaS founders this has a compliance edge too. If your product touches personal information covered by the Privacy Act, tenant isolation is one of the controls a customer's security questionnaire will ask about directly, especially in regulated verticals like finance or health where APRA or AUSTRAC obligations sit upstream of your product.
Three isolation patterns for Claude-powered products
There is no single correct pattern. The right one depends on how many tenants you expect, how sensitive their data is, and how much engineering time you have. In practice, most teams land on one of three approaches.
Shared API key, tenant-scoped context: one Anthropic API key for the whole product, with every prompt, retrieved document, and conversation history strictly namespaced by tenant ID at the application layer. Cheapest to run, but every code path that touches Claude needs a tenant filter, and a single missed filter is a data leak.
Per-tenant API keys: each customer (or each pricing tier) gets its own Anthropic API key, issued and rotated through your own provisioning system. This gives you clean cost attribution and a natural blast-radius limit if a key is compromised, at the cost of key management overhead.
Dedicated workspace or project per tenant: for enterprise customers who demand contractual data separation, a distinct Anthropic Console project (or a fully separate cloud environment) per tenant is the strongest guarantee, and the one most likely to satisfy a Sydney-based enterprise procurement team doing due diligence.
Most products we build at Automata AI start on the first pattern and graduate individual enterprise accounts to the third as they sign, rather than choosing one pattern for every customer on day one.
Quota and rate-limit design per tenant
Anthropic's API applies rate limits at the account level, not automatically per tenant, so if you don't build your own quota layer, one noisy customer can degrade the experience for every other tenant on a shared key. The fix is a token bucket or sliding-window limiter that sits in front of every Claude call, keyed by tenant ID rather than by user ID, with separate ceilings for requests per minute and tokens per day.
What to track per tenant
Requests per minute, to catch runaway loops in a customer's own automation
Input and output tokens per day, mapped against their plan's included allowance
Concurrent in-flight requests, so one tenant can't starve the connection pool
Error and retry rate, which often flags a misconfigured integration before the customer notices
Soft limits that degrade gracefully (a slower model tier, a queued response) tend to produce fewer support tickets than hard limits that return an error, especially for tenants on the edge of their plan.
Billing: turning usage into a line item customers trust
Usage-based Claude costs don't map neatly onto the flat monthly pricing most Australian SaaS products still use. The teams that get this right meter token usage per tenant from day one, even before they charge for it, so they have real consumption data when they design a pricing tier rather than a guess. A practical approach: bundle a token allowance into the base subscription (say $99 a month including 2 million tokens), and bill overage at a small markup on Anthropic's list price, itemised on the invoice so finance teams can see exactly what they're paying for.
One Sydney-based SaaS client we worked with was absorbing an average of $6,400 a month in unbilled Claude usage across their customer base before they added per-tenant metering. After introducing tiered allowances and overage billing, that cost became a $38,000 annual revenue line instead of a margin leak, without changing a single feature.
A worked example: three tenants, one Claude account
Picture a practice-management SaaS selling to Australian accounting firms. Tenant A is a two-partner firm in Brisbane on the entry plan. Tenant B is a 40-person firm in Melbourne on the growth plan. Tenant C is a national firm with its own compliance team demanding a dedicated environment. The entry and growth tenants share an API key with tenant-scoped context and per-tenant quotas; token usage is metered and billed monthly. The national firm gets its own Anthropic Console project, its own rate limits, and a separate line in the vendor security register. Same product, three isolation postures, one engineering team maintaining all of it.
Where to start if none of this exists yet
You don't need to rebuild everything before your next release. Start by adding a tenant ID to every log line that touches Claude, so you can see usage per customer even before you act on it. Then add a basic per-tenant rate limiter in front of the API call. Metering and billing changes can follow once you have a few weeks of real consumption data to price against.
If you're weighing up which pattern fits your product, our Claude consultancy work is exactly this: getting the isolation, quota, and billing layer right before it becomes a customer-facing incident. Book a session and we'll map it against your current architecture.
