How little authority does a useful agent need?
We propose comparing broad account access, fixed roles and task-specific permissions in a simulator using synthetic workflows. Reading a record, proposing a change and committing an approved update will be tested separately, including revoked access and stale approvals. We will measure forbidden actions that actually succeed alongside legitimate task completion.
Scope and question
Connecting an agent to business software delegates authority as well as capability. The proposed study asks whether task-specific permissions and action-bound approvals offer a better security/usefulness tradeoff than a broad account-level grant.
The first environment is a deterministic simulator with synthetic users and records. It separates reading a permitted record, proposing an update and committing an approved update. It will not connect to production accounts.
Research approach
Define the action contract.
Write an actor, action and resource matrix with expected final states. Freeze allowed and denied sequences before comparing policies.
Exercise the awkward transitions.
Include revoked access, a changed recipient after approval, stale approval, repeated submission and a mid-workflow role change.
Test enforcement before the model.
First score the external policy independently. Then compare a small agent pilot against the same contract, preserving unseen sequence compositions for evaluation.
What we will measure
- Primary: forbidden state transitions that actually succeed.
- Legitimate task completion and unnecessary denials.
- Approval burden, revocation time and completeness of the action record.
What this can and cannot tell us
A model proposing a forbidden action is different from the enforcing service allowing it. These failures must be recorded separately.
Passing known synthetic cases does not prove the policy covers every sequence or integration. Blocking everything is not a useful security result.
This is a proposal. The simulator and measured agent comparison have not been completed.
Next steps
Define the permission matrix and the first ten sequence cases. The intended outputs are an executable reference simulator, a failure catalogue and a design note. A reusable authorization product is a hypothesis to test later.
Discuss the research