2.9 Emerging

User-defined access policies

Letting a user write the standing rules for their agent in advance (what it may do, when, and for what purpose) so the service can grant or refuse access later without the user present. A request outside the rules is refused by the service itself, whatever the agent claims the user wanted.

01

The impact of agents

A user often will not be present when their agent needs to act: a tax agent files months after being authorized, an assistant checks a payment status overnight. Conventional access control assumes someone is there to grant or refuse access in the moment, and agents break that assumption at scale.

Whatever the user sets only protects them if they can express it in terms they understand; a policy console that speaks in raw permission grants moves the risk from the moment of access to the moment of setup, where errors are harder to notice and last longer.

02

What must be verified

An agency needs a user to be able to express standing, conditional rules in advance that it can evaluate when an agent later requests access, granting or refusing without the user present.

03

Protecting access

Standing policies shift the whole burden to setup. Conditional rules are a reasoning task, and a user who sets them wrong grants more access than they meant, or blocks access they intended, usually without ever seeing the mistake. This falls hardest on users with no prior exposure to conditional or boolean logic, who have the least intuition for how a rule they wrote will be evaluated in their absence. The error often surfaces months later, when the agent acts or fails to act.

Keeping the path open

  • Provide government templates for the common cases, so 'I'm authorizing a tax professional' arrives as a pre-built, plain-language policy set.
  • Hold customization out for those who want it, rather than requiring it of everyone.
  • Add a readback step that tells the user, in words, what their policy will and won't allow before it takes effect.
04

Response surface

Access Policy

Conditional access rules, such as tax preparation only and only in business hours, are offered as editable templates rather than left as raw policy to author.

User setting policy
City Digital Services

Set rules for your agent

Start from a template and adjust it. Your agent can only act inside these rules.

1
Can access your tax records during business hours (Mon–Fri, 08:00–18:00)
Edit
2
Can view and submit tax returns only
Edit
3
Cannot access superannuation or health records
Edit
+ Add another rule

See what each rule would have done against your agent’s recent requests, before you turn it on.

System evaluates access
Policy evaluations
15 Jun, 10:32 · read income statements
Allowed by Rule 1
15 Jun, 10:33 · submit 2025 return
Allowed by Rule 2
15 Jun, 21:07 · read super balance
Denied by Rule 3

The user is notified on every denial. A denial with no notice would be read as the agent failing.

05

Maturity

Emerging

Emerging for letting a user set standing, conditional rules that an agency evaluates without the user present; the response exists as a worked-out approach but has seen limited adoption.

06

Precedents

UMA 2.0 (User-Managed Access). The OAuth-based protocol separates the resource owner from the requesting party, so a person can grant access to software that someone else is operating. The owner sets sharing policies at a central authorization server, decisions can be made asynchronously with the owner absent, and a policy can carry conditions on time and purpose. Delegation is expressed as policy the owner holds, and not as a token issued at the moment of asking.

07

What carries over to agent use

UMA's model of asynchronous, policy-based access delegation is highly relevant for AI agents. The user sets policies in advance ("my tax agent can view my returns but not amend them; my AI assistant can check my Centrelink payment status but not change my bank details"). The agent requests access, the authorization server evaluates the request against the user's policies, and grants or denies access without the user needing to be present.

Limitations: UMA has seen limited adoption compared to standard OAuth, partly due to its complexity. Government services would need to invest in the policy management UX, helping users set meaningful policies without overwhelming them.

08

Where things go wrong

Without server-side policy limits, an agent can expand its reach into unrelated records during an automated run. Pre-set, conditional policies evaluated server-side mean it only ever gets the narrow access the user defined. A request timed to land a minute inside a 'business hours only' window satisfies that condition on paper while doing exactly what the condition was meant to prevent.

09

Sources

3 references International
Primary frameworks

The instrument, the operating deployment, or the official record itself.