AI agent self-assembly exposes gaps in identity and access control

At a glance

What this is: This is an analysis of how self-assembling AI agents change identity and access control, with the key finding that runtime plan selection breaks fixed IAM assumptions.

Why it matters: It matters because IAM, PAM and NHI programmes now have to govern agent behaviour, delegated access and auditability when the integration path is not known in advance.

Context

Self-assembling AI agents are software that decides which tools, APIs and systems to use while it is running. That means the identity problem is no longer just who can authenticate, but what authority a runtime plan can assemble across databases, internal systems and third-party tools.

The governance gap is that most access models assume the workflow is known before execution begins. When an agent derives its own sequence of actions, static roles, pre-approved paths and traditional audit trails no longer describe the actual decision-making boundary, especially when human and machine authority are blended.

This is an NHI and agentic AI governance problem at the same time. The subject article is about agent behaviour, but the access model it strains is the same one used to govern service accounts, delegated tokens and other non-human identities.

Key questions

Q: What breaks when AI agents assemble their own access paths at runtime?

A: Fixed IAM assumptions break because the access path is no longer known when permissions are granted. That makes predeclared roles, static scopes and manual approvals a poor fit for agentic workflows that decide which tools to call during execution.

Q: Why do blended user and system identities increase risk in agentic workflows?

A: They create two authority planes inside one task, so a single agent can act both as a delegated user and as a machine credential holder. That complicates accountability, makes scoping less precise and can hide when system-level privilege expands beyond the user’s original intent.

Q: How do teams know if agent access is staying inside its intended scope?

A: Measure execution-level evidence, not just identity events. Look for tool calls, resource access, action sequences, and revocation behaviour tied to a specific task. If the only evidence is authentication and token issuance, you do not have enough signal to judge scope adherence.

Q: What should security teams do when an AI agent touches both user data and backend systems?

A: They should separate delegated user permissions from backend service authority and log each identity transition explicitly. If the agent can cross from user context into system context without a clear control boundary, governance and incident reconstruction both become unreliable.

Technical breakdown

Runtime tool selection creates a moving identity boundary

In self-assembling agent architectures, the model selects tools and calls APIs during execution instead of following a prewired flow. That means the identity boundary is not just the account used to authenticate, but the sequence of downstream systems the agent can reach once it starts reasoning. Traditional integration patterns depend on known inputs, known paths and known authorisations. Agentic execution breaks that certainty because the path can change with prompt wording, context or task interpretation.

Practical implication: Practitioners need to treat runtime tool choice as an identity control point, not just an application design detail.

Blended identity mixes delegated user authority with system authority

The article’s blended identity example is important because the agent may act under a user’s delegated OAuth context and also use a service account or workload credential for system actions. That creates two authority planes in one session: user intent on one side and machine-level privilege on the other. The risk is not only over-privilege. It is also accountability ambiguity when the action chain spans multiple identities and control models, especially if the agent crosses from personal context into organisational data stores.

Practical implication: Practitioners should separate delegated user actions from system-level actions wherever the agent can switch authority mid-task.

Static IAM and OAuth models assume the access path is known up front

OAuth and predefined IAM roles both assume that access can be scoped before execution. That works when the workload or person has a stable purpose and a predictable sequence of systems. It fails when the agent builds its own path, because the access needed may emerge only after the task begins. The result is credential sprawl, over-permissioning and inconsistent logging, all of which make later review less meaningful. This is the core limitation of static authorisation for agentic systems.

Practical implication: Practitioners need runtime-scoped authority models, not only predeclared roles and broad tokens.

Threat narrative

Attacker objective: The objective is to exploit the agent’s runtime access path so that the resulting actions and accountability are difficult to constrain, trace or reverse.

1. Entry occurs when an AI agent is granted broad access through API keys, OAuth delegation or inherited environment credentials that were meant for a narrower workflow.
2. Escalation happens when the agent assembles additional tool calls at runtime, expanding from the initial task into databases, internal systems or third-party services not tightly scoped in advance.
3. Impact follows when inconsistent identities and weak logging make it difficult to trace what the agent did, which system it touched first, and who is accountable for the resulting change or exposure.

Breaches seen in the wild

• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Self-assembling AI agents create an identity boundary that is decided at runtime, not design time. That boundary shifts with each prompt, tool choice and execution path, so fixed access models no longer describe the real control surface. The practical implication is that IAM teams have to govern action paths, not just identities.

Blended identity is the governance problem hiding inside agentic workflows. When an agent uses delegated user authority and system authority in the same task, accountability is no longer attached to one stable subject. That is a structural problem for audit, approval and incident reconstruction, especially in mixed human-machine workflows.

Runtime plan selection exposes an ephemeral credential trust debt. The article shows that teams are still handing broad static access to systems that decide their own next step. The debt is that every extra token, inherited role or shared secret increases the gap between what was approved and what actually executed.

Static IAM assumptions were designed for known workflows, not self-assembling systems. Those assumptions fail when the agent’s access path is not knowable before execution and may vary on every run. The implication is that identity governance for agents must move from provisioning-time certainty to runtime context and traceable delegation.

AI agents should be governed as non-human identities with dynamic authority, not as enhanced applications. The article’s examples span databases, APIs and service accounts, which means the control problem sits squarely in NHI governance. Practitioners should treat agent behaviour as an identity lifecycle issue as much as an application security issue.

What this signals

Ephemeral credential trust debt: every time teams let an agent choose its own tool path, they create a gap between approval and execution that static IAM cannot close. The governance answer is not just more policy, but tighter runtime delegation and clearer identity transitions.

Enterprises should expect agent governance to converge with NHI governance, because the access problem is the same even when the reasoning layer is new. The control point moves from the login event to the moment authority is assembled and used.

A practical programme will need to distinguish between user delegation, workload authority and autonomous tool invocation. Without that separation, audit trails will describe the account structure, not the actual behaviour of the agent.

For practitioners

• Map every runtime authority path Inventory where an agent can obtain authority during execution, including OAuth delegation, service accounts, environment variables and inherited CI or dev identities.
• Separate user delegation from system privilege Ensure the permissions used on behalf of a user cannot silently expand into broader service account access when the agent switches from personal context to backend actions.
• Replace broad static tokens with task-scoped access Use ephemeral credentials tied to the current task and task context so the agent cannot reuse standing access across unrelated systems or later sessions.
• Make agent action trails auditable end to end Record which identity authorises each tool call, which context triggered it and which downstream system received it so incident review can reconstruct the full chain.

Key takeaways

• Self-assembling AI agents change the access problem because the system decides its own integration path while it is running.
• The main risk is not only over-permissioning but also blurred accountability when delegated user access and machine privilege coexist.
• Practical control has to shift toward runtime-scoped authority, end-to-end logging and explicit separation of user and system identities.

Key terms

• Self-Assembling Agent: An AI agent that chooses its own tools, APIs, and action sequence at runtime to complete a goal. In identity terms, the access path is not fully known at design time, so authorisation and audit controls must work on executed behaviour rather than fixed workflow assumptions.
• Blended Identity: Blended identity occurs when an autonomous system acts partly on behalf of a person and partly under its own machine authority. This creates split accountability because one actor may initiate the task while another identity performs the privileged action across different systems.
• Runtime scope: The effective boundary of what an identity can do while it is actively operating, not just what it was allowed to do at provisioning time. For AI agents, runtime scope matters because tool choice and execution timing can change during a live session.
• Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the hidden risk that appears when short-lived tokens create a false sense of safety while permissions remain broad. The credential expires quickly, but the underlying blast radius stays large unless identity scope, revocation, and audit controls are also tightened.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.