Segregation of duties is among the oldest controls in accounting and among the best understood. It is also constructed entirely around an assumption that has stopped holding: that the actor performing a step in a transaction is a person, and that persons can be counted, distinguished and kept apart.
Key Takeaway
Segregation of duties separates initiation, authorisation and execution, and any entity holding all three roles on the same transaction is a violation. But the control was designed around human role boundaries, and has nothing to enforce a boundary against when the actor is a single automated process. The problem is compounded by privilege inheritance: an agent built with its creator's access can be invoked by a user who lacks that access, with no identity rule broken and no prompt injection involved, because the agent behaved exactly as configured. Practitioners report that by mid-2026 non-human identities outnumber human identities by 50 to 140 times in large enterprises, and that classical identity management, built for human joiner-mover-leaver cycles, cannot govern agents with no hire date, no manager and no offboarding trigger. A joint Five Eyes advisory published 1 May 2026, co-signed by the Canadian Centre for Cyber Security, is reported to name privilege risk as the foundational concern. The workable response is to enforce the separation outside the model rather than inside the prompt.
A Note On Sources
As with the drift article in this series, the evidence base here is practitioner and vendor material rather than peer-reviewed research, and readers should weigh it accordingly.
Most sources cited are commercial publications from companies selling identity governance, agent security or approval tooling, and one is an encyclopedia entry. The governmental and standards material referenced, including the Five Eyes advisory and the NIST initiative, reaches us through a technology publication rather than from the documents themselves, and we have flagged that at each point.
What makes the material worth reporting despite this is that the structural argument is verifiable by inspection. A reader can check whether segregation of duties in their own environment is defined over people, and whether an agent in their environment holds more than one role. Neither question requires trusting a vendor.
The Three Roles
The control, stated in its conventional form.
One source sets out the decomposition: initiation, meaning identifying that something should happen and generating the request; and authorisation, meaning independently evaluating whether it should happen and approving it. It adds that any entity holding all three roles on the same transaction is a segregation of duties violation, and that this is true in accounting, in IT access management, in procurement, and now in AI-driven automation[1].
The third role, execution, is the performance of the action itself.
The related maker-checker formulation is described as one of the central principles of authorisation in the information systems of financial organisations, meaning that for each transaction there must be at least two individuals necessary for its completion, so that while one individual may create a transaction, the other should be involved in confirmation or authorisation, with segregation of duties playing an important role in keeping strict control over system software and data[2].
Another states the four-eyes principle as one person preparing or requesting an action and another independent person reviewing and approving it before the action is completed, also called maker-checker, dual control or two-signature approval, used to separate duties for payments, exceptions and high-risk changes, with audit evidence expected to show both the maker action and the checker decision[3].
Two words in those formulations do the work and will recur throughout this article: individuals and independent.
The Structural Problem
The claim this article is built on, stated by one source with unusual clarity.
Segregation of duties was designed around a specific kind of actor, and AI agents do not match it, with the result that segregation of duties, a control built on human role boundaries, has nothing to enforce a boundary against when the actor is a single automated process[1].
The distinction between a control failing and a control having nothing to attach to is worth drawing carefully, because it determines what a remediation looks like.
A failing control is one that exists and is not operating: a checker who approves without reviewing, a matrix with a conflict nobody noticed. The remedy is enforcement of the existing design.
A control with nothing to attach to is different. The design presupposes a boundary between actors, and where one actor performs the whole transaction there is no boundary to enforce. No amount of diligence in operating the control produces separation, because separation is not a property the arrangement has.
For a Canadian finance function the practical test is straightforward. Take any workflow where an agent has been introduced and ask which of initiation, authorisation and execution it performs. If the answer is more than one, the segregation that the control framework asserts is not present, regardless of what the framework says.
They Are Not Synonyms
A distinction the literature draws and practice generally collapses.
One source notes that while frequently conflated in casual industry discourse, the four-eyes principle, dual control and segregation of duties represent distinct methodologies[3].
The distinction matters here because the three degrade differently under automation, and this is our own analysis.
Segregation of duties is structural. It concerns which roles a given actor may hold across a process, and it is defined in advance in a matrix. It degrades when an actor acquires roles the matrix did not contemplate, which is precisely what an agent does.
Four-eyes is transactional. It concerns a specific action requiring two parties, and it degrades when one of the two parties is not exercising judgment, which is the automation bias problem this publication has examined.
Dual control is possessive. It concerns joint access to something, requiring two parties to act together, and it degrades when an agent holds credentials that were meant to be split.
A firm that has collapsed the three into a single idea of two people signing will address one degradation mode and miss the others, and the structural one is the hardest to see because it lives in a matrix rather than in a transaction.
Independence Is The Load-Bearing Property
The reason the control works at all, which the definitions state and which is easy to read past.
The four-eyes formulation specifies another independent person[3], and the initiation and authorisation decomposition specifies independently evaluating whether it should happen[1].
Independence is what makes two reviews better than one. If the second reviewer's judgment is uncorrelated with the first, then the probability of both missing the same defect is the product of two probabilities rather than either alone. That multiplication is the entire statistical basis of the control.
Where the two are correlated, the benefit collapses toward that of a single review while the cost doubles. The automation bias article in this series raised this in relation to two human reviewers operating under shared deadlines and shared assumptions about a system's reliability, and noted that the research on whether teams outperform individuals on automation bias exists and that we did not have its findings.
The reason to establish the point here is that the correlation question becomes decisive in the next section, where the proposed second reviewer is not a person at all.
Why Two Agents Do Not Help
The most common proposed fix, and the argument against it. This section is our own analysis.
Told that an agent should not approve its own work, an engineering-minded organisation reaches for a second agent. One proposes, another reviews. The structure of maker-checker is reproduced, two actors appear in the log, and the control framework can be updated.
This satisfies the form and not the property. Two instances of the same model, given the same context, are not independent judges in any sense the control requires. They share training, they share failure modes, and where the same prompt lineage and retrieval sources are used they share inputs.
The correlation is also of a different order from correlation between two humans. Two accountants under the same deadline are correlated by circumstance and culture, and remain distinct minds with distinct experience. Two invocations of one model are the same function evaluated twice.
A second model from a different provider is a genuine improvement on this axis, and we would still be cautious. The benchmark contamination article established that models are trained on overlapping public data and that frontier systems have converged on many measures, so their errors are unlikely to be independent even across vendors.
Our conclusion is that an agent may be a useful additional check, and should not be counted as the independent second party the control specifies. Where the framework requires independence, the second party should be a person, and the agent's review should be recorded as a supplementary control rather than as the checker.
Configuration Is Not Reality
The illustration that best conveys why this is not a hypothetical concern, and it is worth quoting closely.
One source describes an agent built in maker mode that inherits its builder's admin-level access to a connected customer relationship system. A user with no entitlement to that system invokes the agent and pulls restricted customer records. No identity rule was broken. No prompt injection occurred. The agent behaved exactly as configured. Yet security-of-processing duties under one privacy regime, the minimum-necessary principle under another, and the access-control expectations in common audit frameworks were all crossed, because the effective access of the agent bypassed the controls named in the risk assessment[4].
The same source characterises this as the shift from theoretical configuration to runtime truth: the configuration page shows what the vendor allows in principle, and does not show that this agent, running as this service account, read these customer objects for that invoker. Configuration is not reality, and that gap is exactly what an agent can walk through[4].
Three features make this the most instructive example in the material.
Nothing malfunctioned. There is no defect to fix, no exploit to patch and no misconfiguration to correct, which means every detective control looking for anomalies would find nothing.
The violation is of the access model rather than of any rule. The user obtained data they were not entitled to, through a mechanism that granted it legitimately.
And the gap is between the documented control and the operating reality, which is the gap an audit is supposed to close and which this particular arrangement is unusually good at hiding.
The Escalation Channel
Generalising the example, offered as our own analysis.
The pattern described is a privilege escalation channel that requires no attacker. An agent holds permissions granted to its builder. Invocation of the agent is granted more widely than those permissions. Therefore anyone who can invoke the agent can act with the builder's access, within whatever the agent is willing to do.
In a Canadian finance function this shape appears wherever a senior person builds a helper that others use. A partner builds an agent with access to the full client file set; staff use it. A controller builds an agent with access to the general ledger; the team invokes it. In each case the effective access of the invoker is the union of their own permissions and the agent's, and only the first appears in the access review.
Two questions follow that a firm can ask immediately. Whose credentials does each agent run under? And who can invoke each agent?
Where the second set is larger than the set entitled to the first set's access, an escalation channel exists. It may be entirely benign in effect, and it is still a difference between the documented access model and the operating one, which is the thing an access review exists to detect and in this case cannot.
Your SoD Matrix Describes People
The governance consequence, and the reason a firm can pass a review while the control is defeated.
A segregation of duties matrix is a table of roles against incompatible functions, maintained in a human resources or identity system, and reviewed periodically against the people holding those roles.
It describes permissions granted to persons. It does not describe effective access obtained through agents, for the reasons the previous section sets out, and it does not describe roles held by agents, because agents are not in it.
So a firm can complete an access review, confirm no person holds conflicting roles, and be entirely correct, while an agent in one of its workflows performs initiation, authorisation and execution on the same transaction. The review was accurate about what it examined and silent about the actor that mattered.
Practitioner commentary names this among the concrete gaps: segregation of duties policy coverage that spans human and non-human identities[5].
The remediation is unglamorous. Agents belong in the matrix as actors, with the roles they hold recorded, and the review has to cover them. That requires first knowing which agents exist, which is the inventory problem the scale section below describes.
Fifty To One Hundred And Forty Times
The figure that determines whether conventional methods can work at all.
One source reports that by mid-2026, non-human identities outnumber human identities by 50 to 140 times in large enterprises, describing this as a range cited consistently across analyst research[5].
We report the figure as stated and note it concerns large enterprises rather than the mid-sized Canadian firms this publication addresses, and that the underlying analyst research was not accessed.
The ratio nonetheless has an implication that survives uncertainty about its precision. Access review as conventionally practised, in which a manager confirms each identity's entitlements periodically, is a process whose cost scales with the number of identities. At a ratio of even ten to one it becomes the dominant workload in the review; at fifty to one hundred and forty it is not performable.
The same commentary lists what accumulates in the absence of governance: orphaned accounts, privilege creep, excessive global roles, dormant service accounts, shadow identities, AI agents with unclear ownership, and non-human identities without lifecycle governance[6].
Every item on that list is familiar to anyone who has run an access review. The point is that each becomes substantially harder at the ratio described, and that the mid-sized firm's version of this problem is smaller in absolute terms and identical in shape.
No Hire Date, No Manager, No Leaver Trigger
The specific reason existing processes do not extend, and it is well put.
One source states that classical identity and access management, built for human joiner-mover-leaver cycles, cannot govern agents that have no hire date, no manager and no offboarding trigger[5].
Consider how a Canadian firm actually removes access today. Someone resigns, human resources records a leaving date, and a process revokes entitlements. The control is reliable because it is driven by an event the organisation cannot miss.
An agent has no such event. It is created during a project, it persists, and nothing in the organisation's calendar prompts anyone to ask whether it should still exist. There is no equivalent of a final day.
The mover case is worse. When a person changes role, their entitlements are reviewed because the change is recorded. When an agent's purpose changes, typically by someone extending what it does, no record is created and no review is triggered.
The practical instruction, and this is our own recommendation, is to give every agent three attributes at creation: a named human owner accountable for it, a stated purpose, and an expiry date requiring affirmative renewal. The expiry is the substitute for the leaver event, and it is the only mechanism that reliably removes things nobody remembers creating.
The Five Eyes Advisory
The governmental position, which has direct Canadian relevance.
One source reports that CISA's first joint Five Eyes advisory on the topic, titled around careful adoption of agentic AI services and published 1 May 2026 with the NSA, the Australian Signals Directorate's ACSC, the Canadian Centre for Cyber Security, and the New Zealand and United Kingdom national cyber security centres, converges on the conclusion that privilege risk is the foundational concern. The same source records that the Center for Internet Security followed with a report on prompt injection as the top compounding risk in April 2026, and that a NIST AI Agent Standards Initiative launched in February 2026 is drafting formal standards[7].
Its summary of the position is worth reporting: the dominant risk class introduced by agentic AI is not novel cryptography or some new exploit primitive, but the unbounded scope of an identity that the existing identity model was never asked to govern[7].
We flag clearly that we have not read the advisory and are reporting a technology publication's characterisation of it, and readers with material exposure should obtain the document directly.
The reason it matters for a Canadian audience is the signatory. The Canadian Centre for Cyber Security is part of the Communications Security Establishment, so this is not a foreign regulator's concern reaching Canada indirectly. On this reporting, Canada's national cyber authority has joined a position that privilege risk is the foundational issue in agent adoption.
The Control Must Live Outside The Model
The architectural principle, which is the most important design point in this article.
One vendor describes enforcing segregation of duties in code, so that an agent proposing an irreversible action is refused as its own approver by a hard rejection rather than a prompt-level promise, and states that because this boundary sits outside the model, even a fully compromised agent cannot sign off its own work. It contrasts the approaches directly: prompt filters are probabilistic, whereas the described mechanism is a deterministic runtime fence outside the model, and rather than attempting a better prompt-injection filter it scopes the blast radius of the agent's tools.
This is vendor marketing for a specific product and we report it as such. The architectural distinction it draws is nonetheless correct and generalises well beyond any product.
The distinction is between a control expressed as an instruction to the model and a control expressed as a constraint on what the model can cause to happen. An instruction saying always obtain approval before transferring funds is a request that the system will usually honour. A gate that refuses the transfer unless an approval record exists is a control.
The phrase probabilistic versus deterministic captures why this matters for a finance function specifically. Control frameworks are built on assertions that something cannot happen, and a probabilistic mechanism cannot support that assertion at any confidence a control framework recognises.
Our formulation of the principle, which we would apply regardless of tooling: if the only thing preventing an action is text in a prompt, the control does not exist. The enforcement point must be somewhere the model cannot reach, which in practice means the system executing the action rather than the system requesting it.
Two Workable Patterns
The designs that preserve the control, both of which are usable by a mid-sized Canadian firm.
One source sets out the first: the agent handles initiation and, once approved, execution, while a human handles authorisation in between, giving the example of an agent detecting an inactive account and preparing the deprovisioning action, with a person confirming it before it runs[1].
The elegance of this arrangement is that it maps exactly onto the classical decomposition. The agent takes the two roles that were always compatible, initiation and execution, and the human retains the one that must be separate. It is maker-checker with the maker automated.
The second pattern is bounded autonomy: defining narrow conditions under which an agent can act without a human step, limited to low-risk, low-impact, easily reversible actions, with everything outside that scope requiring authorisation. The example given specifies an agent removing a licence for an inactive user with no active projects and under fifty dollars a month in spend running autonomously, while an agent with access to a sensitive role cannot[1].
What makes that example instructive is its specificity. The boundary is defined by conjunctive, checkable conditions rather than by a judgment about risk appetite, which means the gate can be implemented and audited.
A finance translation would look similar: an agent may post an adjusting entry autonomously where the amount is below a stated threshold, the account is not a control account, the period is open, and the entry reverses automatically. Every clause is machine-checkable, and failing any one of them routes to a person.
Reversibility, Independently Arrived At
A convergence worth noting explicitly.
The bounded autonomy pattern above limits autonomous action to what is easily reversible[1]. The preceding article in this series, working from function allocation theory, argued that the automation level for the execution stage should be set by reversibility rather than by capability.
These are different literatures reaching the same criterion. Function allocation asks how much automation a stage should carry; identity governance asks when an agent may act alone. Both answer with reversibility rather than with how well the system performs.
We think the convergence is not accidental and the reason is worth stating. Capability determines how often the system will be right. Reversibility determines what happens on the occasions it is wrong. A control framework is concerned with the second, because the first is never one hundred percent and the residual is where the exposure lives.
For a Canadian finance function this yields a simple ordering rule for deciding what an agent may do unsupervised. Not the tasks it performs best, but the tasks whose errors are cheapest to undo.
What The Audit Evidence Shows
A question that determines whether any of this is defensible after the fact.
The four-eyes formulation specifies that audit evidence should show both the maker action and the checker decision[3]. One source describes coupling audit logging with the four-eyes principle so that logging transforms from a passive repository of historical data into an active deterrent, and characterises well-designed logging as establishing a verifiable chronological narrative of system events[3]. The approval-gate vendor requires a named person to sign with a recorded reason, and states that anyone can verify the record offline.
Two observations for a firm designing this, offered as our own analysis.
A log entry recording that an agent approved something is evidence that a process ran. It is not evidence of independent judgment, because the entity recorded did not exercise any. If the framework asserts an independent second review, the evidence needs to show a person.
And the recorded reason requirement is more valuable than it appears. A checker who must state why in free text is performing an act that cannot be completed inattentively, which addresses the automation bias failure mode where approval degrades into a click. It also produces the contemporaneous record the incident response article identified as unreconstructable later.
The corollary is that approval interfaces offering a single button are optimised against the control they implement, and adding a mandatory reason field is among the cheapest control improvements available.
Recertify Policies, Not Agents
The operational answer to the scale problem, and a genuinely useful reframing.
Practitioner commentary names among its concrete gaps the need for recertification of policies rather than thousands of individual agents[5].
The reframing matters because the conventional access review recertifies identities: each quarter, each manager confirms each person's entitlements. At the identity ratios described that process does not scale, and an organisation attempting it will either not complete it or complete it without attention, which the base rate discussion in this series predicts will follow.
Recertifying policies inverts the unit. Rather than confirming that this agent should have these permissions, the review confirms that this class of agent, defined by its purpose, should be permitted this set of capabilities, and that the assignment of agents to classes is correct.
That is tractable at scale because the number of policies is bounded by the number of distinct purposes rather than by the number of instances.
For a mid-sized Canadian firm the version of this that works is a short list of agent classes with defined permission sets, and a rule that an agent must belong to a class. The review then covers the classes, and the exceptions are the agents that do not fit one, which is a much shorter list and a more informative one.
A Worked Case: The Payment Run
A Canadian firm introducing agent assistance into supplier payments. The reconstruction illustrates the control question rather than reporting a specific engagement.
The existing control is classical. One person prepares the payment file, a second authorises it, and release requires dual credentials. The matrix records that no individual holds conflicting roles, and the annual review confirms it.
An agent is introduced to prepare the run: it identifies due invoices, matches them to receipts, applies the payment terms and assembles the file. That is initiation, and on the first pattern above it is exactly the role an agent should hold[1].
Scope then expands, as it does. The agent is extended to clear exceptions it can resolve, which is a limited authorisation. It is given the ability to submit the file, which is execution. No single decision was unreasonable and each was an increment.
The firm now has one actor performing all three roles, which is the violation as defined[1], and its matrix will not show it because the matrix describes people. The access review will pass.
Separately, the agent runs under the credentials of the person who configured it, so whoever can invoke it acts with that access[4], and the invocation right was granted more widely than the underlying entitlement.
The remedy is not to remove the agent. It is to place the authorisation gate outside the model, require a named person with a recorded reason, give the agent its own identity with its own scoped permissions rather than inherited ones, and record it in the matrix as an actor.
What To Do
Ask which of the three roles each agent holds. Initiation, authorisation, execution. More than one on the same transaction is the violation, whatever the matrix says.
Put agents in the segregation of duties matrix as actors. A matrix describing only people is silent about the actor that matters.
Give every agent its own identity, not an inherited one. Where it runs under a builder's credentials, everyone who can invoke it has that builder's access.
Compare the invocation set to the entitlement set. Where more people can invoke than are entitled to the underlying access, an escalation channel exists.
Move the gate outside the model. If the only thing preventing an action is text in a prompt, the control does not exist. Prompt instructions are probabilistic; a runtime refusal is not.
Do not count a second agent as the independent checker. Two invocations of one model are the same function evaluated twice, and independence is what makes two reviews worth more than one.
Scope autonomy by reversibility, not capability. Use conjunctive, checkable conditions, so the boundary can be implemented and audited.
Require a named approver and a recorded reason. A free-text reason cannot be supplied inattentively, and single-button approval is optimised against the control it implements.
Give each agent an owner, a purpose and an expiry. There is no leaver event for an agent, so expiry with affirmative renewal is the substitute.
Recertify classes of agent, not instances. Per-identity review does not scale at the ratios reported, and a review nobody completes is worse than a smaller one that is done properly.
The Limits Of This Analysis
Several caveats matter. The evidence base is practitioner and vendor material rather than peer-reviewed research: most sources are commercial publications from companies selling identity governance, agent security or approval tooling, one is an encyclopedia entry, and one is a personal conference write-up. The Five Eyes advisory, the Center for Internet Security report and the NIST standards initiative are reported through a technology publication rather than from the documents themselves, and we have not read the advisory; readers with material exposure should obtain it directly. The 50 to 140 times identity ratio is reported as a range cited across analyst research that we did not access, and it concerns large enterprises rather than mid-sized Canadian firms. Privacy and health regimes referenced in one example are foreign to Canada and we have described them generically rather than asserting their content. The argument that two agents cannot serve as independent checkers, the escalation channel generalisation, the matrix silence argument, the distinction between the three control types degrading differently, the agent lifecycle attributes, the audit evidence reasoning and the finance worked case are our own analysis rather than findings in the cited material. This article does not address prompt injection defence, agent authentication protocols, delegated authorisation standards, Canadian privacy obligations where personal information is processed, or auditor expectations under Canadian assurance standards. Nothing here is a substitute for professional advice on control design or identity governance in a specific environment.
Frequently Asked Questions
Why doesn't segregation of duties work for agents?
Can I use a second agent as the checker?
What is the privilege inheritance problem?
Why won't our access review catch this?
Where should the control be enforced?
How do we decide what an agent may do alone?
References
- CloudEagle.ai. (2026, July 13). Why AI Agents Break Segregation of Duties Controls, on the decomposition into initiation and authorisation, any entity holding all three roles being a violation, segregation of duties having nothing to enforce a boundary against when the actor is a single automated process, the agent-initiates-human-authorises pattern, and bounded autonomy limited to low-risk, easily reversible actions with the licence removal example. Note: published by a vendor of software management tooling. cloudeagle.ai/blogs/segregation-of-duties-ai-agents
- Maker-checker, encyclopedia entry, on the principle as central to authorisation in financial information systems, requiring at least two individuals for each transaction with one creating and another confirming or authorising, and on the role of segregation of duties in maintaining control over software and data. Note: an encyclopedia entry rather than a primary or peer-reviewed source. en.wikipedia.org/wiki/Maker-checker
- Chequedb. (2026, March). Four-Eyes Principle: Maker-Checker and Two-Signature Control, on the definition requiring another independent person, its use for payments, exceptions and high-risk changes, the expectation that audit evidence show both maker action and checker decision, the distinction between four-eyes, dual control and segregation of duties as distinct methodologies, and audit logging as an active deterrent when coupled with four-eyes. Note: published by a payments software vendor. chequedb.com/resources/blog/four-eyes-principle-foundations
- Obsidian Security. (2026, July). AI Agent Regulations: 2026 Overview, on the maker mode example of an agent inheriting admin access, a user without entitlement obtaining restricted records with no rule broken and no injection occurring, the crossing of security-of-processing, minimum-necessary and access-control expectations, and the characterisation that configuration is not reality. Note: published by a security vendor. obsidiansecurity.com/academy/ai-agent-regulations-2026
- Nexis. (2026, June 1). AI Agent Governance: EIC 2026 Takeaways, on the named gaps of ownership assignment, segregation of duties policy coverage spanning human and non-human identities, and recertification of policies rather than thousands of individual agents; on non-human identities outnumbering human identities by 50 to 140 times by mid-2026; and on classical identity management being unable to govern agents with no hire date, manager or offboarding trigger. Note: a conference write-up published by a security consultancy; the analyst research behind the ratio was not accessed. nexis-secure.com/insights/blog/ai-agent-governance-my-eic-2026-takeaways
- Digital Proton. (2026, July 25). From Human Users to Agentic AI: Rethinking Identity Governance in 2026, on the accumulation of orphaned accounts, privilege creep, excessive global roles, dormant service accounts, shadow identities, agents with unclear ownership and non-human identities without lifecycle governance, and on agents as digital actors requiring authentication, authorisation and access scopes. Note: published by a technology consultancy. digitalproton.com/from-human-users-to-agentic-ai-rethinking-identity-governance-in-2026-2
- CSO Online. (2026, July 9). Agentic AI Identity: A 6-Stage Maturity Model for Non-Human Identities, reporting the joint Five Eyes advisory of 1 May 2026 co-signed by the Canadian Centre for Cyber Security and naming privilege risk as the foundational concern, the Center for Internet Security report of April 2026 on prompt injection, the NIST AI Agent Standards Initiative launched February 2026, and the characterisation of the dominant risk class as the unbounded scope of an identity the existing model was never asked to govern. Note: the advisory and other documents were not accessed directly. csoonline.com/article/4194548
This article discusses control design and identity governance and is provided for general informational purposes. Its sources are practitioner and vendor publications rather than peer-reviewed research, and several cited vendors sell related tooling. Government and standards documents are reported through a secondary publication and were not accessed directly. Nothing here is a substitute for professional advice on control design or identity governance. Some statements in this article are the publication’s own analysis and are not attributed to a published source; treat any such point as a starting position to verify rather than as a sourced fact.