A Presenter Identity for the Caller

Here is the failure stated as a test you can run on your own logs. Take one write action performed for user A in tenant A, and one for user B in tenant B. Ask whether the two log lines differ in the fields that identify the human and the tenant.

With a shared service account they usually do not. Both lines show the same principal, the same credential id and the same client. The user and tenant, if they appear at all, sit in a request body the caller controls. WorkOS draws the same contrast: a service account produces one log line, while an agent's authority is a chain of delegation that should be traceable to the original authorization event 1. A shared account collapses that chain into a single anonymous hop.

That is why the shared account fails an audit test rather than merely looking untidy. Investigators and auditors need to reconstruct who acted, on whose behalf, and under which tenant. If the values that answer those questions are parameters rather than claims bound to a credential, the log proves only that the service account made a call.

The second failure is worse. When a credential spans several tenants, cross-tenant access requires breaking nothing. Scalekit describes a concrete case: a background job with no customer context in execution scope resolves the first stored token it finds and updates records in the wrong organization, and the downstream API accepts the call because the token was valid 3. No exception, no 403. The log shows a legitimate call by the shared account.

Research on tool-using agents formalizes this. When a tenant identifier is a tool parameter, the effective authority of the request is bounded by the model's prompt rather than by the caller's credential, because the arguments the model supplies are the output of a stochastic process whose context an attacker can partly reach 4. In the reported ablation, a correctly validated tenant parameter served every out-of-scope pretext attempt: 26 of 26. Removing the parameter from the tool schema was what closed the path.

Make it numeric. Suppose the agent platform holds two delegated grants, one for Alice in tenant A and one for Bob in tenant B, and an hourly job reconciles pending invoices. With a shared account, the job runs with no tenant in scope.

• Calls in one hour: the job processes 400 invoices across both tenants.
• Calls attributable to a human from the log alone: 0, because every line names the service account.
• Calls that could land in the wrong tenant: any of the 400, because nothing in the credential narrows the set.
• Time to detect: in the case Scalekit describes, the anomaly surfaced six weeks later, in a customer review 3.

Now run the same job with presenter identities. Each work item carries a presenter token issued for one user and one tenant, valid for a few minutes and bound to a specific audience.

• Calls attributable to a human: 400, because the token subject is the user and the tenant is a signed claim.
• Calls that could land in the wrong tenant: those whose token names the other tenant, which the target service rejects before reading a row.
• Time to detect: the duration of one request, because the deny is logged with both the claimed tenant and the resource tenant.

The numbers are illustrative, but the ratio is the insight: a shared account gives you one attributable principal for every call it makes, however many humans sit behind them.

The presenter record is small. Keep it in its own table, apart from human users and apart from any service-account registry, because its lifecycle differs: created when a user first delegates, suspended when the delegation is revoked, deleted when the user is deprovisioned.

Two rules make this schema do the work. First, presenter_id maps to exactly one user_id and one tenant_id, enforced by a unique constraint, so a record cannot represent two people. Second, no caller supplies tenant_id as a request parameter to a tool. The tenant comes from the presenter record, travels in the token, and the tool schema has no field for it, which is the structural defense the arXiv work recommends 4.

WorkOS recommends minute-scale token lifetimes and just-in-time issuance over long-lived secrets, with every cache where a credential might persist inventoried 5. The presenter record is the administrative anchor; the token is its short-lived projection.

The token should carry actor and subject separately. In the delegation pattern Scalekit describes, a token can hold both the agent identity and the user identity as nested claims, so downstream services can enforce policy and log actions against the right human 6. OAuth 2.0 Token Exchange is the standardized way to mint such a token: present the user's token, name the audience, and receive a narrower token addressed to one downstream API 7. The audience parameter pins the issued token to a target and prevents cross-server reuse 8.

A presenter token should satisfy all of these:

1. Subject is the user id. Actor is the presenter id. Neither is readable from the request body.
2. Tenant id is a signed claim, not a query parameter.
3. Audience names the one service the token is for.
4. Lifetime is minutes, not days, and issuance happens just in time.
5. Scope is a narrow verb on a narrow resource, checked by a gateway the model cannot instruct.

A minimal verification step in Python, assuming you decode and signature-check the token with your identity provider library first:

def admit(token_claims, resource_tenant_id, required_scope):
    # token_claims come from a verified signature, never from the request body
    if token_claims["aud"] != SERVICE_AUDIENCE:
        return deny("wrong audience")
    if token_claims["tenant_id"] != resource_tenant_id:
        return deny("tenant mismatch")
    if required_scope not in token_claims["scope"]:
        return deny("scope not granted")
    return allow(user_id=token_claims["sub"], presenter_id=token_claims["act"])

The deny path must write an audit record naming the claimed tenant and the requested tenant. That record is the artifact your replay test asserts on.

One more rule: the presenter's effective authority is the intersection of what the presenter is allowed and what the user is allowed, never the union 5. A user who loses access in the identity provider should lose it in the agent at the next issuance, not at the next rotation. Auth0 makes the adjacent point that fine-grained scopes let you block any tool call not explicitly granted to the agent, which limits what a successful prompt injection can reach 9.

This is the test that proves the design, and it costs less than any penetration test. Issue a real presenter token for a user in tenant A. Send it to a resource owned by tenant B. Assert three things: the response is a deny, the deny is a 403 rather than a 404 that leaks existence, and an audit record exists with the presenter id, the user id, the claimed tenant and the target tenant.

Keep the test small and hermetic. Small tests should finish in under a second and cannot touch the network, so mock HTTP at the library level and let your own authorization code run normally 10. pytest-httpx provides a fixture that intercepts client calls and returns canned responses, which is exactly the shape needed for a cross-tenant request 10. If your code uses the standard library client, patch the connection object with a mock and set status and body explicitly, a pattern documented for that client 11.

def test_token_cannot_replay_into_second_tenant(httpx_mock, audit_log):
    token = issue_presenter_token(user="alice", tenant="tenant-a", aud="billing")
    httpx_mock.add_response(url="https://billing.internal/tenants/tenant-b/invoices",
                            status_code=403, json={"error": "tenant mismatch"})
    resp = billing_client.post("/tenants/tenant-b/invoices",
                               headers={"Authorization": f"Bearer {token}"})
    assert resp.status_code == 403
    assert audit_log.last.presenter_id == "presenter-alice"
    assert audit_log.last.target_tenant == "tenant-b"

Three more cases belong in the same file, because each catches a different mistake:

Run these on every build. A design that passes all four is safe to extend. A design that passes only the first is one parameter change away from the failure Scalekit describes 3.

The comparison comes down to what each option leaves behind after an incident.

Use the shared account only where the actor genuinely is the account: scheduled jobs with no human behind them, health checks, machine-to-machine calls where the caller is the principal. The moment a human's intent drives the call, the shared account has already lost the information you will need. Azure's guidance lists agent identity as the first place tenant context is lost, precisely because the identity carries no implicit tenant 2. OWASP's agent security sheet adds the operational half: grant the minimum tools per task, scope permissions per tool, and enforce authorization in the execution component rather than in the agent's context, failing closed for unknown tools 12.

If you are still deciding how agents reach models at all, that is a separate choice from identity and worth making separately. Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key, so your presenter design stays the same whichever model the agent calls (https://quantaintelligence.ai/inference).

Do not rewrite every caller. Sequence the work in four steps, each useful on its own.

1. Instrument first. Add presenter_id, user_id, tenant_id and target_tenant_id to your audit schema, and log the request-body tenant alongside anything the credential claims. Once the fields exist you can measure how often they disagree, and that number is your business case.
2. Issue tokens for new integrations only. New agent connections get presenter identities and audience-bound tokens from day one, so the code path exists before anyone depends on it.
3. Move the highest-risk tool calls next. Anything writing to a system you do not own, such as a CRM, a ticketing tool or a messaging channel, goes first, because those actions are external and irreversible 3.
4. Retire shared accounts last, and only after the replay tests pass for every presenter in production. Keep the shared account for jobs whose actor truly is the account.

Two operational details decide whether this sticks. Deprovisioning must revoke presenters automatically when a user leaves, or you build the orphaned-agent problem IAM teams already struggle with, where unused tokens and unnamed owners accumulate 13. And per-user keys rather than one shared admin key make attribution possible at the agent's own boundary; Quanta for Teams gives each member their own API key inside a shared credit pool, which matches the one-identity-per-person rule (https://quantaintelligence.ai/for-teams).

If you want a second opinion on where the identity provider ends and the agent platform begins before you start step 2, a short discovery call is often enough to settle it (https://quantaintelligence.ai/calendar).