Keeping the real credential out of model context is a meaningful improvement, but the gateway still becomes a confused-deputy boundary. How granular are policies below the endpoint level? An agent allowed to call a CRM API may still be tricked into exporting the wrong customer or changing a field it should only read. I'd be interested in whether policies can constrain method, path, request fields, resource ownership, and response volume, and how those rules are tested against prompt injection.
In a similar vein, I've been playing with Nemesis8. It provides the same sandbox and network constraint as this repo but adds orchestration and observability. You can control and communicate a fleet of agent containers that persist sessions, configure MCP tooling, and schedule events. That appears to just be the surface, I'm still digging into it. Now that I've experienced this single-pane-of-glass interface, I don't think I'm going back. If this is a trend, I hope it sticks. Check it out:
https://github.com/DeepBlueDynamics/nemesis8
The important detail is whether approval binds to the exact proposed action, including the recipient, repository, issue, or data being sent, rather than just “allow Gmail” or “allow this endpoint.” How granular are the gateway policies for APIs where read and write actions share the same host?
jonathan from OneCLI here, yes - approval binds to the exact req by opening it (method, URL, body) when there’s a matching policy defined. then the gateway holds the call and the card shows the parsed payload.
just to clarify how it works - on same host, rules match based on method + path + body, not only the host. for example, GET /calendar/v3/* can be allowed while POST needs approval.
How do you even win in this space? I feel like every day I see either a paid or fully OSS version of this product being posted here. As an end user I've become so overwhelmed that I've just started to mostly ignore them at this point. I can't be the only potential customer feeling this way?
Honestly, we're not sure yet how we win this space. We both come from security backgrounds, and that's probably what led us to where we are today. basically we built the gateway first because we were afraid of using openclaw the way it came out of the box. we didn't even connect our gmail out of fear. then after a while working with agents behind the gateway, we just started building our own agent that integrates better with it, for me and my partner. So maybe it lands with the same kind of people as us, who worry about the security side and want that safe feeling. Still figuring out how many of us are out there.
> I feel that YC just invests in anything these days.
When there is a popular gold rush, YC invests in many companies that do the same thing with the expectation that 1) a rising tide lifts all ships, and 2) if there is a clear winner, they have eggs in every basket.
It’s definitely a crowded space, totally agree about it.
honestly for us we didn't want to commit to a specific provider, whether that's grok or openai. So we decided to go with a harness that lets us switch models easily when one is down, or when another provider comes out with a new improved model
I think it's pretty interesting - I can see why companies would want to go for this instead of build everything themselves...
Curious about how your customers are responding to pricing. 20 agents for $499/month without API costs included feels steep... but perhaps within the range of "worth it if we don't have to think about this".
Keeping the real credential out of model context is a meaningful improvement, but the gateway still becomes a confused-deputy boundary. How granular are policies below the endpoint level? An agent allowed to call a CRM API may still be tricked into exporting the wrong customer or changing a field it should only read. I'd be interested in whether policies can constrain method, path, request fields, resource ownership, and response volume, and how those rules are tested against prompt injection.
Honest question, how does this project already has over 3,200 stars on GitHub?
Their video demo was posted 13 hours ago, and it only has 38 views as of the time of this post.
The post on HN is 4 hours ago.
In a similar vein, I've been playing with Nemesis8. It provides the same sandbox and network constraint as this repo but adds orchestration and observability. You can control and communicate a fleet of agent containers that persist sessions, configure MCP tooling, and schedule events. That appears to just be the surface, I'm still digging into it. Now that I've experienced this single-pane-of-glass interface, I don't think I'm going back. If this is a trend, I hope it sticks. Check it out: https://github.com/DeepBlueDynamics/nemesis8
The important detail is whether approval binds to the exact proposed action, including the recipient, repository, issue, or data being sent, rather than just “allow Gmail” or “allow this endpoint.” How granular are the gateway policies for APIs where read and write actions share the same host?
jonathan from OneCLI here, yes - approval binds to the exact req by opening it (method, URL, body) when there’s a matching policy defined. then the gateway holds the call and the card shows the parsed payload.
just to clarify how it works - on same host, rules match based on method + path + body, not only the host. for example, GET /calendar/v3/* can be allowed while POST needs approval.
How do you even win in this space? I feel like every day I see either a paid or fully OSS version of this product being posted here. As an end user I've become so overwhelmed that I've just started to mostly ignore them at this point. I can't be the only potential customer feeling this way?
Honestly, we're not sure yet how we win this space. We both come from security backgrounds, and that's probably what led us to where we are today. basically we built the gateway first because we were afraid of using openclaw the way it came out of the box. we didn't even connect our gmail out of fear. then after a while working with agents behind the gateway, we just started building our own agent that integrates better with it, for me and my partner. So maybe it lands with the same kind of people as us, who worry about the security side and want that safe feeling. Still figuring out how many of us are out there.
You're not alone, I don't get it either and this market is extremely crowded with many agent tools popping up everyday.
Some closed source, lots that are open source, hundreds of thousands and many which are completely vibecoded.
I feel that YC just invests in anything these days.
I mean, I don't see a moat here.
Like, why this over Grok Bot or anything that Anthropic or OpenAI would make for their 900M+ users?
Or is that the goal all along? Get acquired by a lab?
> I feel that YC just invests in anything these days.
When there is a popular gold rush, YC invests in many companies that do the same thing with the expectation that 1) a rising tide lifts all ships, and 2) if there is a clear winner, they have eggs in every basket.
It’s definitely a crowded space, totally agree about it. honestly for us we didn't want to commit to a specific provider, whether that's grok or openai. So we decided to go with a harness that lets us switch models easily when one is down, or when another provider comes out with a new improved model
Yep. OrcaBot has all these features. Free on desktop.
It's been out for 6 months.
I think it's pretty interesting - I can see why companies would want to go for this instead of build everything themselves...
Curious about how your customers are responding to pricing. 20 agents for $499/month without API costs included feels steep... but perhaps within the range of "worth it if we don't have to think about this".
Interesting, gonna take a closer look at this. But nice repo!