Practical LLM Security · interactive lab

Delegation boundaries: trace privileges across three agents

Follow synthetic credentials through concierge, research, and operations agents, and see which checks stop unauthorized actions.

Synthetic fixtures · no model, identity, or payment API calls

Experiment inputs

Complete-run results

Decision trace

    What this experiment demonstrates

    A customer, c-104, talks to a concierge agent. The concierge delegates reading to a research agent, which also reads untrusted product reviews, and the operations agent holds tools for refunds and exports. Each scenario sends one request to operations: a legitimate refund the customer confirmed, an injected refund for another customer's order, an export designated by a research summary, a stored approval reused on a different order, and a bulk export from a compromised research agent.

    The privilege cards show what each agent holds under three credential models. Ambient service accounts give each agent broad rights of its own. Forwarding sends the customer's token unchanged through every hop. Per-hop exchange issues a token for each audience with the customer as subject, the calling agent as actor, and scopes that only shrink. No identity provider, token service, model, or payment API runs here; each check is a deterministic rule applied to fixture data.

    Run controlled comparisons

    Start with the default: ambient service accounts and an injected refund. Operations trusts any internal agent, so the refund for order o-91 executes even though resource ownership checking is enabled; no end-user identity reaches the API, so ownership cannot be checked. Switch to per-hop exchange. The broker refuses to issue a research-to-operations token. Turn that hop policy off and the ownership check stops the request instead, because the exchanged token names the customer.

    Choose the approval reuse scenario. Order o-78 belongs to the same customer, so ownership passes and the refund executes until you enable approval binding or trusted designation sources. Choose the forwarded token model with the legitimate refund, then enable audience validation: the correct check now refuses the legitimate request, because the forwarded token was issued for the concierge. That is why forwarding is not a safe shortcut. Finally choose the compromised bulk export and compare ambient accounts with read-only quarantine of the research agent.

    Inspect the trace and keep evidence

    Each run lists the privileges at every hop, the request and its designation source, then each check at operations in order, ending with the effect. The outcome line names the first control that stopped the request. Use Start trace, Next step, Show all, and the slider to walk through a run, Reset to restore the default, and Export JSON to save the assumptions and decision trace. For every comparison, record the protected effect, the earliest check with enough evidence to stop it, and whether the legitimate scenario still works.

    Limits and production translation

    The model checks one request per run and assumes every enabled control is implemented correctly. It does not model token theft, clock skew, revocation latency, partial failures, or concurrent requests, and the scope names are invented. In a real deployment, test the receiving services directly with tokens for the wrong audience, extra scopes, expired lifetimes, and mismatched designations, and assert that fake tool counters stay at zero. Repeat the tests after any SDK, broker, or policy change.