Runlayer’s lawsuit against Rippling is the kind of dispute that feels tailor-made for the current era of AI tooling: fast-moving, lightly standardized, and full of “who saw what first” questions that are hard to answer once product ideas start circulating through demos, evaluations, and informal technical collaboration.
At the center of the case is an MCP gateway product—an approach to connecting tools and services through the Model Context Protocol (MCP), a framework designed to make it easier for AI applications to interact with external systems in a consistent way. Runlayer says it built a gateway that solved a real integration problem for teams trying to operationalize MCP-based workflows. Rippling, according to Runlayer, evaluated that product and then chose to build something similar internally. Runlayer’s claim is not simply that Rippling competed; it alleges that Rippling’s internal build crossed the line from normal iteration into stealing Runlayer’s product idea.
The lawsuit, reported by TechCrunch, frames the conflict as more than a standard competitive story. It suggests that the evaluation process itself—what was learned, what was shared, and what was later replicated—matters as much as the final outcome. In other words, Runlayer is arguing that the path Rippling took to arrive at its own solution is legally relevant, not just the fact that both companies ended up offering comparable functionality.
Why MCP gateways are suddenly a legal flashpoint
To understand why this dispute has traction beyond the usual “startup vs. incumbent” narrative, it helps to look at what MCP gateways represent in practice. MCP is often discussed as a protocol, but for many teams it functions more like a bridge between the AI layer and the messy reality of enterprise software: ticketing systems, internal knowledge bases, data warehouses, automation tools, and custom services. A gateway, in this context, typically acts as a control plane—helping route requests, manage permissions, normalize tool access, and provide a smoother path from “we want MCP” to “we can actually deploy MCP safely and reliably.”
That last step is where many products differentiate. Two teams can both say they support MCP, but the details—how authentication is handled, how tool schemas are generated or validated, how errors are surfaced, how observability works, how multi-tenant environments are managed, and how quickly new tools can be onboarded—can be the difference between a demo and a production system.
When a large company evaluates a startup’s gateway, it isn’t just looking at whether the concept works. It’s looking at the architecture, the integration strategy, and the implementation choices that reduce time-to-value. Those are precisely the kinds of things that can become contentious if the evaluator later ships a competing product.
In the past, these disputes often centered on code copying or explicit reuse of proprietary assets. But in the modern AI ecosystem—where “ideas” can be expressed through system design patterns, prompt/tool orchestration strategies, and integration workflows—the boundary between inspiration and appropriation can feel blurry. That’s especially true when the technology is still maturing and the market is forming around early best practices.
Runlayer’s core allegation: evaluation to internal build
Runlayer’s complaint, as described in coverage, hinges on a sequence: Rippling evaluated Runlayer’s MCP gateway product, and then Rippling decided to build a similar capability internally. Runlayer’s position is that this sequence reflects more than ordinary competition. The company is effectively saying: we showed you our approach, you learned from it, and then you used that learning to create your own version without permission.
This is a familiar pattern in tech litigation, but it takes on a sharper edge in the AI tooling space because the “product idea” can be both abstract and concrete at the same time. A gateway might be described in high-level terms—“an MCP gateway that connects enterprise tools”—but the value may lie in the specific implementation decisions that make it work well. If those decisions were communicated during evaluation, and if the resulting internal product mirrors them closely, Runlayer’s argument gains force.
At the same time, Rippling will likely argue that building a similar product after evaluating a competitor is not inherently wrongful. Many companies evaluate vendors, learn from them, and then decide to develop internal solutions. That can be a legitimate business decision, particularly for large platforms that want tighter integration, better margins, or more control over roadmap priorities.
So the legal question becomes less about whether Rippling built something and more about what exactly Rippling took from the evaluation and whether that “taking” is protected under the relevant legal theories.
What “idea theft” usually means in court
The phrase “idea theft” can sound straightforward, but courts often treat it carefully. In many jurisdictions, raw ideas are difficult to protect. What is more commonly protected are specific expressions—code, documentation, designs that are sufficiently concrete, trade secrets, or other forms of proprietary information.
That means Runlayer’s case will likely depend on demonstrating that what Rippling allegedly replicated wasn’t just a general concept. Instead, Runlayer will need to show that the internal build drew from protectable material—such as confidential information, trade secrets, or specific implementation details that were shared under circumstances implying confidentiality.
Even when a plaintiff uses the language of “stealing an idea,” the underlying evidence tends to look like one of the following:
1) Timing and access
If Rippling had access to Runlayer’s materials during evaluation, and the internal product emerged soon after, that timing can support an inference of misuse. Timing alone rarely proves wrongdoing, but it can make other evidence more persuasive.
2) Similarity of implementation
Courts and experts often look for technical parallels that go beyond generic functionality. If two products share unusual design choices, specific workflows, or distinctive architectural patterns, that can suggest more than coincidence.
3) Confidentiality and documentation
If Runlayer provided detailed documentation, architecture diagrams, integration guides, or other materials marked confidential—or if there were NDAs or similar agreements—then the case can shift from “you copied an idea” to “you used confidential information.”
4) Trade secret handling
If Runlayer claims trade secrets, it must show that the information was kept secret and that reasonable steps were taken to protect it. This can include access controls, internal policies, and how information was shared with evaluators.
5) Evidence of intent
Direct evidence is rare, but emails, meeting notes, internal messages, or project plans can sometimes reveal whether the internal team was influenced by the startup’s specific approach.
The unique twist here is that the dispute is framed around an MCP gateway product idea rather than a single line of copied code. That doesn’t make the case impossible—it just raises the evidentiary bar. Plaintiffs typically need to translate “idea theft” into something the law recognizes as protectable.
Why incumbents building internally is common—and why it still sparks lawsuits
Rippling is not a random company in this story. It’s a platform with deep enterprise relationships and a strong incentive to own key parts of its stack. When new protocols emerge—especially ones that promise to standardize tool access—platform companies often face a strategic choice: partner with startups, or build their own capabilities.
From a business perspective, internal builds can be attractive for reasons that have nothing to do with copying. Large platforms want consistent security models, unified billing, predictable performance, and tight integration with existing workflows. They also may want to avoid dependency risk.
But from a startup perspective, vendor evaluations can feel like a one-way door. A startup invests engineering time to create a working product, then shares it with a potential buyer or partner. If the evaluator later builds a similar solution, the startup may feel that it paid the cost of discovery while the larger company captured the upside.
This is why the evaluation phase matters so much. If the evaluation involved sharing detailed architecture, integration strategies, or other proprietary information, the startup’s argument becomes stronger. If the evaluation was limited to public features or high-level discussions, the startup’s claim becomes harder.
In other words, the lawsuit is likely to turn on the boundaries of what was shared and what was later replicated.
The broader industry context: MCP adoption accelerates, and so does competitive sensitivity
MCP is gaining attention because it offers a structured way to connect AI systems to tools. As more teams adopt MCP-based workflows, the market for “plumbing” products—gateways, connectors, orchestration layers, and governance tools—expands quickly. These products sit at the intersection of AI and enterprise integration, which means they often require careful handling of permissions, audit logs, and reliability.
That combination makes them valuable and also makes them sensitive. Enterprises don’t just want a model that can call tools; they want a system that can do it safely, consistently, and with clear accountability. Gateways are where those requirements get implemented.
As a result, the competitive landscape is likely to produce more disputes like this one. Not necessarily because everyone is acting in bad faith, but because the pace of innovation creates situations where multiple teams converge on similar solutions. When that happens, the question becomes: did they converge independently, or did one team learn from the other?
In early-stage markets, independent convergence is common. Two teams can solve the same problem using similar patterns because the constraints are similar. But when one team has direct access to another’s product during evaluation, the convergence story becomes harder to accept without explanation.
Runlayer’s lawsuit, therefore, is not only about one company’s alleged experience. It’s also a signal to the market about how startups may seek legal remedies when they believe their competitive advantage was extracted during a vendor evaluation.
What to watch next: Rippling’s response and the evidence trail
As the case proceeds, the most important developments will likely be Rippling’s response and the shape of the evidence presented.
1) How Rippling characterizes the evaluation
Rippling may argue that the evaluation was limited, that any shared information was either non-confidential or already known in the industry, or that the internal build was based on general engineering knowledge rather than Runlayer-specific materials.
2) Whether there were NDAs