Accountability sits with the teams that own endpoint security, developer platform governance, and identity-aware access controls. They must ensure approved tools, packages, and agent integrations are inventoried, monitored, and enforced consistently across the fleet. In practice, this means treating developer machines as managed security assets, not just personal workstations.
Why Accountability Splits Across Developer Platforms, Endpoint Security, and Identity Controls
Unapproved mcp server and compromised developer dependencies create the same governance problem from two directions: one introduces unvetted execution paths, the other turns trusted software supply into a delivery channel for malicious code. That means accountability cannot sit with a single function. Endpoint security owns device trust and local execution exposure, developer platform governance owns what tools and packages are allowed into the build and agent workflow, and identity-aware access controls own who or what can use those paths. The relevant discipline is less about naming the tool class and more about enforcing provenance, approval, and revocation across the full developer environment.
For agentic and software-supply-chain questions, the most useful external authority is the OWASP Top 10 for Agentic Applications 2026, because it frames agent tool access, trust boundaries, and untrusted extensions as design and governance problems rather than isolated hygiene tasks. In practice, many teams discover the accountability gap only after an unapproved integration or dependency has already been promoted into a developer workflow.
How Control Actually Works Across the Developer Estate
Controlling unapproved MCP servers is not the same as blocking a random application. MCP servers sit in the path between an AI-enabled client, its tools, and the data or actions those tools can reach. If the server is not approved, the organisation may still be allowing a new trust boundary to form outside review, logging, and access policy. That is why ownership must include the team that can govern local endpoints, the team that can define which developer tools may connect, and the team that can bind those connections to identity and entitlement rules.
Compromised developer dependencies follow a similar pattern, but the control point is earlier in the lifecycle. Package registries, lockfiles, build pipelines, and developer workstations all become part of the security boundary. The accountable teams need to know which dependencies are in use, which are pinned, which are updated automatically, and which can execute code during install or build. If those dependencies are allowed to run with broad access to secrets, tokens, or internal services, a dependency compromise can become an internal foothold rather than a simple software defect.
Operationally, the control model usually needs three layers:
- endpoint enforcement to prevent unsanctioned local servers or tools from running unchecked
- developer platform governance to approve packages, plugins, and agent integrations before use
- identity-aware access controls to constrain which accounts, tokens, and service permissions those tools can exercise
The practical question is not whether a tool is useful, but whether the organisation can prove who approved it, where it runs, what it can reach, and how it is revoked. That proof matters because a developer environment often blends personal productivity, privileged source access, and automated tool execution in the same session. The guidance from OWASP is especially useful here because it treats untrusted tool invocation and dependency trust as a single risk surface, which is closer to how these incidents actually unfold.
Where this guidance breaks down is in highly decentralised engineering environments that lack a single inventory of sanctioned tools, dependency sources, or device posture. In those cases, accountability exists on paper but cannot yet be enforced consistently.
Where the Standard Answer Breaks Down in Real Programmes
Tighter control over developer tools and dependencies often increases friction, so organisations have to balance release speed against the need to keep unvetted code paths out of privileged workflows. That tradeoff becomes sharper when teams rely on fast-moving build ecosystems, internal mirrors, or autonomous agents that can install or call tools dynamically.
One edge case is shared responsibility between central security and product engineering. Security can define the policy, but engineering platform teams usually need to implement the approval gates, package allowlists, and telemetry. Another edge case is bring-your-own-device development, where endpoint ownership may be unclear and device trust is harder to enforce. A third is experimental agent usage, where teams may argue that a tool is only a prototype and therefore outside normal governance. That is a governance gap, not an exception.
There is also a difference between approving a dependency and trusting everything that dependency can pull in transitively. A package may be named in inventory, yet its nested dependencies may still be unmanaged. The same issue appears with MCP servers that proxy to other tools or APIs: the visible server may be approved while the effective attack surface is much larger. The accountable team therefore has to verify both the direct object and the downstream trust chain before treating the control as effective.
Anthropic report on AI-orchestrated cyber espionage is relevant here because it illustrates why tool-use governance and identity-bound permissions cannot be treated as optional once agents can act on behalf of users. The control boundary weakens fastest when organisations assume that a developer tool remains harmless simply because it started as a convenience feature.
Risk and Threat Considerations
Unapproved MCP servers and compromised developer dependencies create a material trust and supply-chain exposure. The risk is not only malware execution, but also the quiet expansion of what a developer workstation, build process, or agent can access under legitimate credentials.
Failure mechanism: An attacker or malicious package can exploit trusted installation paths, dependency resolution, or tool registration to introduce code that executes with developer permissions, reaches secrets, or redirects agent actions through an unapproved server.
Impact: The result can be credential theft, source-code exposure, poisoned builds, lateral movement through developer systems, or persistence inside an environment that appears compliant at the user interface level.
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 ATT&CK address the attack and risk surface, while CIS Controls v8 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 — Untrusted Tool Invocation | Directly addresses agent tool trust and approval boundaries. |
| A5 — Supply Chain and Dependency Risks | Covers compromised dependencies and untrusted package inputs. | |
| Recommendation — Restrict agent tool access to approved servers and verify every invoked capability. Pin, vet, and monitor dependencies before they can execute in developer workflows. | ||
| CIS Controls v8 | 02 — Software Inventory | Requires visibility into approved software and components across managed assets. |
| 06 — Access Control Management | Applies to limiting who can use sensitive developer and agent pathways. | |
| Recommendation — Maintain an accurate inventory of sanctioned tools, packages, and integrations. Remove unnecessary access to developer tooling and privileged integration paths. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Models attacker abuse of trusted software and dependency channels. |
| Recommendation — Hunt for compromised dependencies and validate build inputs against trusted sources. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Applies to identity-aware restriction of tool and dependency use. |
| ID.AM-1 — Physical Devices and Systems Inventory | Supports inventory of endpoints and sanctioned execution surfaces. | |
| PR.DS-6 — Integrity Verification | Addresses checking software and dependency integrity before execution. | |
| Recommendation — Enforce least-privilege permissions for developer tools and agent credentials. Inventory developer endpoints and approved runtime surfaces before allowing tool use. Verify package and tool integrity before they are allowed into build or agent flows. | ||
Practitioner Guidance
What to prioritise: Treat the developer workstation, package source, and agent toolchain as one governed system. If those three layers are owned by different teams, define a single escalation path for unapproved servers, dependency anomalies, and revoked tool access.
What to verify: Confirm that every approved MCP server, package source, and agent integration has an explicit owner, an inventory record, and a revocation path. If any of those are missing, the control is advisory rather than enforceable.
Common mistake: Teams often focus on package approval while leaving local execution and identity permissions unchanged. That leaves a route for trusted code to arrive through one channel and act through another.
Practitioner takeaway: Accountability is strongest when the same governance model covers approval, execution, and revocation; if those are split, unapproved tools and compromised dependencies will find the seam.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
