I test what ships and publish what I find, failures included.
Kubernetes, AWS and supply chain security.
Docker Captain, CNCF Ambassador, IBM Champion. 1.8M+ Docker Hub pulls.
"Never more than that person has right now" holds only if the tool server computes it on every call from two identities, instead of trusting the agent to say whom it acts for.
In the setup I run, the MCP server takes two tokens per call: the agent's in Authorization, the person's in On-Behalf-Of, both checked with TokenReview. What gets through is the intersection of the two grants in policy.json. Before that change, 7 of the 10 checks in tests/e2e/people.sh failed, and first-line support could have the agent send an email. Token exchange with an act claim is the cleaner form where a token service exists; inside an air gap there was none.
One gap a session grant leaves open. The model gateway still knows only the agent, so quotas and token budgets are per agent, and one person can spend the allowance for everyone. Consent covers the tools, not the spend.
That's the enforcement point I had in mind, and it's good to see it working in an air gap: the agent's token plus the person's token, intersected on every call. Going from 7 of 10 checks failing to none is a good argument for anyone who thinks the agent can just pass a user id.
Fair point on spend. Consent covers what the agent can touch, not what it burns. I think budgets should be keyed like everything else, on the person or the session rather than the agent. It could even be part of the grant, so "run this with up to N tokens" gets approved alongside the tool access. I hadn't thought about it until you raised it.
I test what ships and publish what I find, failures included.
Kubernetes, AWS and supply chain security.
Docker Captain, CNCF Ambassador, IBM Champion. 1.8M+ Docker Hub pulls.
Keyed on the person is where I would take it too, and the obstacle is plain: the gateway never sees the person. The person's token is minted for the MCP server's audience alone and travels in On-Behalf-Of, while the gateway keys its request quota and its token budget on jwt.sub of the agent's service account. Putting the budget into the grant means the gateway reads a second token, or the MCP server carries the model calls itself, and either is a design change rather than a config line.
One property holds under either keying. A token count exists only after the answer, so the request that crosses the budget is served and the next one gets 429; the agent caps an answer at 400 tokens to bound that overshoot to one prompt and 400. "Up to N tokens" in a grant is a ceiling with one request of slack, and the audit line should say so.
Agreed, that's a design change, not a config line. The least invasive version I can see is to key the budget on the session rather than the person. Mint the agent's credential for the model gateway per session, with the gateway as its only audience and the session id inside. Then the gateway keys on a claim it already reads, and IAM answers which person the session belongs to. It still changes how the agent gets its gateway credential, but it doesn't add a second token to every call.
On the overshoot, I think you can close the slack. Input tokens can be counted before the call, and output is capped by max tokens, so the gateway can clamp each request's max output to whatever budget is left. Then "up to N" is a real ceiling rather than N plus one request.
I test what ships and publish what I find, failures included.
Kubernetes, AWS and supply chain security.
Docker Captain, CNCF Ambassador, IBM Champion. 1.8M+ Docker Hub pulls.
The session-keyed credential I'd take. It keeps the key on jwt.sub, which the gateway already checks offline, and leaves the question of which person a session belongs to with IAM and the audit, where it was.
Clamping closes the answer side. The slack that survives it is replicas: agentgateway counts a budget in each proxy replica on its own (ADR 12), so a site running three gives every caller three budgets. One replica here hides that.
A real ceiling with several replicas needs the global rate limit service, one more service inside the boundary. That's the cost of making "up to N" mean N.
We're a place where coders share, stay up-to-date and grow their careers.
"Never more than that person has right now" holds only if the tool server computes it on every call from two identities, instead of trusting the agent to say whom it acts for.
In the setup I run, the MCP server takes two tokens per call: the agent's in
Authorization, the person's inOn-Behalf-Of, both checked with TokenReview. What gets through is the intersection of the two grants inpolicy.json. Before that change, 7 of the 10 checks intests/e2e/people.shfailed, and first-line support could have the agent send an email. Token exchange with anactclaim is the cleaner form where a token service exists; inside an air gap there was none.One gap a session grant leaves open. The model gateway still knows only the agent, so quotas and token budgets are per agent, and one person can spend the allowance for everyone. Consent covers the tools, not the spend.
That's the enforcement point I had in mind, and it's good to see it working in an air gap: the agent's token plus the person's token, intersected on every call. Going from 7 of 10 checks failing to none is a good argument for anyone who thinks the agent can just pass a user id.
Fair point on spend. Consent covers what the agent can touch, not what it burns. I think budgets should be keyed like everything else, on the person or the session rather than the agent. It could even be part of the grant, so "run this with up to N tokens" gets approved alongside the tool access. I hadn't thought about it until you raised it.
Keyed on the person is where I would take it too, and the obstacle is plain: the gateway never sees the person. The person's token is minted for the MCP server's audience alone and travels in
On-Behalf-Of, while the gateway keys its request quota and its token budget onjwt.subof the agent's service account. Putting the budget into the grant means the gateway reads a second token, or the MCP server carries the model calls itself, and either is a design change rather than a config line.One property holds under either keying. A token count exists only after the answer, so the request that crosses the budget is served and the next one gets 429; the agent caps an answer at 400 tokens to bound that overshoot to one prompt and 400. "Up to N tokens" in a grant is a ceiling with one request of slack, and the audit line should say so.
Agreed, that's a design change, not a config line. The least invasive version I can see is to key the budget on the session rather than the person. Mint the agent's credential for the model gateway per session, with the gateway as its only audience and the session id inside. Then the gateway keys on a claim it already reads, and IAM answers which person the session belongs to. It still changes how the agent gets its gateway credential, but it doesn't add a second token to every call.
On the overshoot, I think you can close the slack. Input tokens can be counted before the call, and output is capped by max tokens, so the gateway can clamp each request's max output to whatever budget is left. Then "up to N" is a real ceiling rather than N plus one request.
The session-keyed credential I'd take. It keeps the key on
jwt.sub, which the gateway already checks offline, and leaves the question of which person a session belongs to with IAM and the audit, where it was.Clamping closes the answer side. The slack that survives it is replicas: agentgateway counts a budget in each proxy replica on its own (ADR 12), so a site running three gives every caller three budgets. One replica here hides that.
A real ceiling with several replicas needs the global rate limit service, one more service inside the boundary. That's the cost of making "up to N" mean N.