Local AI agents are creating a new NHI risk surface

At a glance

What this is: The article argues that autonomous local agents in developer workflows should be treated as NHIs because they inherit privileges, execute commands locally, and expand supply-chain risk.

Why it matters: IAM, PAM, and IGA teams need to govern these agents as first-class identities because their access paths can bypass review, evade logging, and touch production-connected resources.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Noma Security's analysis of local AI agent risks in developer environments

Context

Local AI agents are software systems that can read files, run commands, and act inside a developer’s environment with the permissions already present on that endpoint. The governance problem is that these tools do not sit outside identity control, they inherit identity control, which means existing IAM and PAM assumptions can fail inside a normal engineering workflow.

In Git repositories and adjacent build environments, that creates an identity layer that is easy to miss and hard to observe. The article’s central point is that organisations are moving from browser-based AI interaction to endpoint-resident agent execution faster than their access review, logging, and containment models are adapting.

That shift is not typical experimentation. It is a structural change in how non-human identities are entering the software development lifecycle, and it compresses the time between access grant, execution, and possible data exposure.

Key questions

Q: How should security teams govern local AI agents that run on developer endpoints?

A: Treat them as NHIs with identity, access, and lifecycle ownership. Inventory each agent, define which user context it inherits, limit its reachable systems, and require approval for commands that modify code, secrets, or network state. If the agent can execute in the same context as the developer, it needs the same level of governance as other privileged machine identities.

Q: Why do local AI agents create more risk than browser-based AI tools?

A: Local agents can inherit endpoint permissions, active sessions, and filesystem access, which means they can execute actions directly in the development environment. Browser-based tools usually sit farther from the code and credentials. The local model collapses that separation, so one compromised or misused agent can touch source, secrets, and connected infrastructure at once.

Q: What do teams get wrong about auto-approval for AI agents?

A: They treat auto-approval as a productivity setting rather than a standing authority grant. Once enabled, the agent can keep issuing commands without fresh human judgment, which makes accidental data exposure and unauthorized system changes more likely. The right lens is privileged execution, not convenience, because the risk persists for as long as the agent is running.

Q: What should teams do when an AI agent can access repositories and secrets?

A: Restrict the agent to a scoped runtime, separate it from the host, and review whether its access is still justified after the task ends. If the agent can read files outside the repository or reach external systems, it should be treated as a high-risk NHI subject to tighter containment and review.

Technical breakdown

Privilege inheritance in local agent workflows

Local agent systems inherit the shell context of the user running them. If that user already has active sessions, tokens, or file permissions, the agent can invoke AWS, Kubernetes, databases, or local files without a new authentication step. That is why local agent risk is not just about model output. It is about delegated execution under an already trusted identity. Once the agent can call tools in the same context as the developer, it becomes part of the enterprise identity plane whether or not it was designed that way.

Practical implication: treat any agent running with developer credentials as an NHI that must be inventoried, scoped, and reviewed.

Auto-approval collapses human approval gates

Auto-approval settings remove the human checkpoint between the agent’s decision and the command it executes. In practice, this turns a conversational interface into unattended command execution, where bash operations, file edits, and outbound requests can happen without review. The security issue is not only speed. It is that the trust boundary moves from explicit user consent to a persistent configuration choice, which is far easier to forget and much harder to audit consistently across teams and endpoints.

Practical implication: disable unattended execution for any agent that can modify files, reach networks, or touch shared repositories.

Why local autonomy changes supply chain exposure

Community forks and model-agnostic wrappers can broaden developer flexibility, but they also move security responsibility away from a vendor-controlled channel and into an ad hoc ecosystem. When the agent can browse the web and execute commands in one session, indirect prompt injection becomes a practical control problem, because poisoned content can trigger local actions. Scoping failures make this worse when the agent is not jailed to a project folder, because sensitive files outside the repository become reachable inputs and exfiltration targets.

Practical implication: isolate agent execution, constrain egress, and assume repository-adjacent content can become a control input.

Threat narrative

Attacker objective: The attacker’s objective is to turn trusted developer autonomy into code execution, secret access, and supply-chain compromise through the agent’s inherited permissions.

1. Entry occurs when a developer installs a local agent or community fork inside an endpoint that already holds active credentials and filesystem access.
2. Escalation happens when the agent inherits those permissions, accepts auto-approval, and begins issuing commands or reading files beyond the intended repository scope.
3. Impact follows when the agent exfiltrates secrets, modifies code, or touches connected systems in ways that bypass normal review and leave limited audit evidence.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

Privilege inheritance is the named control gap here: it was designed for a human operator whose permissions remain visible and reviewable over time. That assumption fails when a local agent executes inside the same shell context and can act immediately on active tokens, file permissions, and network reach. The implication is not simply that access needs tightening, but that identity ownership has shifted into execution time, where traditional review cycles see too little and too late.

Auto-approval creates a standing privilege problem inside the developer workflow: the article shows that unattended agent execution turns a convenience setting into persistent authority. Access is no longer granted only at login or deploy time, it is continuously available whenever the agent is running. Practitioners should read this as a PAM and IGA boundary issue, because the agent can keep acting after the human has mentally stopped supervising it.

Local agents are becoming shadow NHIs in software delivery: they are installed, active, and privileged, but often not represented in identity inventories or entitlement reviews. That matters because repository automation is now making code changes, dependency choices, and pull requests under machine-held permissions. The governance problem is not limited to AI content moderation. It is lifecycle control for a non-human actor that can change the software supply chain.

Identity blast radius: the article illustrates how a single developer context can expose source code, credentials, and downstream systems at once. Once an agent shares the same context as the operator, the blast radius of one compromised session is no longer limited to one user action. Practitioners need to treat endpoint-resident agents as connected identity surfaces, not isolated productivity tools.

Governed autonomy will separate acceptable AI use from unmanaged AI use: enterprises will not stop local agent adoption, but they will have to decide which executions are allowed to inherit production-relevant trust. That decision is becoming a security architecture choice, not a tooling preference. The teams that win this control point will be the ones that classify local agents, scope them, and measure them like identities.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Our research also found that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader view of non-human identity control failures, see The 52 NHI breaches Report, which shows how unmanaged machine identities create persistent exposure patterns across environments.

What this signals

Privilege inheritance is now an endpoint governance issue, not just an AI policy issue: if an agent inherits the developer’s shell, the identity programme has to understand endpoint context, token persistence, and command authority together. That is why agent controls need to sit alongside PAM, EDR, and lifecycle governance rather than in a separate AI-only policy stack.

With 98% of organisations planning to deploy even more AI agents within the next 12 months, according to AI Agents: The New Attack Surface report, the operational question is no longer whether adoption will spread. The question is whether identity teams can classify and contain these agents before they become normalised shadow NHIs in engineering workflows.

Shadow agent detection: unmanaged local agents will increasingly appear as normal developer activity unless identity and endpoint teams agree on ownership signals. Security programmes should expect the logging problem to persist until inventory, runtime isolation, and egress controls are tied to the same control plane.

For practitioners

• Inventory every local agent as an identity Create a register of all agent installs, forks, and wrappers running on developer endpoints, including which user context they inherit and which systems they can reach.
• Remove unattended execution by default Disable auto-approval for commands that can modify files, access secrets, or reach external networks, then require explicit review for privileged actions.
• Isolate agent runtime from the host Run agents in isolated containers or sandboxed environments so they cannot access host SSH keys, local databases, or broader corporate network paths.
• Constrain agent egress to approved destinations Allow only approved documentation sites, package registries, and internal services, and block unrestricted outbound web requests that could carry exfiltrated data.
• Review repository automation for shadow NHI behaviour Map where agents open pull requests, refactor code, or manage dependencies without human review, then assign ownership for those workflows in IGA and PAM.

Key takeaways

• Local AI agents behave like NHIs when they inherit endpoint privileges, which makes them an identity governance problem as much as an AI productivity feature.
• The central risk is not model output, but the combination of auto-approval, inherited tokens, and weak auditability across developer workstations.
• Enterprises need inventory, containment, and egress restrictions for agents now, before shadow agent adoption becomes the default operating model.

Key terms

• Privilege Inheritance: Privilege inheritance occurs when a system uses the permissions of the human or service identity that launched it. For agents, this means the workload can access anything the parent role can access, which makes entitlement design more important than the model’s natural-language capabilities.
• Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight — the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
• Auto-Approval: Auto-approval is a configuration that allows an agent to execute actions without a human confirming each step. It removes the review gate between decision and command, which can turn convenience into persistent privileged execution when the agent can modify code, access secrets, or reach external systems.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Noma Security's full post covers the operational detail this analysis intentionally leaves for the source:

• A closer look at Claw, OpenClaw, and related agent workflows that shape the risk model.
• Specific examples of shell inheritance, directory scoping gaps, and auto-approval behaviour in local agents.
• The vendor's field observations on repository maintenance, visibility gaps, and unofficial supply-chain exposure.
• Practical recommendations for deploying isolated containers and egress allowlists in agent workflows.

👉 The full Noma Security post covers endpoint visibility gaps, privilege inheritance, and agent containment details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.