Issuing Per-Teammate Keys Behind One Aggregator Account: Caps, Revocation and Spend Isolation

Why one key per person or service is worth the overhead

A single shared API key is convenient until it isn't. When several people and several services all call models through one credential, you lose three things at once: you can't tell who spent what, you can't cut off one bad actor without disrupting everyone, and a single runaway loop can consume the whole account balance.

Per-teammate and per-service keys restore those properties. Each key becomes an identity: it has a known owner, an expected spend envelope, and an independent switch. The goal is not bureaucracy — it is making failure small. A buggy script or a leaked key should cost you a bounded slice of your balance, not the entire top-up.

Understand where the account boundary sits

With an aggregator, your USDC top-up funds an account balance. API keys are credentials that draw down against that balance when they make calls. The account is the billing entity; the keys are access paths to it.

That distinction shapes everything below:

• Top-up and balance live at the account level. One USDC deposit credits the whole account.
• Billing is per call at official price × 1.3. Every request through any key is priced the same way relative to the underlying model's official rate.
• Keys are what you distribute. Treat each key as a token with a named owner and a purpose.

Because balances are shared, true spend isolation is achieved by tracking and moderating per-key usage rather than by physically partitioning the money. Your job is to make each key's exposure visible and controllable.

Choose a key taxonomy before you issue anything

Decide the granularity up front. A workable default is three tiers:

• Human keys — one per teammate. Named after the person, rotated when they leave or when a laptop is lost.
• Service keys — one per deployed application or background job. Named after the service and environment (for example, staging versus production).
• Ephemeral keys — one per experiment, spike, or short-lived automation. Created for a task and revoked when it ends.

Do not share a key between a human and a service. If a service key leaks through logs, you want the blast radius to be the service, not a person's workflows.

Apply caps in layers

The aggregator enforces the account balance; you enforce the finer-grained envelopes. Layered caps work best:

• Per-key budget envelopes. Assign each key a spending ceiling expressed in USDC for a period (daily, weekly, or per task). When the envelope is exhausted, the key is paused until you review it.
• Per-key request ceilings. A cap on request volume catches tight loops even when individual calls are cheap.
• Account-level headroom. Keep the total of all envelopes below your topped-up balance so one key's overrun cannot silently starve the others.
• Model allowlists. Restrict a key to the models its owner actually needs. A summarization job has no reason to reach for your most expensive reasoning model, and narrowing the allowlist narrows the worst case.

Enforce these in the layer that sits between your callers and the aggregator — a small gateway, proxy, or internal client library that attaches the right key and checks the envelope before forwarding. Envelopes are your policy; the aggregator's balance is the hard floor beneath them.

Isolate spend so a runaway script drains only itself

Isolation is mostly about attribution and containment:

• Attribute every call. Log key ID, owner, model, token counts, and computed cost on each request. Without per-key attribution you cannot answer "what did this key cost me last week?"
• Give every script its own key. A batch job, a cron task, and a webhook handler should not share a credential. If one loops, you revoke one key and the rest keep running.
• Set envelopes to the task, not the person. For automation, size the cap to the expected run plus a safety margin. If a job normally costs a few dollars, an envelope of the same order of magnitude turns a runaway into a stopped job rather than a drained account.
• Alert on envelope burn rate. A key that consumes its daily envelope in minutes is behaving abnormally. Route that signal to whoever owns the key.
• Rehearse the stop. Know exactly how to pause or revoke a key before you need to. A revocation procedure you have never tested is not a control.

Handle revocation as a routine, not an emergency

Revocation should be boring and repeatable:

• Offboarding: revoke human keys the day a teammate leaves; rotate any key they could have seen.
• Incident response: revoke first, investigate second. Because keys are independent, revocation is cheap and localized.
• Rotation: issue a new key, deploy it, confirm traffic, then revoke the old one. Keep the overlap window short.
• Ephemeral cleanup: expire experiment keys automatically at the end of their task so forgotten credentials do not linger.

Maintain a key registry — key ID, owner, purpose, envelope, creation date, last-used date — so revocation decisions are informed rather than guesswork.

Keep contributor accounting legible

If your account includes contributors who are compensated for their work, keep that accounting separate from day-to-day spend. Contributors are credited at official price × 1.1 (premium × 1.2) in USDC, while calls are billed at official price × 1.3. The margin between those rates is the platform's, and contributor credit is a distinct flow from request billing.

Practically, this means: tag contributor-linked usage clearly in your logs, and do not let a contributor credit balance be confused with a spend envelope. One is money owed to a person; the other is a ceiling on a key.

A minimal operating checklist

• Name every key after a person, service, or task — never share keys across those lines.
• Set a per-key USDC envelope and a request ceiling, sized to expected use.
• Narrow each key's model allowlist to what it needs.
• Log key ID, owner, model, tokens, and cost on every call.
• Alert on abnormal envelope burn rate.
• Keep a key registry and review it periodically.
• Revoke on offboarding, rotate on suspicion, expire ephemeral keys.
• Keep total envelopes below your topped-up balance.

Done consistently, this turns one account into many bounded identities. A runaway script hits its own ceiling, gets paused, and the rest of your team and services keep working.