- In short
- In a multi-tenant deployment, a shared API key across tenants makes it impossible to attribute a rate-limit breach or cost spike to the tenant that caused it. Separate API keys per tenant provide both isolation, so one tenant's load cannot silently exhaust another's budget, and attribution, so the source of a spike is identifiable. Without per-tenant keys, an organisation-level rate-limit trip is visible but its source is not, and request-level logging alone does not close that gap.
Why the credential boundary defines the tenant boundary
In a multi-tenant deployment, many customers share one Claude integration, and a design decision that looks purely operational, which API key to use, turns out to govern isolation and attribution. The exam treats this at the analyse level: you need to reason about what a shared key does to your ability to contain and diagnose problems. A single API key shared across all tenants pools their traffic into one bucket for the purposes of rate limits and cost accounting. That pooling is the root of both failures the topic cares about.
The alternative is separate API keys per tenant. Now each tenant's traffic is accounted against its own credential, which means the credential boundary lines up with the tenant boundary. That alignment is what makes both isolation and attribution possible. It is worth seeing this as one decision with two payoffs rather than two separate features.
- Per-tenant API key isolation
- Assigning each tenant in a multi-tenant deployment its own API key so that rate-limit consumption and cost are accounted per tenant. This provides isolation (one tenant's load cannot exhaust another's budget) and attribution (a rate-limit breach or cost spike can be traced to its source tenant), neither of which a shared key can offer.
Attribution: knowing which tenant caused it
Picture the shared-key world when something goes wrong. The organisation-level rate limit trips at peak, or the monthly bill spikes. With one key, all you can see is that the aggregate limit was hit or the aggregate cost rose. The signal is real but sourceless: you know something happened, but not which tenant's traffic caused it. You cannot tell a runaway integration at tenant A from a legitimate surge at tenant B, because their requests were never accounted separately.
Per-tenant keys make the source legible. Each tenant's consumption is tracked against its own key, so a spike shows up attributed to the specific tenant driving it. That is the difference between "the org limit tripped" and "tenant A's key is at 300% of its usual rate." Attribution turns an alarm into an actionable diagnosis.
Isolation: containing one tenant's load
Attribution is about seeing the source after the fact; isolation is about preventing one tenant's problem from becoming everyone's. Under a shared key, all tenants draw down the same pooled rate-limit and budget allowance, so a single tenant running hot can consume the shared headroom and starve every other tenant, silently, until the pooled limit trips for all of them. One tenant's bad day becomes a shared outage.
Separate keys wall the tenants off from each other. Tenant A's surge draws down tenant A's allowance and trips tenant A's limit, leaving the others unaffected. The blast radius of a single tenant's load is contained to that tenant. This is the same containment logic as scoping subagent tool access, applied to rate-limit and budget consumption rather than to capability.
What the exam trips candidates on
Two traps recur. The first is assuming request-level logging alone is enough for tenant attribution without separate credentials; logs can show traffic, but the rate-limit and budget accounting stay pooled under a shared key, so the organisation-level trip remains sourceless in the terms that matter. The second is sharing a single key across tenants to simplify key management, trading away isolation and attribution for convenience. The credited answer uses per-tenant keys and names both the isolation and attribution reasons.
Worked example
A SaaS company runs one Claude integration for all its customers behind a single shared API key. It logs every request with a tenant ID. One afternoon the organisation-level rate limit trips at peak and every customer's assistant stops responding. The team says their per-request tenant-ID logging will let them attribute the cause. Evaluate.
The shared key is the root problem, and the team's confidence in logging is the first trap. Tagging each request with a tenant ID does help you see traffic volumes, but the rate limit and the budget were consumed against one pooled credential, so the limit that tripped is an organisation-level limit with no per-tenant accounting behind it. You can look at the logs afterward and estimate which tenant sent the most requests, but the enforcement that actually failed, the shared rate limit, had no notion of tenants, which is why every customer went down together. The logging gives a retrospective guess at volume, not the clean isolation and attribution the situation needs.
Two things were missing, and both are what per-tenant keys provide. Isolation: had each tenant used its own key, the surging tenant would have tripped only its own limit, and the other customers' assistants would have kept running. Attribution: the spike would have shown up directly against the offending tenant's key rather than as a sourceless org-level trip that logs can only approximate. The fix is to issue a separate API key per tenant so the credential boundary matches the tenant boundary. Request-level tenant logging is a useful complement for observability, but it is not a substitute for the credential isolation that contains and attributes a rate-limit event.
Common misreadings to avoid
Misconception
Per-request tenant-ID logging is enough to attribute a rate-limit breach, so a shared API key is fine.
What's actually true
Misconception
Sharing one API key across all tenants is a reasonable simplification of key management.
What's actually true
How this shows up on the exam
Expect a multi-tenant scenario with a shared key, often defended by request logging, and a rate-limit or cost event with no clear source. The reliable reading is that per-tenant keys are required for both isolation and attribution, and that logging does not substitute for credential separation. This knowledge point relates to authorization model parity as another tenant-boundary control, feeds spotting auth gaps in an integration design, and connects to the four-layer request logging model and anomaly detection thresholds, which is where a per-tenant cost spike would raise an alert.
A multi-tenant SaaS runs all customers through one shared Claude API key, logging a tenant ID per request. The org rate limit trips at peak and every customer goes down. What is the correct architectural change?
People also ask
Why use separate API keys per tenant?
What breaks with a shared API key across tenants?
Is request-level logging enough for tenant attribution?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.