OneCLI (YC S26) Just Hit 300K Downloads With a Credential Firewall for AI Agents. Is 'Agent Identity' a Real YC F26 Wedge?

This morning, OneCLI (YC S26) posted a Launch HN for an open-source "sandboxed agent harness for teams." The pitch is narrow and specific: give every employee a personal AI agent, run it in a sandbox, and route every tool call through a gateway that injects real credentials at the network layer so the agent never actually sees your API keys or OAuth tokens. Agents get placeholder tokens; the secrets stay out of the model's context entirely.

The traction is the part that should make you sit up. OneCLI is already at 2.5K+ GitHub stars and 300K+ downloads, and it's the default credential layer for products like NanoClaw, all before the batch has really started. That combination, a hot problem plus real adoption plus a YC stamp, is exactly the kind of signal that makes a solo founder staring at the YC F26 application ask the obvious question: is "agent identity and secrets" a real startup, or did I just watch someone fence off the wedge I was going to pitch?

Here's the honest answer, and what it means for your application.

What did OneCLI actually launch?

Strip away the framing and OneCLI is solving a boring, real problem: AI agents need access to your tools, and giving a probabilistic system your Gmail, GitHub, Jira, and Slack credentials is terrifying. Their answer is a firewall-style gateway. The agent requests an action, the gateway holds the real secret and injects it at the network layer, and you get per-agent access control and full audit logs across 50+ integrations. A compromised or jailbroken agent can misbehave, but it can't exfiltrate the key, because it never had the key.

This is the same category of concern that put a prompt-injection story on the Hacker News front page back in July, when someone tricked Claude into silently leaking a user's private data. The difference is that OneCLI isn't selling fear, it's selling plumbing. That distinction matters enormously for how you position against it.

Isn't 'agent security' already a crowded wedge?

Yes, and you should say so in your application before a partner says it to you. "AI agent security" as a category is loud. There are prompt-injection defenses, agent observability tools, sandboxed runtimes, and now credential gateways. YC has funded across most of this surface already.

But "crowded category" and "closed wedge" are not the same thing, and conflating them is one of the most common mistakes we see in YC applications. The category is crowded. The specific, unglamorous slice OneCLI picked, agent identity and secret injection, is narrow enough that most of the noisy "agent security platform" companies aren't actually competing for it. OneCLI won a specific job (keep secrets out of the model) rather than claiming the whole category. That's the move YC rewards, and it's the move you should copy, not the surface-level takeaway that "security is taken."

Is agent identity a wedge, or just a feature?

This is the question a YC F26 partner will actually push on, so let's answer it directly.

The bear case: credential injection looks like a feature that AWS, a model provider, or the agent framework itself (LangChain, the big labs' agent SDKs) absorbs in a release cycle. If it's a feature, you die when the platform ships it. This is the exact same risk we wrote about when Apple shipped its Safari MCP server and "Sherlocked" a swath of agent-browser startups.

The bull case, and the reason OneCLI's 300K downloads matter, is that identity and access have historically been durable standalone businesses precisely because they sit between everything. Okta, Vault, and Auth0 are all "features" you could imagine a platform bundling, and all became large independent companies because being the neutral broker across many tools is a position no single platform wants to cede to a competitor. If agents become the primary thing touching your systems, the identity layer for agents is plausibly the same shape of business.

You don't need to win this argument in the abstract. You need to show YC you know which side of it you're betting on and why the platform won't casually eat you. "We're the neutral credential broker across 50+ tools, which no single model lab will build because it means integrating their competitors' products" is a defensibility answer. "We add a security layer to agents" is not.

What YC F26 partners will push on

If you're applying to F26 with anything in this space, expect three questions, and OneCLI's launch just raised the bar on all of them.

First, why won't the framework or the lab build this? Have a real answer tied to incentives, not just "we'll move faster." Second, where's the wedge that isn't already open source? OneCLI gave away the harness. If your entire product is now something a founder can git clone this afternoon, your business has to live somewhere else, in the hosted control plane, the compliance surface, the enterprise audit and access-governance layer. Third, why you? Agent-infra credibility is now table stakes; the partners have seen dozens of these.

Notice that the open-source move doesn't kill the opportunity, it relocates it. The same pattern showed up with TensorZero and other OSS-first infra companies: the free tool is distribution, and the business is the governance, hosting, and team features that a 300K-download user base eventually needs. If you're pitching agent identity for F26, your application should make explicit which layer you monetize and why the free layer is a moat (distribution and standard-setting) rather than a giveaway.

How to position an agent-infra startup for F26

The practical takeaway is not "pick a different idea because OneCLI exists." One funded company does not close a category; YC funds competitors in the same batch constantly. The takeaway is to get more specific than they did. OneCLI owns "keep secrets out of the agent." What's the adjacent job that a team running fleets of agents will need next, agent-to-agent authorization, revocation and kill-switches, cross-org agent access, spend and rate governance, that isn't cleanly solved yet? Pick one job, show a working slice, and get a real user.

And write the OneCLI comparison into your application yourself. Partners respect founders who name the closest competitor and explain the gap, far more than founders who pretend the space is empty.

Before you submit, it's worth having someone who has actually sat in the YC partner seat pressure-test exactly these answers, the platform-risk question, the feature-versus-company question, the why-you question. That's the whole reason we built YC Roaster: you can get your F26 application and your positioning roasted by founders who've been through YC and know which of these answers survive the ten-minute interview and which fall apart on the first follow-up. It's a lot cheaper to hear "this reads like a feature" from an alum now than from a partner in your interview.

The agent identity wedge isn't closed. OneCLI just showed you how sharp your version of it has to be.