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.
Why This Matters for Security Teams
Local AI agents on developer endpoints are not just productivity tools. They are executable, tool-using workloads that can read source code, call APIs, reach repositories, and act on behalf of a user. That makes them non-human identities with real blast radius, especially when they inherit the developer session, browser state, and filesystem access. Current guidance suggests treating them as privileged machine identities rather than convenience software.
The operational risk is already visible. In AI Agents: The New Attack Surface report, SailPoint found that 80% of organisations said their AI agents had already acted beyond intended scope, while 52% could not fully track and audit the data those agents accessed. That is a governance problem, not a tuning problem. The right baseline is reinforced by the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10, both of which emphasise context, accountability, and runtime risk controls.
Security teams often miss that an endpoint agent can become a lateral-movement path, a secret exfiltration path, or a code execution proxy in minutes. In practice, many security teams encounter agent misuse only after a repository, token, or deployment target has already been touched, rather than through intentional policy design.
How It Works in Practice
Governance starts by defining the agent’s identity boundary. If the agent runs locally, it should still have a distinct workload identity, separate from the developer’s own account, so access decisions can be attributed to the agent’s actions rather than bundled into a human session. Where possible, teams should pair that identity with short-lived credentials, scoped tokens, and explicit task boundaries. This is where just-in-time provisioning matters: the agent receives only the access needed for the current job, then loses it automatically.
That model works best when authorisation is evaluated at request time. Static RBAC is too blunt for autonomous tooling because the agent’s behaviour is dynamic. Instead, use policy-as-code and context-aware approval gates for sensitive operations such as pushing code, changing network rules, reading production secrets, or invoking CI/CD actions. CSA MAESTRO agentic AI threat modeling framework is useful here because it frames agent behaviour around tool use, trust boundaries, and escalation paths.
- Inventory every local agent, its owner, and its allowed tools.
- Bind the agent to a workload identity and a named user context.
- Restrict filesystem, browser, repo, and network reach by default.
- Require step-up approval for code, secrets, and environment changes.
- Log prompts, tool calls, policy decisions, and resulting actions for audit.
NHI controls are especially important when developers can install agents ad hoc or connect them to personal tokens. The attack patterns described in the Analysis of Claude Code Security show why local code assistants need the same governance discipline as other privileged endpoints. These controls tend to break down in highly trusted developer workstations because broad local admin rights and unmanaged browser sessions erase the separation between user intent and agent action.
Common Variations and Edge Cases
Tighter agent controls often increase friction for developers, requiring organisations to balance speed against containment. That tradeoff is real, especially when teams rely on fast iteration, offline work, or custom plugins. Best practice is evolving, and there is no universal standard for this yet, but current guidance consistently favours minimising standing access and making sensitive actions explicit.
Some environments need extra nuance. For example, agents used only for local refactoring can be granted narrower scope than agents that can open pull requests or deploy test infrastructure. Agents that can access browser sessions or cloud consoles deserve stronger controls because they can chain tools in ways humans do not anticipate. The same is true for secret-heavy workflows: the State of Secrets in AppSec highlights how fragmented secrets management and weak developer practices make token leakage and reuse more likely.
In edge cases, the right answer is to prohibit local execution entirely and move the agent into a managed workspace or hardened remote environment. That is often the safer choice when the agent can reach production data, regulated systems, or high-value credentials. The NIST Cybersecurity Framework 2.0 and OWASP guidance both support reducing trust assumptions around endpoints. For autonomous agents, the main question is not whether they are helpful, but whether the endpoint can tolerate the privilege they inherit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Local agents can abuse tools and prompts to exceed intended actions. |
| CSA MAESTRO | TRUST | MAESTRO maps agent trust boundaries and escalation paths on endpoints. |
| NIST AI RMF | GOVERN | AI RMF governs ownership, accountability, and oversight for agentic systems. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Endpoint agents are machine identities that need inventory and access control. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and permission management fit developer agent controls. |
Assign named ownership, logging, and review processes for every endpoint agent.
