Access cloning is the assignment of permissions by copying another user’s profile, often a peer or senior teammate. It can accelerate onboarding, but it also imports unrelated entitlements and inherited privilege. Good governance requires validating copied access against the new role, not assuming similarity of job function.
Expanded Definition
Access cloning is a provisioning shortcut in which an identity is granted permissions by copying another account, usually a peer, manager, or role exemplar. In human IAM, this is often treated as a practical onboarding method; in NHI environments it becomes riskier because copied entitlements can include dormant secrets, inherited API access, or permissions tied to workflows the new identity should never execute. The concept sits close to role mining and template-based provisioning, but those methods rely on explicit role design, whereas cloning often relies on informal similarity. Guidance varies across vendors on how much automatic copying is acceptable, so governance should treat cloning as a starting point for review, not as an approval decision. For NHI programs, that review should check whether copied permissions align with least privilege, whether the identity will have standing access, and whether any secrets or tokens should be issued separately under tighter controls. The most common misapplication is using a senior employee’s access as a proxy for a new account’s needs, which occurs when teams confuse tenure or proximity with functional equivalence.
For control context, access cloning should be evaluated against least privilege and entitlement review practices described in the OWASP Non-Human Identity Top 10 and the NIST SP 800-53 Rev 5 Security and Privacy Controls.
Examples and Use Cases
Implementing access cloning rigorously often speeds onboarding, but it also introduces review overhead, forcing organisations to balance time-to-access against the cost of hidden privilege.
- A platform team creates a new deployment service account by copying permissions from an existing CI/CD account, then removes database write access because the new job only needs build and release functions.
- An AI agent is cloned from a support workflow template, but the team strips human-level ticket administration rights and issues a separate secret for tool invocation.
- A contractor’s account is provisioned from a colleague profile, then narrowed after a manager confirms the contractor does not need production data access.
- An operations bot is cloned from a senior engineer’s profile, but the copied access is revalidated before rotation to avoid inheriting unused SSH keys or cloud admin roles.
NHIMG’s research shows why this matters: 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts, as discussed in the Ultimate Guide to NHIs. Access cloning can be acceptable when it is paired with role-specific pruning, secret re-issuance, and documented approval. It is especially useful during rapid onboarding, temporary access restoration, or when a new NHI must match an already validated operational pattern. The challenge is that copied access often includes permissions that are convenient but not essential, so every clone should be treated as a draft entitlements set rather than a final state.
Why It Matters in NHI Security
Access cloning becomes a security issue when copied entitlements outlive the business need that justified them. In NHI environments, that can mean service accounts with broad cloud permissions, agentic tools with write access, or automation identities inheriting secrets that were meant for a different workflow. The result is privilege sprawl, weak accountability, and a larger blast radius if a cloned identity is compromised. NHIMG reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, underscoring how inherited access can quickly become an attack path. The same risk appears in guidance from the 52 NHI Breaches Analysis, where excessive permissions and poor lifecycle handling repeatedly intensified incidents. Access cloning should therefore be tied to periodic recertification, secret separation, and role-specific design rather than informal peer matching. Organizations typically encounter the damage only after a token is abused, a job changes scope, or an incident reveals that the cloned account had far more access than anyone expected, at which point access cloning becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret and privilege handling that cloning can propagate. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access rights management and authorization for identities. |
| NIST SP 800-63 | Identity proofing and authenticator binding matter when copied access creates new accounts. |
Bind each cloned account to its own approved identity and separate authenticators or secrets.
