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

At a glance

What this is: This analysis examines self-assembling AI agents that choose tools and permissions at runtime, and shows why that creates identity and access control gaps.

Why it matters: IAM and NHI teams need to account for autonomous execution paths that can combine user, workload, and service identities in ways traditional controls were not built to govern.

👉 Read Aembit's analysis of self-assembling AI agents and identity risk

Context

Self-assembling AI agents are software systems that decide at runtime which tools to call, which data to read, and which actions to take. That shifts the security problem from protecting a fixed workflow to governing a dynamic one, where the agent may combine OAuth delegation, service accounts, API keys, and internal APIs in a single run. For IAM and NHI practitioners, the central issue is that the agent becomes a non-human identity with changing intent and changing access needs.

The article describes a pattern that is already showing up in support bots, research assistants, and developer tools. That is a familiar starting point for immature control environments: broad credentials, unclear accountability, and weak logging. In NHIMG terms, this is not an edge case but a preview of how agentic systems will stress identity lifecycle, access scoping, and audit controls across enterprise environments.

Key questions

Q: How should security teams govern AI agents that choose tools at runtime?

A: Security teams should treat runtime tool choice as a governed access event, not a normal application call. That means task-scoped credentials, explicit approval boundaries for sensitive actions, and logs that record both the tool selected and the identity used. If the agent can change its plan, the control model must be able to change with it.

Q: What is the difference between delegated access and agent authority?

A: Delegated access means a user authorizes an agent to act on their behalf for a defined scope. Agent authority means the software performs actions under its own operational identity. The distinction matters because blended flows can hide accountability gaps, especially when a single agent uses both user context and service credentials in one task.

Q: Why do autonomous agents increase NHI governance risk?

A: Autonomous agents increase NHI governance risk because they can create, combine, and use access paths at runtime rather than through a fixed workflow. That makes it harder to predict privilege, harder to review entitlements in advance, and harder to prove which identity was responsible for a specific action.

Q: Should organisations use ephemeral credentials for AI agents?

A: Yes, but only as part of a broader runtime control model. Ephemeral credentials reduce standing exposure, but they do not solve scoping, logging, or accountability on their own. Organisations should pair short-lived access with task context, tamper-evident logs, and automatic revocation when the agent finishes or changes intent.

Technical breakdown

How self-assembling agents change the access model

Traditional integrations are designed ahead of time, with fixed API calls, known service boundaries, and explicit permissions. In self-assembling systems, the LLM generates the plan at runtime and decides which systems to touch based on the prompt and context. That means access is no longer just a property of the application, but of the agent’s current reasoning path. The security problem is not only secret storage. It is also trust in the sequence of actions the agent invents, especially when those actions cross systems with different identity models.

Practical implication: Treat every runtime tool choice as a governance decision, not just an application detail.

Why OAuth delegation and static IAM roles both break down

OAuth works well when a user explicitly delegates access, while static IAM roles work when a workload’s permissions can be predicted in advance. Agentic systems often sit between those models. An agent may act on behalf of a user for one step, then perform system-level actions under its own authority in the next step. That blended identity creates accountability gaps and makes least-privilege policies harder to express. If the access pattern changes each run, fixed role design stops matching actual behaviour.

Practical implication: Map agent actions to separate delegated and system-authority trust paths before production rollout.

Ephemeral credentials need traceable context

Ephemeral credentials reduce standing access, but they do not solve the full problem unless they are tied to task, context, and audit trail. Without that linkage, the organization may know a token existed but not why it was issued, what the agent did with it, or which decision caused the action. The runtime control plane therefore matters as much as the credential itself. For NHI governance, this is where scoping, logging, and revocation have to work together rather than as separate controls.

Practical implication: Issue time-bound credentials with task context and immutable logs that link actions back to the agent decision.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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 agents create a new identity class that existing IAM tools only partially understand. These systems are not just workloads and not quite users. They can borrow delegated authority, call APIs autonomously, and change their action path from one run to the next. That makes them a distinct governance problem for NHI teams, because control design now has to follow runtime behaviour rather than predefined application logic.

Blended identity is the real operational risk, not agent intelligence itself. The article shows an agent reading data under a user context and writing system data under a service context, which is exactly where accountability becomes unclear. Once authority is split across identities, audit and approval models lose precision. Practitioners should treat mixed-authority flows as high-risk until they can be traced end to end.

Identity blast radius becomes the most useful concept for agentic AI governance. A single agent can touch multiple systems, each with different privileges and failure modes, so the impact of one compromised credential can expand quickly. That does not mean agentic systems should be blocked. It means access design must assume multi-system propagation and constrain the maximum damage of any one runtime decision.

Static access design is now a liability when the integration path is generated on the fly. Teams that still rely on broad roles, long-lived secrets, and manual approval gates will struggle to govern autonomous execution safely. The discipline now is to design for task-scoped access, continuous verification, and revocation that matches agent behaviour. The practitioner conclusion is simple: if the plan is dynamic, the controls must be dynamic too.

Security architecture for agentic AI must move from provisioning to orchestration. The control question is no longer only who gets access, but how access is created, observed, constrained, and withdrawn during execution. That changes procurement, engineering, and audit conversations at the same time. Practitioners should reframe agent security as runtime identity governance, not as a narrow secrets problem.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That visibility gap includes 38% with no or low visibility and a further 47% with only partial visibility, which leaves delegated access paths under-governed.
• For a broader view of how this pressure is reshaping the category, see Ultimate Guide to NHIs , 2025 Outlook and Predictions.

What this signals

Identity blast radius is the practical lens teams should use for agentic AI. When one agent can traverse multiple systems under mixed authority, the question is no longer whether access exists, but how far a single runtime decision can propagate before controls intervene. That is where zero trust and NHI governance need to converge in practice, not just in policy language.

The programme implication is straightforward: agent governance will fail if it is bolted onto human IAM review cycles. Autonomous systems need continuous verification, task-scoped access, and revocation paths that work at machine speed. Without that, security teams will discover agent behaviour only after the audit trail has already become too hard to reconstruct.

As agent adoption expands, teams should expect more pressure on delegated identity visibility, especially where OAuth-connected tools are involved. The combination of runtime planning and third-party access creates a governance gap that traditional entitlement reviews do not close. Practitioners should use the OWASP Agentic AI Top 10 to pressure-test where their current model assumes static behaviour.

For practitioners

• Define separate trust paths for agents and users Document when an agent is acting under delegated user authority and when it is acting under service authority. Require each path to have its own approval, logging, and revocation model so the audit trail reflects actual decision points.
• Scope credentials to a single task context Issue ephemeral credentials with explicit task boundaries, short TTLs, and runtime context labels such as workflow, ticket, or data domain. Revoke access automatically when the task completes or the agent changes plan.
• Log the runtime decision path Capture which tools the agent selected, in what order, and under which identity each action executed. Preserve those logs in a tamper-evident store so investigators can reconstruct blended identity flows.
• Review over-permissioned agent workflows Inventory support bots, research assistants, and developer productivity tools for inherited environment credentials, shared tokens, and broad API scopes. Reduce each one to the minimum access needed for the current run.
• Align controls to NHI lifecycle governance Apply provisioning, rotation, review, and offboarding discipline to agents the same way you would to other NHIs. The runtime identity should expire cleanly, leave an audit trail, and fail closed if governance checks are missing.

Key takeaways

• Self-assembling AI agents create governance risk because access is decided at runtime, not just assigned ahead of time.
• Mixed user and service authority makes audit, approval, and accountability models less reliable unless teams separate the trust paths.
• Practitioners should respond with task-scoped credentials, runtime logging, and lifecycle controls that match how agents actually behave.

Key terms

• Self-Assembling System: A self-assembling system is an AI-driven workflow that constructs its own integration path at runtime. Instead of following a fixed, prebuilt sequence, it selects tools, data sources, and actions dynamically based on the current prompt and context.
• Blended Identity: Blended identity is when a single agent uses more than one authority model in the same workflow, such as delegated user access and service-account access. This creates accountability ambiguity and makes auditing harder because the same action chain may involve multiple identities.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised identity can cause across connected systems. For AI agents, it expands when one runtime credential can touch multiple tools, APIs, and data stores in a single task.
• Task-Scoped Access: Task-scoped access is permission granted for one specific job, context, or time window rather than as standing access. In agentic environments, it helps limit misuse by ensuring the credential expires when the task ends or the agent changes intent.

Deepen your knowledge

AI agent identity governance and runtime access scoping are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for self-assembling systems, it is worth exploring.

This post draws on content published by Aembit: Self-Assembling AI and the Security Gaps It Leaves Behind. Read the original.