They should govern them as part of access management, not only as endpoint software. That means approving sources, limiting permissions, blocking risky install behaviour, and revoking access when the tool, extension, or token is no longer required. If the tool can act on data or credentials, it belongs in the identity control model.
Why This Matters for Security Teams
Developer tools that install packages or invoke AI agents can create a hidden control plane inside the build and delivery path. They are not just productivity utilities. They can read source code, reach package registries, create or use tokens, and trigger downstream actions. That makes them relevant to access governance, software supply chain risk, and identity security at the same time.
Current guidance suggests treating these tools as trusted execution surfaces only after explicit approval, scope limits, and revocation paths are in place. The same logic applies when an agent can call tools on behalf of a developer: the tool’s permissions matter as much as the human account’s permissions. That is why frameworks such as the NIST AI Risk Management Framework and OWASP Agentic AI Top 10 are useful starting points, even for teams that do not think of themselves as “AI security” teams.
In practice, many security teams encounter this only after a package install, plugin, or agent has already been granted broad access to code, secrets, or cloud resources.
How It Works in Practice
Governance works best when these tools are managed through a combination of software approval, identity controls, and runtime restriction. Security teams should start by defining which package managers, extensions, model endpoints, and agent frameworks are allowed, then tie those approvals to business owners and expiry dates. If the tool can install code, call APIs, or access repositories, it should be treated as a privileged integration, not a generic desktop app.
At implementation time, the key question is not only whether the tool is installed, but what it can reach. That includes registry access, filesystem reach, shell execution, local credential stores, and any delegated tokens. A practical model is to use least privilege, just-in-time elevation where necessary, and separate identities for human users, build systems, and agents. The NIST Cybersecurity Framework 2.0 is helpful here because it pushes teams to connect governance, access control, monitoring, and recovery rather than treating them as separate tasks.
A workable operating model usually includes:
- Approved sources for packages, extensions, and agent toolchains.
- Blocking of unsigned, untrusted, or policy-violating installs.
- Token scoping that prevents broad repo, cloud, or secret access.
- Logging for install actions, permission grants, and agent tool calls.
- Rapid revocation when a tool, extension, or service account is no longer required.
Security teams should also align detection logic with attack patterns seen in malicious package installation, credential harvesting, and agent misuse. The MITRE ATLAS adversarial AI threat matrix and Anthropic report on AI-orchestrated cyber espionage both reinforce that AI-enabled workflows can be abused to accelerate reconnaissance, social engineering, and unauthorized execution. These controls tend to break down in developer environments that allow unmanaged local admin rights and direct internet access to registries because the tool can install, update, and execute faster than policy enforcement can intervene.
Common Variations and Edge Cases
Tighter control of developer tools often increases friction for engineering teams, so organisations have to balance delivery speed against the risk of uncontrolled execution. That tradeoff becomes sharper when the tool is genuinely useful but also capable of changing code, fetching dependencies, or operating through an AI agent.
There is no universal standard for this yet, but current guidance suggests a few practical exceptions. Short-lived sandbox environments may tolerate broader permissions if they are isolated and fully disposable. Open-source development teams may need broader package access, but that should still be paired with source allowlisting and continuous monitoring. AI coding assistants present a special case: if they can recommend code but cannot act without human approval, their risk profile is different from an agent that can run commands or open pull requests autonomously.
Another edge case is delegated identity. If the tool uses a service account or API token rather than a human login, that credential becomes the real control point. In those cases, access review must cover the token lifecycle, not just the installed software. Organisations should also distinguish between offline developer tools and network-connected agents that can exfiltrate data, because the latter deserve stronger identity binding and audit coverage. Where AI or package tools reach sensitive systems, governance should follow the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework so that ownership, tool trust, and failure handling are explicit.
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 MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Tool access must be approved, limited, and revocable across identities and tokens. |
| NIST AI RMF | Agentic tools need governance, mapping, measurement, and management of AI risk. | |
| OWASP Agentic AI Top 10 | Autonomous tool use creates prompt, tool, and execution abuse paths. | |
| MITRE ATLAS | Adversarial AI tactics help model misuse of agent tools and package workflows. | |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is central when tools can install code or use credentials. |
Inventory tool access, restrict privileges, and revoke exposure when the tool is no longer needed.
Related resources from NHI Mgmt Group
- How can organisations govern AI agents that use service accounts and tokens?
- How should security teams reduce risk from AI agents and developer tools that use secrets locally?
- How should security teams govern AI agents that use service accounts and MCP tools?
- How should organisations govern AI usage when employees use unapproved tools?
