They increase risk because developer machines often already hold browser sessions, tokens, SSH keys, and cloud access. A malicious skill does not need to defeat the whole identity stack if it can harvest what is already present on the endpoint. That is why agent governance and secret hygiene now have to be managed together.
Why This Matters for Security Teams
Agent-installed skills matter because they turn a developer laptop into a mixed-trust execution zone. A skill may not need to break authentication if the endpoint already contains browser sessions, cloud tokens, SSH keys, package registry access, and cached secrets. That shifts the risk from perimeter defence to local trust composition, where one compromised extension, plugin, or helper can become a bridge into development and production systems.
This is why NHIMG treats endpoint-held identity material as a first-class NHI exposure. The Ultimate Guide to NHIs notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which makes developer machines especially attractive to agent-installed tooling. That finding aligns with the broader concern raised in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, both of which emphasise contextual controls rather than blind trust in installed software.
Security teams often underestimate how much authority a “helpful” skill inherits from the developer environment rather than from any explicit grant. In practice, many teams encounter credential theft only after an agent-enabled workflow has already accessed repos, tickets, and cloud consoles, rather than through intentional review of the skill’s trust boundary.
How It Works in Practice
The identity risk comes from the way agent-installed skills operate inside the same session and filesystem context as the developer. They can read environment variables, inspect local config files, query browser-stored sessions, invoke CLIs, and chain that access into downstream tools. In agentic environments, static role-based access control is not enough, because the skill’s behaviour is task-driven and can change based on prompt, data, and tool output.
Best practice is evolving toward workload identity, intent-based authorisation, and just-in-time credentials. Instead of letting a skill inherit broad ambient authority, organisations should issue short-lived, task-scoped credentials, bind them to workload identity, and revoke them automatically after completion. SPIFFE-style workload identity and OIDC-backed tokens help prove what the agent is, while policy engines such as OPA or Cedar can evaluate what the agent is trying to do at request time. The OWASP NHI Top 10 and CSA MAESTRO agentic AI threat modeling framework both reinforce this shift from static trust to runtime control.
- Separate human developer sessions from agent execution contexts.
- Block ambient access to long-lived secrets on endpoints wherever possible.
- Use JIT secret issuance with short TTLs and automatic revocation.
- Require per-action policy evaluation for tool use, file access, and network reach.
- Log skill actions with enough context to detect secret discovery, not just secret use.
NHIMG research shows why this matters: the State of Secrets in AppSec reports that the average time to remediate a leaked secret is 27 days, which leaves a long exposure window if an installed skill exfiltrates credentials. These controls tend to break down on unmanaged developer laptops with persistent browser sessions and local admin rights because the endpoint itself becomes the trust anchor.
Common Variations and Edge Cases
Tighter endpoint control often increases developer friction, requiring organisations to balance security against usability and velocity. That tradeoff is real, especially where teams rely on local builds, offline work, or rapid plugin experimentation. Current guidance suggests allowing agent skills only inside constrained profiles, but there is no universal standard for this yet.
Edge cases matter. A skill that never handles secrets directly can still become dangerous if it can read browser state, trigger clipboard access, or call other tooling that already has authority. Likewise, sandboxing helps, but it does not eliminate risk if the sandbox can reach developer tokens mounted from the host. The practical lesson is to treat every installed skill as a potential identity broker, not just a code assistant. NHIMG’s 52 NHI Breaches Analysis shows how often compromise starts with weak identity boundaries, and the same pattern now appears on endpoints through agent tooling.
Where environments use shared workstations, privileged debugging, or long-lived cloud logins, this guidance breaks down because the skill can inherit too much ambient privilege before any policy engine has a chance to intervene.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A07 | Addresses agent tool abuse and unintended actions on developer endpoints. |
| CSA MAESTRO | T1 | Focuses on threat modeling autonomous agent execution and identity sprawl. |
| NIST AI RMF | GOVERN | Supports accountability for AI-driven identity misuse and endpoint risk. |
Constrain agent tools, require task-scoped approval, and monitor for unsafe autonomous actions.
