Self-assembling AI agents expose the gaps in static IAM models

At a glance

What this is: This analysis argues that self-assembling AI agents create a runtime identity and access problem because they choose tools and credentials dynamically instead of following fixed workflows.

Why it matters: IAM and NHI teams need to treat agent actions as governed access events, not just application behavior, or they will lose control of privilege scope, accountability, and rotation.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Aembit's analysis of self-assembling AI and runtime access gaps

Context

Self-assembling AI agents change the access problem because the system no longer follows a fixed integration path. Instead, the agent decides at runtime which tools, data sources, and credentials to use, which means traditional IAM assumptions about known workflows and stable entitlements start to break down for NHI governance.

That matters because the security question shifts from whether a workload can authenticate to whether its runtime decisions stay inside an approved trust boundary. For teams managing AI agents, service accounts, and delegated access, the practical issue is controlling identity, scope, and auditability when the execution path is not fully known in advance.

This pattern is already visible in support bots, research assistants, and developer productivity tools, so it is not a theoretical edge case. The starting point described in the article is increasingly typical for early agentic deployments, which is why security teams should treat it as an emerging baseline rather than a novelty.

Key questions

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

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: What is the difference between delegated user access and machine authority for AI agents?

A: Delegated user access comes from a human authorization context, usually through OAuth or a similar consent flow. Machine authority comes from the system or workload identity that actually executes the action. Mixing the two in one agent makes accountability unclear, so mature programmes keep them separate and audit both paths independently.

Q: Why do self-assembling AI agents create more IAM risk than fixed workflows?

A: Fixed workflows expose a known sequence of systems, permissions, and audit points, so IAM teams can design controls around them. Self-assembling agents decide the sequence at runtime, which means the access path can vary by prompt, data, or available tool. That unpredictability makes least privilege and logging harder to enforce.

Q: Should organisations use standing credentials for autonomous AI agents?

A: Organisations should avoid standing credentials for autonomous agents wherever possible. Standing access expands blast radius, hides over-permissioning, and makes it harder to prove why the agent needed access at a specific moment. Ephemeral, task-scoped credentials are safer because they reduce persistence and make review and revocation more practical.

Technical breakdown

Runtime tool selection changes the access model

In self-assembling systems, the agent does not merely call a prewired API sequence. It interprets a goal, selects tools at runtime, and often chains multiple systems together to complete the task. That makes the access path dynamic, which complicates approval, logging, and policy enforcement because the system cannot rely on a single fixed role or workflow. The result is a governance problem as much as a technical one: identity decisions happen after the prompt is issued, not before the action begins. Practical implication: design controls that inspect each runtime action, not just the initial login or token issuance.

Practical implication: inspect each runtime action, not just the initial login or token issuance.

Blended identity creates accountability gaps

The article highlights a blended identity pattern where an agent may act on behalf of a user through OAuth delegation while also using a service account or another system identity. That hybrid model is difficult to audit because the agent’s authority is split across human context and machine context. When the same agent can read a user-scoped resource and then write to a system-scoped target, traditional ownership models become unclear. This is a core NHI issue because the entity performing the work is autonomous, but the privileges often come from legacy human or workload assumptions. Practical implication: separate delegated user authority from system authority wherever possible.

Practical implication: separate delegated user authority from system authority wherever possible.

Static IAM and OAuth are not enough for autonomous agents

Static IAM roles assume the workload’s needs can be known ahead of time, while OAuth assumes a person or process is explicitly authorizing access. Self-assembling agents weaken both assumptions because the agent’s plan changes with context, prompt wording, and available tools. That creates pressure for context-aware identity, ephemeral credentials, and tighter scoping tied to task and time. The article also points toward authenticated delegation as a better fit than broad standing access, because it can preserve traceability while limiting privilege. Practical implication: move from permanent entitlements to task-bound access paths with explicit logging.

Practical implication: move from permanent entitlements to task-bound access paths with explicit logging.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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 a runtime identity gap that conventional IAM was never built to close. The core issue is not whether the agent can authenticate, but whether each tool decision remains inside a governed trust boundary. Static roles and predeclared workflows do not capture that reality, so access control has to move closer to execution time. Practitioners should treat this as a design failure in current identity models, not just a monitoring problem.

Blended identity is the name of the new control problem. When an agent uses both delegated user access and system-level authority, accountability becomes split across human, workload, and application layers. That makes audits harder and increases the chance that privilege creep hides inside ordinary automation. The field needs clearer separation between who approved the task, which identity executed it, and which system credentials were used.

Ephemeral credential trust debt is accumulating faster than most teams can repay it. The article’s examples show how quickly secrets, tokens, and environment variables become embedded in agent workflows. That debt grows when teams prototype first and secure later, because every temporary shortcut becomes a future governance exception. The practical conclusion is simple: if access cannot be scoped, logged, and rotated, it should not be handed to an autonomous agent.

Runtime governance will become the differentiator for agentic AI security. The market is moving toward controls that evaluate context, task, and duration instead of trusting broad standing access. That direction validates zero standing privilege thinking, but it also complicates implementation because teams must redesign how agents obtain and retain authority. Security leaders should expect agent governance to sit at the intersection of IAM, PAM, and NHI lifecycle control.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 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.
• For a wider attacker pattern: When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, which is why LLMjacking: How Attackers Hijack AI Using Compromised NHIs remains relevant to agent credential governance.

What this signals

Ephemeral credential trust debt: the faster teams prototype agent workflows, the more temporary access paths become permanent governance exceptions. That creates an operational backlog for IAM, PAM, and NHI owners because every shortcut must eventually be rotated, reviewed, or removed. The reader response is to make runtime credentials expire by default and to enforce review cycles before agent sprawl becomes normalised.

The governance signal is that agentic AI is pushing identity controls closer to zero standing privilege and task-scoped authority. That aligns with the NIST AI Risk Management Framework and with the OWASP Agentic AI Top 10, both of which treat autonomous behaviour as a risk-management problem, not just a development pattern. Teams should prepare for access review processes that include agents, not only people.

As agent toolchains expand, hidden dependencies will move from isolated bots to linked chains of service accounts, tokens, and delegated scopes. That expands the impact of a single compromised secret and makes discovery the first control to mature. Practitioners should be able to answer which agent can touch which system, under what scope, and for how long, before the next use case goes live.

For practitioners

• Inventory agent identities and hidden credentials Map every AI agent, bot, workflow, and service account that can initiate actions, then trace where its credentials are stored, inherited, or delegated. Include environment variables, YAML files, CI jobs, and third-party tool connections in the review.
• Scope access to the task, not the platform Replace broad standing entitlements with time-bound, task-specific permissions that expire after the agent completes the workflow. Where possible, issue ephemeral credentials and require explicit approval for sensitive actions such as writing, deleting, or exporting data.
• Separate user delegation from machine authority Do not let a single agent freely mix OAuth delegation and service-account authority. Use distinct identities, record which context initiated the action, and preserve an audit trail that links the user request to the machine execution path.
• Log runtime decisions, not just successful actions Capture the tool chosen, the identity used, the policy evaluated, and the data source touched for each step in the agent chain. That gives investigators enough context to reconstruct why an agent took a path, not only what it changed.
• Apply rotation and review to agent credentials on the same cadence as NHI secrets Treat agent credentials as high-risk NHI secrets and rotate them regularly, especially when they are reused across tools. Align access reviews with the NHI lifecycle so abandoned automations do not keep privileged paths alive.

Key takeaways

• Self-assembling AI agents create runtime access paths that static IAM assumptions cannot reliably govern.
• Blended identity and hidden credential reuse increase audit complexity, privilege creep, and blast radius.
• The practical response is task-scoped, ephemeral access with stronger logging, rotation, and separation of authority.

Key terms

• Self-Assembling AI: A self-assembling AI system is one that builds its own integration path at runtime instead of following a fixed, developer-defined workflow. The model chooses tools, credentials, and sequencing dynamically, which makes identity and access control harder to predict, approve, and audit.
• 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.
• Ephemeral Credential: An ephemeral credential is a short-lived secret or token issued for a specific task and then retired. In NHI governance, ephemeral credentials reduce persistence, limit blast radius, and make it easier to tie access to a narrow context, but only if rotation and logging are enforced.
• Runtime Authorization: Runtime authorization is the act of evaluating access at the moment a system is about to perform an action, rather than relying only on preapproved static permissions. For agentic AI, it is the control point that decides whether the next tool call, data access, or write operation should be allowed.

Deepen your knowledge

Self-assembling AI agents, runtime credential scoping, and delegated authority are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic workflows, the course is a useful next step.

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