Why the open-source layer of this category went unmaintained

The timeline

Two dated claims about named companies, each from the company's own announcement, and two archive facts read from the GitHub API rather than asserted:

• 2024-01-31: Protect AI acquires Laiyer AI, the maker of LLM Guard, announcing a commercial version of it (Protect AI announcement, Business Wire).
• 2024-08-07: the last push to protectai/rebuff, which is archived.
• 2025-07-22: Palo Alto Networks completes its acquisition of Protect AI; the team and technology fold into Prisma AIRS (Palo Alto Networks press release).
• 2026-07-08: the last push to protectai/llm-guard, which is archived, one year after the acquisition closed.

LLM Guard was not a marginal tool. It is the library this project ships a migration adapter for, and at 3,201 stars it was the most adopted open-source input/output scanner in the category. It did not fail; it was acquired twice and then archived.

The state of the category

The pattern is incentives, not neglect

Nobody in this timeline behaved badly. An open-source guardrail library built by a startup is a wedge: it earns adoption, and the adoption is what an acquirer buys. After the exit, the free layer stops being the product and starts being a cost, and a cost with no owner gets archived. The people who built these tools mostly kept working on the same problem, inside platforms, where the checking layer is sold rather than given away. The repository is what gets left behind, and the repository is exactly the part a deployment depends on.

The tools in the table that are still moving prove the same rule from the other side. They are maintained by organisations whose business does not depend on monetising the checking layer itself, so an exit does not change the answer to who pays for maintenance.

What this means for a deployment

If a guardrail library sits on your request path, its maintenance model is part of your threat model. The question is not whether the project is good; LLM Guard was good. The question is who pays for its maintenance, and what happens to your integration on the day that answer changes. If you are holding an integration with an archived scanner right now, that is the situation the migration guide exists for: it keeps llm-guard's call signatures so the move starts as an import change.

And it is why this project's founding memo made ongoing maintenance funding a precondition of starting at all, before any code existed. That constraint aged better than the detector cap in the same memo, which is its own story.