Topic starter
24/07/2026 4:09 pm
TL;DR: Local AI agents running in developer endpoints are being adopted rapidly, but their inherited shell context, auto-approval settings, and weak visibility create a new NHI risk surface for repositories and downstream systems, according to Noma Security. The governance gap is no longer about what the model says, but what the agent can execute with existing credentials and local privileges.
Editorial analysis by NHI Mgmt Group, based on content published by Noma Security: “Pandora’s Claw: From Internal Leak to Industry Standard”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Local AI agents create identity risk because they execute with inherited developer privileges, not because they merely produce code suggestions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
24/07/2026 4:15 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Local AI agents are creating a new NHI risk surface