Local AI agents are creating a new NHI risk surface

At a glance

What this is: Noma Security argues that local AI agents in developer environments should be treated as NHIs because they execute with inherited credentials, local file access and limited visibility.

Why it matters: This matters because IAM and NHI programmes must govern what these agents can touch, how they are isolated, and how their activity is audited before they become an unmanaged execution layer.

Context

Local AI agents change the identity problem because they do not just generate content, they execute actions on a developer endpoint using the user’s existing privileges. In practice, that turns a repository workflow into an access problem, not only a code-assistance problem.

Noma Security’s analysis frames these agents as non-human identities with direct execution authority, which means their permissions, network reach, and visibility need to be governed like any other machine identity. The issue is amplified when teams adopt community forks and auto-approval settings faster than security controls can adapt.

Key questions

Q: What breaks when local AI agents inherit a developer’s shell context?

A: They stop behaving like advisory tools and become active non-human identities with the same tokens, filesystem access, and downstream reach as the logged-in user. That means a repository workflow can silently become a credentialed execution path. The governance failure is assuming the developer’s trust boundary still holds once an agent can act inside it.

Q: Why do local AI agents increase supply chain risk in git repositories?

A: Because they can modify code, dependencies, and pull requests from inside the development workstation, often with fewer human checkpoints than standard engineering workflows require. If the agent is also allowed to browse, ingest untrusted content, or use community forked software, the repo becomes a delivery point for unreviewed machine-authored change.

Q: How can security teams tell whether agent access is actually under control?

A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.

Q: What should teams do when auto-approval is enabled for local AI agents?

A: Treat auto-approval as a privileged operating mode and restrict it to tightly scoped projects, not general developer workstations. The key question is whether the agent can execute commands, read files, and reach external resources without a human checkpoint. If yes, the control boundary has shifted from review to runtime containment.

Technical breakdown

Why privilege inheritance turns local agents into an identity problem

Local agents inherit the shell context of the signed-in developer, which means they inherit whatever tokens, filesystem access, and internal reach that session already has. If the developer is authenticated to cloud consoles, package registries, or internal databases, the agent can act through those credentials without a new auth event. That is why the control issue is identity scope, not model capability. The risk is not hypothetical autonomy; it is delegated execution under already-trusted human context.

Practical implication: inventory local agents as NHI instances and explicitly define the resources each one may reach.

Why auto-approval and shared sessions break review boundaries

Auto-approve settings collapse the human checkpoint that normally separates suggestion from execution. Once the agent can run Bash commands and modify files unattended, it can change code, dependencies, and system state faster than a reviewer can intervene. The same problem appears when web browsing and terminal execution share one session, because prompt-injected instructions can be converted directly into local commands. The security boundary is therefore session control, not content moderation.

Practical implication: separate browsing, execution, and approval paths so a poisoned instruction cannot become a terminal action.

How endpoint visibility gaps create shadow agents

Local execution makes these agents harder to distinguish from the user’s own activity, even when endpoint tooling captures the process. That creates an audit problem because the organisation may know a command ran, but not whether a human or an agent initiated it, nor what external content shaped the action. Community forks deepen the issue by introducing software without the governance posture of an approved enterprise toolchain. The result is a shadow identity layer inside development workflows.

Practical implication: require provenance, inventory, and audit trails for every agent installation before it is allowed onto a developer endpoint.

Threat narrative

Attacker objective: The attacker wants to use the trusted local agent path to reach developer credentials, manipulate code, and exfiltrate data or secrets without triggering normal review controls.

1. Entry occurs when a developer installs a local AI agent or community fork into a trusted workstation and grants it access to the active shell session.
2. Credential access follows because the agent inherits the user’s permissions, tokens, and local files, including cloud and source control access.
3. Escalation happens when auto-approval or shared web-and-shell sessions let the agent execute commands, modify files, or follow injected instructions without human review.
4. Impact is silent code tampering, credential exposure, and downstream supply-chain risk across repositories and connected internal systems.

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.
• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Local AI agents are now an NHI governance problem, not a software convenience problem. Once an agent executes with the developer’s own shell context, it becomes part of the identity estate and must be managed accordingly. The meaningful control question is not whether the model is approved, but whether the executing identity is inventoried, scoped, and observable. Practitioners should treat every endpoint agent as a governed non-human identity.

Privilege inheritance is the core assumption collapse in local agent deployment. The assumption that access is stable, human-paced, and easy to review was designed for a user sitting at a keyboard, not for an agent that can consume context and act immediately through inherited permissions. That assumption fails when the actor can browse, read files, and execute commands inside one session. The implication is that access governance has to move from review-time thinking to issuance-time control.

Shadow agents create a new form of unreviewed supply-chain exposure inside the developer workstation. Community forks and auto-approved local workflows bypass the operational discipline organisations usually expect from sanctioned development tooling. This is not only a tooling choice, it is an identity propagation choice because the agent brings execution authority into the repo environment. Practitioners should recognise this as unmanaged identity sprawl inside the software supply chain.

Endpoint visibility is no longer enough if the organisation cannot separate human intent from agent action. Logging that only shows a command on the endpoint does not tell you whether the user typed it or the agent derived it from a prompt or website. That weakens incident review, change attribution, and accountability across both IAM and engineering operations. The practical conclusion is that attribution, not just detection, is now part of NHI governance for local agents.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Privilege inheritance is the decisive design flaw: if a local agent inherits the same shell, tokens, and file access as the developer, existing IAM controls cannot tell suggestion from execution. That pushes governance toward runtime containment, not post hoc review.

Shadow AI in repositories should be treated as shadow identity exposure: the programme risk is not only unapproved tooling, but untracked execution authority inside the software delivery path. The practical response is to govern agent installation, scope, and auditability as part of the identity lifecycle.

If the organisation cannot separate human intent from agent action on the endpoint, it will struggle to attribute change, investigate incidents, or prove control ownership across the development estate.

For practitioners

• Inventory local agents as NHIs Record every approved and unapproved agent installation, including model source, execution scope, and the developer account it inherits from.
• Separate browsing from execution Prevent a single session from both consuming external content and running shell commands, so injected instructions cannot become local actions.
• Restrict inherited permissions Limit each agent to a project folder, a minimal set of commands, and a narrowly defined network allowlist for registries and documentation sites.
• Run agents in isolated containers Use container boundaries to block access to host SSH keys, local secrets, and broader corporate network paths on the developer endpoint.
• Require auditability for every agent Maintain logs that tie agent actions to a specific installation, session, and identity so review teams can distinguish human work from machine execution.

Key takeaways

• Local AI agents create identity risk because they execute with inherited developer privileges, not because they merely produce code suggestions.
• The highest exposure comes from unattended execution, shared browsing-and-shell sessions, and community forks that bypass formal security governance.
• Teams need inventory, isolation, and attribution controls before local agents can be allowed to touch repositories, secrets, or internal services.

Key terms

• Local AI Agent: A local AI agent is software that runs on a personal device or server and can interact with files, applications, and system tools directly. Unlike a browser-based assistant, it may hold local memory, use messaging channels, and execute commands, which makes operating system security and access control part of its threat model.
• 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.
• Workflow Execution Boundary: The workflow execution boundary is the point where user-authored logic stops being data transformation and starts becoming privileged runtime activity. In secure designs, that boundary prevents untrusted workflow content from reaching process memory, system calls, or secret stores without strict containment.

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 IAM programme, it is worth exploring.