Koi

Organizations that primarily need classic EDR/MDM

• If the primary requirement is malware detection, deep telemetry, and full incident response capabilities, established EDR/MDM suites may provide broader coverage.

Organizations that require publicly documented compliance proofs

• Buyers needing published SOC 2 Type II or ISO 27001 documentation may find public materials insufficient based on accessible sources; such buyers should request compliance evidence during procurement.

Environments that are already tightly standardized and centrally managed

• If extensions/packages are already blocked or centrally managed with low variance, the incremental value from a governance-focused product may be limited.

Organizations that require extensive third-party peer reviews before engaging

• The lack of accessible, high-volume third-party review content increases the diligence burden for some buyers.

Current limitations acknowledged by the vendor

• No explicit public limitations page was found in the sources accessed; vendor materials emphasize broad coverage.

Roadmap / future features

• Not publicly documented in accessible sources.

Scale limitations

• Not documented in accessible sources.

Security/compliance gaps

• Public documentation for security certifications (SOC 2 / ISO) was not found in the reviewed pages.

API limitations or integration constraints

• Not documented in accessible sources.

• Focus on governing software installed via marketplaces and registries (extensions, packages, models, MCP components) as first-class assets.
• The vendor describes a risk scoring engine (referred to as "Wings" in vendor materials) that evaluates code differences, runtime indicators, ownership changes, update channels, and install source.
• Maintains a public research feed (KoiDex) that publishes writeups and findings related to registries, extensions, and related risks.

• Mature endpoint suites provide broader enterprise footprints, more independently reviewed performance metrics, and a wider set of security features.

Availability caveat (important)

• Traditional review platforms did not surface accessible product review pages for Koi Security during this research.
• Access to a major analyst site was blocked (robots restriction) for direct verification in this environment, so quotes from that analyst platform could not be collected.
• As a result, this section relies primarily on vendor-published case studies, community discussion, and press coverage.

Vendor-published testimonial / case study (summary)

• Koi publishes a customer story about Cambia Health Solutions that describes the deployment objectives and outcomes. As vendor-published content, performance and ROI claims should be treated as directional unless independently verified.

Community / social feedback (mixed to critical)

• On community forums, some contributors criticized Koi-linked content as being partially generated by large language models and noted instances of promotional posting activity attributed to accounts sharing Koi-related materials.

What customers appear to choose Koi for (inferred from positioning and acquisition rationale)

• Visibility and control over marketplace-sourced software that traditional endpoint tools may not govern effectively.
• Policy enforcement and pre-/post-install risk assessment for extensions, packages, and AI components.

Why some buyers might hesitate (inferred from public sentiment and category risks)

• Unclear public security and compliance posture (no easily found SOC 2 / ISO public statements in accessible sources).
• Potential workflow disruption if blocking installs/extensions is implemented aggressively.
• Category novelty: the "agentic endpoint" framing is relatively new and may require additional independent benchmarking for some buyers.

Cambia Health Solutions (vendor case study)

• What’s provided
  • Koi highlights Cambia Health Solutions as a customer and frames the deployment around securing installs from marketplaces and registries.
• What’s missing / methodology gaps
  • The accessible case content did not provide independently audited metrics (e.g., quantified reductions in incidents, measured time savings, measured false-positive rates).
  • Without third-party validation, outcomes reported in vendor case studies should be treated as vendor statements rather than independently verified results.

• Discovery/inventory of installed software across endpoints
• Risk scoring via the vendor-described "Wings" risk engine based on code diffs, runtime behavior, ownership changes, update channels, network egress, and install source
• Policy enforcement (auto-approve, block, cooldowns, allow/block lists)
• Post-install detection and response actions (quarantine/remove, rollback, ticketing)