← Field Notes
AUG 30 · Paper · via arXiv Budget ScopingDelegationPermissions

AID-Guard counts what an agent already did before it allows more

This reframes permissions as a quantity, not just a binary. If I'm designing a delegation UI and I'm not surfacing effect limits alongside capability grants, I'm showing users half the picture.

Machine summary of the source

Most agent authorization systems work like a bouncer checking a list at the door: if the agent has permission for an action type, it can execute that action as many times as it wants. AID-Guard identifies this as a structural flaw. A delegated agent with write access to a calendar, for example, shouldn't be able to create unlimited events just because it was authorized to create one. The paper introduces stateful authorization — a model where the system tracks cumulative effects and checks each new action against what has already occurred, not just what is nominally permitted.

The prototype enforces what the authors call 'effect budgets': constraints defined at delegation time that deplete as the agent acts. An agent authorized to send three emails can send three, not thirty. This sounds simple, but it requires the authorization layer to maintain a running ledger of agent effects across a session — something current permission models, including MCP's tool-access grants, do not do. The empirical results show the approach catches a meaningful class of over-execution failures that static ACLs miss entirely.

For UX designers, this reframes what 'permissions' means as a design material. It's not just about granting or revoking access to a capability — it's about scoping the magnitude of impact that capability can have before a human re-authorizes. The implication is that budget-scoping and permissions are inseparable: showing a user 'this agent can send email' is incomplete without also surfacing 'up to N times before checking back with you.'

The summary above is generated; the note at the top is the editorial judgment. Primary source ↗