Agent permission and authority design
Decide how to constrain delegated authority for each action
When agent capabilities are expanding beyond reading information, this area becomes relevant. For the identity and application security architect, the concern is specific: an agent retains broad authority after the task or user's permission changes. The engineering design starts from that consequence and follows the relevant evidence through the customer workflow. Permission design should follow the action and accountable principal across components. A model instruction to behave carefully is insufficient as the sole boundary for an action the surrounding system is capable of authorising or denying.
The engineering decisions relationship
- Actor and role model
Establish the basis for necessary operation.
- Delegation restriction
Prevent inherited authority from expanding.
- Authority model
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around necessary operation
Questions and the evidence they need
- Necessary operation
- Inspect actor and role model for the relevant constraint or observation.
- Delegation restriction
- Inspect action catalogue for the relevant constraint or observation.
- Revocation behaviour
- Inspect credential and approval lifecycle for the relevant constraint or observation.
For the identity and application security architect, this becomes relevant when agent capabilities are expanding beyond reading information. The immediate decision is how to constrain delegated authority for each action. The scope should be narrow enough that the engineering team can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that an agent retains broad authority after the task or user’s permission changes. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Mechanism
Action permissions should follow the delegated task
Relationships within engineering decisions
- Necessary operation
- Define the smallest resource and action scope.
- Delegation restriction
- Prevent inherited authority from expanding.
- Revocation behaviour
- Check pending work after permission withdrawal.
Least necessary action scope
For this scope, least necessary action scope should be examined alongside actor and role model. Specify the smallest action scope that supports the task and identify its enforcement point. A user’s request, an agent credential, and a business authorisation rule are different inputs. The design should show how they combine before an external action is permitted.
Delegation limits
For this scope, delegation limits should be examined alongside action catalogue. Bound delegated authority across agents and tools. A worker should not receive broader rights merely because it could finish the task faster. The architecture should preserve the initiating principal and constraints so downstream actions remain attributable to the authorised request.
Revocation behaviour
For this scope, revocation behaviour should be examined alongside credential and approval lifecycle. Define revocation and expiration for active sessions and pending tasks. A role change should have an observable effect on later actions. The design should identify stale credentials or context paths and specify how the workflow stops, refreshes authority, or seeks a new decision.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for necessary operation
Illustrative working format
- Actor and role model
- Identify the accountable role and verify its decision rights or availability.
- Action catalogue
- Retain the observed conditions and distinguish gaps from contrary evidence.
- Credential and approval lifecycle
- Connect the accepted action parameters to grant, amendment, expiry, and withdrawal.
The starting material is actor and role model, action catalogue, and credential and approval lifecycle. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include a workflow owner, an implementation lead, an eventual maintainer, and qualified control reviewers where needed. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Carry necessary operation through to an accountable finding
From the scoped material to a decision record
- Actor and role model
Make the component and operating boundary explicit.
- Delegation restriction
Apply the scoped check to revocation behaviour.
- Authority model
Record the evidence, open dependencies, and the owner’s next decision.
Model permissions at the action level and identify the enforcement component. Distinguish a user’s ability to ask for an action from the agent’s technical credential and the business rule permitting execution. The proposed design should also define how delegation, expiration, and revocation affect a task already in progress.
A practical first slice would focus on least necessary action scope and then follow its consequences into delegation limits. Keep revocation behaviour visible as a separate review question rather than assuming it is satisfied by the first result. The engineering team should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefact
Make the authority model usable by its owner
Authority model
Illustrative working format
- Authority model
- Specify the acting role, allowed resource effect, and enforcement boundary.
- Permission policy design
- Specify the acting role, allowed resource effect, and enforcement boundary.
- Authorisation test outline
- Name the unresolved condition, next action, and accountable owner.
Indicative outputs include authority model, permission policy design, and authorisation test outline. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Examine revocation behaviour through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Necessary operation
A ticket-editing agent must remain unable to change account entitlements.
- Delegation restriction
Exercise ticket updates and entitlement changes under the same agent identity.
- Revocation behaviour
Permit the intended edit while denying the unrelated authority expansion.
Consider an illustrative situation in which a support agent should update a ticket but must not change account entitlements. This is a constructed example, not a client engagement or an observed Softlander outcome.
For ticket updates versus entitlement changes, an illustrative test would exercise both actions using the same synthetic user context. The desired boundary should be visible in enforcement and evidence. The architecture review would decide whether the tool surface and credential model are narrow enough or whether separate principals and approval paths are needed.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves revocation behaviour unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and next action
Keep the conclusion within the defined workflow and configuration
Confirm fit before the next commitment
- Necessary operation
- This review is limited to the defined workflow and configuration.
- Actor and role model
- The relevant owner must confirm access and the intended operating conditions.
- Authority model
- Production acceptance needs separate scoped evidence.
The method described here is proposed engineering work. Scope, staffing, implementation access, acceptance, and commercial terms require a readiness review. A design or lab result does not establish production suitability, guaranteed reliability, or security certification.
Ways to engage
Related engagement scopes
AI Fractional Agentic AI Office
Create a regular place for agentic AI decisions. Connect initiative priorities, architecture questions, risk ownership and evidence reviews.
AI Fractional Agentic Transformation Office
Coordinate the operating changes behind agent adoption. Align workflow redesign, ownership, dependencies and adoption measures.
AI Harness Engineering Pod
Engineer a bounded AI execution harness with tool adapters, context handling, orchestration, recovery and observable traces.
Continue exploring
Related insights and resources
Engineer the harness, not just the prompt
Define the contracts around an agent's decisions: what state it trusts, which actions can execute, how interrupted work resumes, and what evidence an operator needs to recover safely.
Governing agent decisions
Governance becomes useful when it changes a decision. Connect each agent workflow to an accountable owner, explicit operating conditions, proportionate evidence and a practical route for exceptions and withdrawal.
Do you need an agent centre of excellence?
A centre can concentrate scarce expertise and reusable controls, or become an approval queue detached from real work. Choose the mandate before the structure.