Instance limits (RAR)
How one running instance of an agent asks for narrower limits than its policy, with RFC 9396 Rich Authorization Requests.
The permissions of an agent are written for the agent, not for each copy of it that is running. A support agent may have ten instances open at the same time, one per ticket, and the policy says what any of them can do: call refund_payment, refund up to USD 1,000. Some of those instances should have less. The one working a disputed order for a new customer should not be able to refund more than USD 100, even though the agent could.
Writing that into the policy would mean a rule per ticket. Xokepoint does the opposite: the instance asks for its own, narrower limits when it gets its token, and the token carries them. The mechanism is RFC 9396, Rich Authorization Requests (RAR), which adds an authorization_details parameter to OAuth requests so a client can describe exactly what it intends to do, instead of a scope string.
Not used in the Admin for now
The backend accepts and checks instance limits, but the Admin does not offer them, because the agent instance sets its own limit in its token, so it is not a control of the administrator; a limit is checked on each call, with no total across calls; and harness login sends no limits. To limit a tool, write a rule.
The request
The instance sends authorization_details in its token exchange, as a JSON array. Xokepoint defines a single type, chokepoint_tool_call, with one entry per tool:
[
{
"type": "chokepoint_tool_call",
"server_id": "<server ID>",
"tool": "refund_payment",
"limits": { "max_amount": 100 }
}
]The AS checks the shape before it signs anything:
| Rule | Limit |
|---|---|
| Entries | At most 16, one per server_id and tool |
| Tool | The agent must be able to call it (tool#can_call@agent) |
limits | 1 to 16 names matching ^[a-z][a-z0-9_]{0,63}$ |
| Values | A number, or a string of at most 256 characters |
Anything else, an unknown type, an extra field, a tool the agent cannot call, is refused with invalid_authorization_details and no token is issued. The refusal is recorded with that reason and shows up in the token exchange inspector. The AS advertises the type in its metadata as authorization_details_types_supported: ["chokepoint_tool_call"].
Limits only narrow
An entry never grants anything. It cannot add a tool, a resource or a delegation; the tool check above exists so that a limit can only name something the agent already has. The accepted entries go into the token response and into the signed JWT, so a limit cannot be raised by editing the token: the signature would no longer match.
Each exchange is independent. To renew its token, the instance sends its authorization_details again. A request without the parameter gets a token without limits.
How a rule uses them
On a call, the PEP takes the limits of the entry whose server_id and tool match the validated call and writes them to context.chokepoint.limits, next to the actor and the arguments. Entries for other tools are ignored, and no mapping can set or replace this field (Trusted context).
A call condition reads the limit like any other input:
double(context.chokepoint.arguments.amount) <= double(context.chokepoint.limits.max_amount)The condition declares the limits it reads in required_limits. If the token has no such limit, the condition is false and the call is denied with reason condition. That is a deliberate difference from a missing PIP fact, which blocks with 503: a missing fact is an outage, a missing limit is a client that did not ask for what the policy requires.
The instance limit adds to the Admin rules, it does not replace them. Every condition of the agent · server · tool edge must pass, so with an Admin rule amount <= 1000 and an instance limit of 100, the effective ceiling is 100. With an instance limit of 5000, it is still 1000. The AS does not compare the two at issuance; the PDP applies both on each call.
What RAR is not here
RAR is often used to let a user approve a specific transaction at consent time. Xokepoint uses it only for self-restriction of an agent instance: nobody approves the limits, because they can only reduce what was already approved. A count of calls, such as "at most 3 refunds", is not a limit either. It needs a reservation before execution and rules for failures and time windows, and it is not part of the current model (Conditions).