The Seven-Constraint Scorecard for Agent Permissions
A complete agent permission carries seven constraints. Score any approach against them and the comparison stops being preference.
| # | Constraint | What it fixes |
| 1 | Agent | Which specific agent. Without it, any holder can exercise it |
| 2 | Scope | Category of action. Read not write, book not cancel |
| 3 | Limit | The quantitative bound. The one people mean by "limit", and it is 1 of 7 |
| 4 | Payment instrument | Which account or rail. $500 from this account ≠ $500 |
| 5 | Expiry | When it lapses on its own |
| 6 | Data access | What it may read. Exfiltration risk ≠ action risk |
| 7 | Revocability | Withdrawal without asking downstream systems to comply |
THE SCORECARD:
| Constraint | Static API key | OAuth 2.1 | JWT | Agent memory | Participant-held mandate |
| Agent | No | Partial, client ID | Encoded | No | Yes |
| Scope | No | Yes | Encoded, not enforced | No | Yes |
| Limit | No | No | Encoded, not enforced | No | Yes |
| Payment instrument | No | No | Encoded, not enforced | No | Yes |
| Expiry | No | Yes | Yes , exp claim | No | Yes |
| Data access | No | Coarse | Encoded, not enforced | No | Yes |
| Revocability | No | No, propagation required | No, valid till expiry | No | Yes |
| TOTAL | 0 / 7 | 2 / 7 | 1 / 7 | 0 / 7 | 7 / 7 |
Two rows need explaining.
JWT, "encoded not enforced": you can put anything in a claim. Encoding a spending limit does not make anything check it . A claim is a statement, a constraint needs something that acts on it.
Memory scoring zero: not a criticism of mem0, which solves a real problem well. Memory is model input , competing for attention inside the context window on the model's terms. That is exactly why injection works, at 56-70% against ReAct agents. If memory constrained behaviour, injection would fail.
Revocability is the load-bearing row. Six constraints describe the permission. The seventh describes what happens when you change your mind. Exposure = actions/sec × window length , so a 15-minute window fine for a human is a different exposure for an agent at 40 calls/sec.
| Approach | Revocation mechanism | Exposure window |
| Static API key | Rotate, update every consumer | Until all consumers updated |
| OAuth 2.1 | Issuer marks invalid, systems learn on own schedule | Per-system, varies |
| JWT | None until expiry unless introspected | Full token lifetime |
| Participant-held mandate | Advance the context | Closes at next check |
Use it as a buying checklist. Hand a vendor the seven and ask them to fill the column. Three predictions: most express Scope and Expiry well, because OAuth normalised those. Most express Limit and Payment instrument as something you encode rather than something enforced, so press on who checks it, and at what moment . Almost none have a good answer on revocability without propagation , which is where to spend your time.
The unit of authority worth asking for lives in the participant's context rather than the agent's config, which is what makes all seven expressible at once.
Limitations. Seven constraints bound what an agent can do, not whether it behaves well inside them. OAuth scoring 2/7 is not a criticism: it was built for a human approving one provider and does that well. Expressing a constraint is not enforcing it everywhere. DevNet stage.