TL;DR: Koi’s acquisition by Palo Alto Networks changes how practitioners should evaluate developer endpoint supply chain controls, because roadmap control, pricing, and integration complexity now sit inside a larger platform model, according to Aikido. The practical question is no longer whether install-time governance matters, but whether it can still be operated with enough speed, transparency, and scope to match modern developer attack surfaces.
At a glance
What this is: Aikido argues that Koi alternatives now need to be judged on install governance trade-offs, because Koi’s acquisition shifts it from an independent tool into a larger platform roadmap.
Why it matters: This matters because security teams evaluating developer device supply chain controls must now weigh speed, breadth, pricing transparency, and platform complexity at the same time.
By the numbers:
- Koi was acquired by Palo Alto Networks in April 2026, with the deal estimated at around $400 million.
Context
Developer device supply chain governance sits between endpoint control and software supply chain security. It focuses on what software can be installed, what sources it can come from, and how quickly risky changes can be stopped before they reach a developer machine. In this article, the primary issue is not whether install governance matters, but how much operational complexity teams are willing to accept to get it.
The identity angle is indirect but real. Packages, browser extensions, IDE plugins, MCP servers, and AI tools all enter through governed software channels, so the control problem overlaps with machine trust, software provenance, and the lifecycle of non-human access paths. Once that control is folded into a larger security suite, practitioners have to decide whether governance remains precise enough for developer workflows.
Key questions
Q: What happens when install governance is folded into a larger security platform?
A: Teams usually gain broader platform integration but lose some combination of operational speed, pricing transparency, and roadmap independence. That matters most when the control has to act at install time, because any extra sales cycle, policy dependency, or interface complexity can reduce how quickly developers can be protected.
Q: Why do malicious packages and extensions still bypass conventional endpoint tools?
A: Traditional EDR and SCA tools are not designed to govern the moment software is installed from marketplaces or registries. They either detect behaviour after execution starts or scan known dependencies after they are already present, which leaves a gap for fast-moving supply chain attacks that arrive as apparently legitimate software.
Q: How should teams evaluate install-time protection against repository scanning?
A: They should treat them as complementary controls. Install-time protection blocks risky software before it reaches the device, while repository scanning finds vulnerabilities, secrets, and misconfigurations already present in code or dependencies. One does not replace the other, and most mature programmes need both.
Q: When does developer supply chain governance need a device-level control?
A: It becomes necessary when software can arrive from multiple channels, including downloads, private registries, browser stores, and AI tooling, and when the team needs enforcement below the network layer. A device-level control matters because anything that bypasses the gateway can bypass the protection.
Technical breakdown
Why install-time governance targets a different attack layer
Install-time governance blocks software before it is executed on a developer device. That is different from SCA, which checks known dependency risk, and different from EDR, which watches for malicious behaviour after execution has begun. The control point matters because many modern supply chain attacks arrive through legitimate marketplaces, registries, or extension stores, where the package may look clean until it is installed or updated. Koi’s model intercepts that install moment and pairs it with endpoint inventory so teams can see what is already present. The architectural trade-off is that the control only works where the governed install path is visible and enforceable.
Practical implication: Practitioners should map which install paths are actually governed, then test whether anything bypasses the intended control point.
Why orchestration depends on the rest of the stack
Koi’s approach relies on existing MDM, EDR, SWG, or similar controls to act on its alerts, rather than enforcing everything from a dedicated on-device agent. That makes the quality of protection dependent on how quickly those other tools respond and how consistently they are integrated. In practice, orchestration can widen coverage when an estate is already mature, but it also introduces latency, policy drift, and troubleshooting overhead. For developer environments, where installs happen quickly and often off-network, those delays can matter more than they do in conventional endpoint workflows.
Practical implication: Teams should validate whether their broader endpoint stack can respond at install speed, not just eventually.
Why supply chain age controls are becoming a baseline expectation
A large share of malicious packages are brand new releases or freshly compromised updates, which is why minimum-age or cooldown policies are increasingly relevant. The idea is simple: hold new artifacts long enough for the community and detection systems to surface malicious behaviour before widespread deployment. Koi’s article does not show the same countermeasure publicly, while the alternative it highlights does. That creates a governance question about whether install control is enough without a time-based filter on new software provenance.
Practical implication: Security teams should treat package age, release freshness, and provenance checks as separate controls rather than assuming install blocking alone is sufficient.
Threat narrative
Attacker objective: The attacker wants to get malicious software onto developer endpoints quickly enough to reach code, credentials, or build workflows before defenders intervene.
- Entry occurs when a malicious package, extension, or AI tool is published through a trusted marketplace or registry and reaches developer install workflows.
- Credential or control exposure follows when the risky artifact is allowed onto the device before the wider community identifies it as hostile.
- Impact comes from the malicious software running inside the developer environment, where it can enable supply chain compromise, credential theft, or downstream code tampering.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Install governance is becoming a supply chain control plane, not a point tool. The article shows that the real question is no longer whether teams need install-time protection, but where that control sits in the broader developer security stack. Once governance spans packages, extensions, AI tooling, and MCP servers, the control starts to function like a policy layer over software intake. Practitioners should evaluate it as part of identity and trust governance for developer machines, not as a narrow endpoint feature.
Acquisition changes the operational meaning of a security control. When a focused control becomes a feature inside a broader platform, buyers inherit new roadmap, packaging, and integration dependencies. That does not automatically weaken the control, but it does change how predictable it is to operate at developer speed. Teams should assume that commercial structure can alter security operability even when the technical idea remains sound.
Minimum-age controls deserve the same governance attention as signature or reputation checks. The article’s reference to fast-moving package attacks shows that time itself is part of the trust model. A control that delays fresh releases can be more effective than a purely reactive detector when the threat window is short. Practitioners should stop treating freshness policies as a niche feature and start treating them as a core supply chain governance decision.
The developer workstation is now part of the software trust boundary. Packages, browser plugins, extensions, and AI tools are no longer just productivity additions. They are machine-level ingress points for code, secrets, and delegated access, which means endpoint governance and supply chain governance are converging. Security teams should align endpoint policy, software provenance, and NHI-style trust boundaries instead of managing them as separate problems.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Endpoint install governance is now part of the developer trust boundary. Teams that still separate endpoint control from software supply chain policy will miss how packages, extensions, and AI tools converge on the same machine-level ingress point. The programme question is whether policy can be enforced at install time without turning developer workflows into a support problem.
Platform consolidation changes the risk model even when the control stays the same. Once a specialist control is absorbed into a larger suite, buyers inherit a different operating rhythm, different packaging logic, and a different integration surface. That does not make the control irrelevant, but it does mean procurement and architecture teams need to reassess operational ownership.
Install-age controls should be treated as a core supply chain defense. Freshly published software is often the highest-risk software, and a cooldown window can reduce exposure before broader detection catches up. For security leaders, the practical move is to decide whether age-based blocking belongs in endpoint policy, software provenance policy, or both.
For practitioners
- Define the governed install surface Inventory which sources are actually blocked or inspected across package managers, extensions, browser plugins, AI tools, and MCP servers, then document the bypass paths that still exist.
- Test response speed across the endpoint stack Measure how long it takes an alert from install governance to become an enforced block when MDM, EDR, or SWG systems must act on it.
- Add release-age filtering to install policy Treat freshly published packages and updates as higher risk and require a cooldown window for software that enters developer machines from public ecosystems.
- Separate install governance from code and cloud controls Make sure teams do not assume that blocking a malicious install also addresses hardcoded secrets, vulnerable dependencies, IaC drift, or cloud misconfiguration.
Key takeaways
- Developer install governance is moving from a point capability to a broader trust-control decision, especially when it is absorbed into a larger platform.
- The core risk is not only malicious software, but also the operational complexity that can slow response when installs are governed through multiple upstream tools.
- Security teams should assess install-time blocking, release-age filtering, and broader code and cloud controls as separate layers of one supply chain programme.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001;TA0006;TA0010 — Initial Access; Credential Access; Exfiltration | The article centres on malicious software reaching developer endpoints through trusted channels and enabling downstream compromise. |
| Recommendation — Map install-time compromise paths to these tactics and monitor developer tooling for suspicious package provenance. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Install governance is fundamentally about controlling what software and tools are authorised onto developer devices. |
| Recommendation — Apply PR.AA-05 to govern which software sources and tools are permitted on developer endpoints. | ||
| CIS Controls v8 | CIS-5 — Account Management | Developer install governance depends on knowing which endpoints and identities can approve or receive software. |
| Recommendation — Use CIS-5 to tighten ownership and approval paths for software install rights. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | The article touches AI tools and MCP-style integrations that can consume external services unsafely if not governed. |
| Recommendation — Review external tool and API consumption paths for unsafe trust in developer tooling. | ||
Key terms
- Install-Time Governance: Install-time governance is the set of controls that decide whether software may reach a developer device, browser, or workspace before execution. It focuses on blocking, delaying, or reviewing packages, extensions, AI tools, and related artifacts at the moment they are introduced into the environment.
- Supply Chain Gateway: A supply chain gateway is a control layer that inspects or blocks software as it is installed from public or private ecosystems. It is designed to stop risky artifacts before execution, especially where conventional endpoint tools only see the result after the package has already landed.
- Developer Endpoint: A developer endpoint is a laptop or workstation used to write code, run tools, and access build or cloud systems. In identity governance terms, it is also a place where live credentials can be stored, copied, or exposed, which makes the device part of the control surface rather than just a user asset.
- Minimum Package Age: Minimum package age is a policy that delays or blocks use of newly published software until it has existed for a set period. It reduces exposure to freshly weaponised packages and rushed supply chain attacks by creating a cooling-off window before developers can install or update dependencies.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with broader security operations and governance decisions.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org