They should classify agents as governed non-human identities, assign clear owners, define explicit action boundaries, and include them in lifecycle and access review processes. If an agent can act on behalf of people, its identity cannot be left outside the migration design.
Why AI Agent Access Must Travel With the Identity
During an identity migration, AI agents should not be treated as temporary technical exceptions or folded into a people-only access model. They are governed non-human identities with their own ownership, permissions, and audit needs, especially when they can call tools, read sensitive data, or trigger actions on behalf of users. If the migration only moves human accounts cleanly, the organisation can create a split control plane where agent access becomes harder to see than the identities it depends on. Current guidance suggests treating agent access as part of the migration scope, not a later cleanup item.
That matters because agents often inherit broad permissions from the workflows they automate, then continue operating after the original business need has changed. In a migration, that can leave stale entitlements, duplicated credentials, or unclear approval paths across old and new directories. The result is not just administrative debt but an access boundary that no one fully owns. For a useful external reference, OWASP Top 10 for Agentic Applications 2026 frames the control problem around agent autonomy and bounded action. In practice, many organisations discover overprivileged agents only after migration cutovers have already scattered their credentials across multiple systems.
How It Works in Practice
Practically, organisations should inventory every agent that authenticates, whether it uses API keys, workload credentials, service accounts, delegated tokens, or embedded secrets. Each agent should be assigned an owner, an approved purpose, and a defined action boundary so the migration team can decide what is preserved, what is reissued, and what must be retired. The key question is not simply “does this agent still work,” but “does this agent still need this scope in the target identity model?”
That makes the migration design closer to non-human identity governance than to a one-time account move. Agents often need short-lived credentials, explicit authorization boundaries, and a clear link to the system or workflow they represent. A good migration process should therefore:
- classify agents separately from human users and shared admin accounts
- map every agent to its upstream owner, downstream dependency, and business purpose
- re-issue secrets or tokens rather than copying them unchanged into the new environment
- verify that the target platform can log, review, and revoke agent actions independently
- remove dormant or orphaned agents before cutover, not after
For governance depth, OWASP Non-Human Identity Top 10 is directly useful because it treats machine and workload identities as first-class security objects. NHIMG research on AI agent exposure also shows why this matters: in the AI Agents: The New Attack Surface report, 80% of organisations reported agents already performing actions beyond intended scope. That is the exact condition a migration can accidentally preserve if access is copied instead of re-governed. These controls tend to break down when teams migrate directories first and redesign agent authorisation later, because the old permissions model remains embedded in the new trust fabric.
Where Identity Migrations Go Wrong With Agents
Tighter control over agent access often increases migration effort, because the team must reconcile application owners, security owners, and platform owners before cutover. That tradeoff is unavoidable when agents can act independently, because a convenient lift-and-shift can carry hidden privilege into the new environment. Best practice is evolving, but there is no universal standard for this yet: organisations should not assume that human identity migration templates are sufficient for autonomous workloads.
The most common failure patterns are scope inflation, shadow ownership, and incomplete revocation. Scope inflation happens when an agent is given broader access “just to keep the workflow alive.” Shadow ownership appears when no team can explain who approved the agent’s current permissions. Incomplete revocation occurs when the old credential path remains valid after the migration, especially for agents using long-lived secrets or external integrations. A useful external control lens is the NIST AI Risk Management Framework, which helps organisations connect governance, measurement, and monitoring for AI-enabled systems, while CSA MAESTRO agentic AI threat modeling framework is useful when the migration must account for agent behaviour as well as identity plumbing.
For agent-heavy environments, the migration also needs a decision rule: if the agent can read sensitive data or execute changes in production, it should not be migrated with open-ended inherited access. It should be reauthorized against a current business need and bounded by observable controls. The point is not to slow migration down for its own sake. It is to make sure the new identity estate can tell the difference between a legitimate autonomous action and an access path that survived only because no one had time to challenge it.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Agents are non-human identities that must be inventoried and owned during migration. |
| NHI-03 — Secrets and Credential Management | Migration often requires reissuing agent credentials instead of copying them forward. | |
| NHI-05 — Lifecycle and Offboarding | Identity migration must include retirement of dormant or orphaned agent access. | |
| Recommendation — Inventory every agent identity and assign a responsible owner before moving access. Rotate and reissue agent secrets rather than preserving long-lived credentials across environments. Retire unused agent identities and revoke stale access as part of the migration. | ||
| OWASP Agentic AI Top 10 | A3 — Agent Boundaries and Authorization | The question centers on constraining what autonomous agents may do after migration. |
| A7 — Human Oversight and Escalation | Agents acting on behalf of people need review and escalation paths during migration. | |
| Recommendation — Define explicit action boundaries for agents before granting access in the target system. Route high-impact agent actions through human approval and exception handling. | ||
| CSA MAESTRO | GOV — Governance | Agent access migration is a governance problem involving ownership, policy, and accountability. |
| Recommendation — Treat agent access as governed AI identity scope with named accountability and policy controls. | ||
| NIST AI RMF | GOV — Govern | The migration must manage AI system accountability, policy, and oversight. |
| Recommendation — Establish AI governance rules that define ownership, scope, and review for agent access. | ||
| CIS Controls v8 | 5 — Account Management | Agent access must be tracked, reviewed, and removed like any other account lifecycle item. |
| Recommendation — Include agent accounts in access reviews, provisioning, and deprovisioning processes. | ||
Practitioner Guidance
What to prioritise: Put agent inventory, ownership, and permission scope ahead of directory cutover. If the migration team cannot answer who owns an agent, what it can do, and which system it is allowed to affect, that agent is not ready to move.
What to verify: Confirm that the target environment can distinguish agent activity from human activity in logs, review workflows, and revocation processes. If agent access is only visible through the same lens as employee access, the organisation will lose the ability to govern autonomous behaviour after the migration.
Common mistake: Do not copy long-lived credentials into the new platform just to preserve uptime. That shortcut often preserves hidden privilege, weak accountability, and stale access scope under a cleaner directory label.
Practitioner takeaway: Identity migration is the moment to reduce agent autonomy to an accountable boundary, not to rehouse it unchanged; if the boundary is unclear before cutover, the migration usually amplifies the governance gap rather than fixing it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
