Agent identity maturity assessment
Prioritise the next improvements in agent identity controls
Identity investment is spread across tools without a shared view of weaknesses. The decision is how to prioritise the next improvements in agent identity controls. The work begins with your actual workflow and looks for the evidence that separates intended behaviour from a consequential exception. It is particularly relevant to CISOs and identity program leads. A useful outcome is an explicit account of what was examined, what remains uncertain, and which decision the evidence can support.
The identity and delegated authority relationship
- Identity inventories
Establish the basis for identity ownership.
- Authority lifecycle
Review issue, delegation, renewal, and removal.
- Evidence-based maturity profile
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around identity ownership
Questions and the evidence they need
- Identity ownership
- Inspect identity inventories for the relevant constraint or observation.
- Authority lifecycle
- Inspect architecture diagrams for the relevant constraint or observation.
- Control evidence
- Inspect lifecycle evidence for the relevant constraint or observation.
The decision is how to prioritise the next improvements in agent identity controls. This is relevant to CISOs and identity program leads when identity investment is spread across tools without a shared view of weaknesses. Name the affected workflow, the consequence of a wrong decision, and the owner who can act on the result. The initial discussion should establish which evidence is already available and which uncertainty is material enough to investigate.
The specific failure hypothesis is that a maturity score rewards documented policies while practical revocation or attribution remains untested. It remains a hypothesis until examined in the deployment. Existing internal tests or operating records may already resolve it; identify the uncovered question before commissioning additional work.
Mechanism
Readiness depends on evidenced identity controls
Relationships within identity and delegated authority
- Identity ownership
- Locate unowned principals and unclear purposes.
- Authority lifecycle
- Review issue, delegation, renewal, and removal.
- Control evidence
- Order improvements by dependencies and observed gaps.
What this specialty examines
Maturity assessment should score demonstrated practices rather than purchased features. Evidence might show ownership, controlled issuance, permission review, tested delegation, revocation and attribution. Mark missing evidence separately from a confirmed absence of a control.
The review should assess ownership, issuance, least privilege, delegation, review and evidence against defined criteria. Identify the normal route, relevant exceptions and the authoritative record of the outcome. Inspect the relevant business-system record, enforcement event or process evidence alongside any reported status. Keep incomplete cases visible, with an explanation of what their absence prevents the owner from concluding.
The tradeoff to make explicit
For this decision, a broad maturity view supports prioritisation while specific control failures need immediate local decisions. Compare the available design or operating choices against the same intended outcome. If one option removes a required control or changes the task boundary, describe that difference before treating its apparent simplicity, speed or lower effort as an improvement. The decision should expose the tradeoff instead of burying it in an aggregate score.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for identity ownership
Illustrative working format
- Identity inventories
- Use nonsecret metadata to trace issuance, acceptance, and withdrawal responsibility.
- Architecture diagrams
- Match this description to the deployed or proposed boundary being examined.
- Lifecycle evidence
- Name the custodian and the conditions requiring a refreshed version.
- Control-test results
- Retain the observed conditions and distinguish gaps from contrary evidence.
Start with identity inventories, architecture diagrams, lifecycle evidence and control-test results. Identify the owner, revision and operating context of each source. Sanitised examples may support initial design, but differences from actual conditions should remain explicit. Where direct access is unsuitable, a customer-controlled evidence or execution route may be considered, with agreed handling and retention.
The scope also needs the identity control owner, agreed expectations for a representative subject-action-resource case, and the authority to inspect the relevant boundary. Specify what evidence would distinguish the failure in which a maturity score rewards documented policies while practical revocation or attribution remains untested from acceptable behaviour. If stakeholders disagree about intended behaviour, resolve the interpretation before classifying the observed difference as a defect.
How the work proceeds
Carry identity ownership through to an accountable finding
From the scoped material to a decision record
- Identity inventories
Locate the source of the claimed authority.
- Authority lifecycle
Apply the scoped check to control evidence.
- Evidence-based maturity profile
Record the evidence, open dependencies, and the owner’s next decision.
Map principals, resources and authority
Reconcile identity inventories, architecture diagrams, lifecycle evidence and control-test results with the workflow described by CISOs and identity program leads. Identify the initiating actor, executing workload, target resource and component that grants access. Prepare paired cases that differ in one material authority condition, such as assignment, tenant, expiry or approval. The preparation output is an action map showing which permission is expected at each boundary and which records can verify it.
Exercise and review the authority path
Use the profile to sequence improvements, preserving critical local findings. A high overall score should not offset an untested control that governs a consequential action. Explain uncertainty and compare dimensions rather than implying that maturity is a universal certification.
Select the identity control change
Consolidate the checked paths into an evidence-based maturity profile and dependency-ordered improvement backlog. Distinguish an identity-verification problem from an excessive permission, lost delegation context or delayed withdrawal. Assign the proposed change to the component that controls the affected action. Before recommending wider use, identify the allowed case and denied counterpart that would demonstrate the revised boundary without breaking legitimate work.
Indicative artefact
Make the evidence-based maturity profile usable by its owner
Evidence-based maturity profile
Illustrative working format
- Evidence-based maturity profile
- Link observations and counterevidence to the case, configuration, and conclusion limit.
- Dependency-ordered improvement backlog
- Name the missing evidence, responsible owner, and condition for revisiting the decision.
- Authority lifecycle evidence
- Link observations and counterevidence to the case, configuration, and conclusion limit.
A useful decision artefact is an evidence-based maturity profile and dependency-ordered improvement backlog. Supporting material may include selected cases, configuration or process records, evidence references, a disagreement log and prioritised actions. Retain the case selection rationale and material disagreements alongside the result; otherwise the result may be mistaken for complete coverage.
Illustrative scenario
Examine control evidence through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Identity ownership
A complete identity inventory lacks proof of effective revocation.
- Authority lifecycle
Compare the inventory with lifecycle and enforcement evidence.
- Control evidence
Prioritise unproven removal and ownership controls before broader maturity claims.
Consider a fictional situation: an organisation has a sophisticated identity platform but cannot identify owners for several agent integration accounts. The scenario is illustrative, with no client engagement, executed test or measured improvement implied.
For ownerless accounts, prioritise reconciliation and accountability even if the identity platform is advanced. The immediate investment may be operating discipline rather than another tool. The assessment should identify that concrete dependency and its completion evidence.
Scope and next action
Keep the conclusion within named authority paths
Confirm fit before the next commitment
- Identity ownership
- This review is limited to named authority paths.
- Identity inventories
- The relevant owner must confirm access and the intended operating conditions.
- Evidence-based maturity profile
- Technical findings do not settle a disputed mandate.
Identity design and technical testing do not establish a legal mandate or resolve a disputed business authorisation. Qualified IAM review is needed for material control conclusions. Any engagement depends on an agreed scope, qualified team, authorised access and confirmed availability. Bring the affected workflow, its current configuration or process, the triggering change and the evidence already available. The immediate scope question is prompted by the situation in which identity investment is spread across tools without a shared view of weaknesses; confirm which missing observation would change the owner’s next action.
Ways to engage
Related engagement scopes
Agent Release Readiness Review
The Agent Release Readiness Review is a fixed-scope, three-week independent test of one AI agent workflow that shows a release board what the agent does, what it is allowed to do and what happens when it is wrong, and ends in a signed recommendation.
AI Agent Authorisation Review
Make delegated authority inspectable. Trace who an agent acts for, what it can access and how that access can be withdrawn.
AI Agent Runtime Security Review
Make every delegation explicit. Examine who the agent acts for, where it can execute and which tools it can reach when instructions alone are not enough.
Continue exploring
Related insights and resources
Designing agent authority boundaries
Turn agent permissions into an enforceable action contract. Separate a model's suggestion from a resource owner's authorisation, test the boundary, and make delegation and revocation reviewable.
The permission boundary behind every agent action
An agent can only be evaluated in the context of what its tools allow. Examine identity, delegated authority and action boundaries before you put a workflow in motion.
Before your agent can act, define its authority
A working paper for the moment an AI system moves from advice to action. Map identity, permissions, approvals and recovery into an authority model your team can review and test.