We've recently decided to complicate life of AI bots in our repo https://archestra.ai/blog/only-responsible-ai, hoping they will just choose those AI startups who are easier to engage with.

Comments URL: https://news.ycombinator.com/item?id=47804668

Points: 5

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=47686275

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46496639

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46418917

Points: 5

# Comments: 0

If you're building LLM agents that use tools, you're probably worried about prompt injection attacks that can hijack those tools. We were too, and found that solutions like prompt-based filtering or secondary "guard" LLMs can be unreliable.

Our thesis is that agent security should be handled at the network level between the agent and the LLM, just like a traditional web application firewall.

So we built Archestra Platform: an open-source gateway that acts as a secure proxy for your AI agents. It's designed to be a deterministic firewall against common attacks. The two core features right now are:

1) Dynamic Tool Engine: This is the key idea. Archestra restricts which tools an agent can even see or call based on the context source. If the context comes from an untrusted tool, the agent won't have access to high-privilege tools like execute_code or send_email. 2) Dual LLM Sanitization: An isolated LLM acts as a "sanitizer" for incoming data, stripping potentially malicious instructions before they're passed to the primary agent.

It’s framework-agnostic (works with LangChain, N8N, etc.), self-hostable (Kubernetes). We're just getting started and have more security features planned.

We'd love for you to take a look at the repo, try it out, and give us your feedback.

GitHub: https://github.com/archestra-ai/archestra

Docs: https://www.archestra.ai/docs/platform-dynamic-tools

Comments URL: https://news.ycombinator.com/item?id=45568635

Points: 9

# Comments: 1

For now, Archestra is categorizing tools and preventing the execution of tools that could leak data to the outside world without consent. Asking for permission for all tool calls may lead to fatigue; not asking for consent will expose the agent to the attack, so we're trying to strike a balance.

Local MCP servers are executables, and running straight from GitHub is quite dangerous. Also, to start the local MCP server and connect it to, for example, Gmail, one needs to register a Google Cloud account, issue a file with OAuth tokens, place it in a specific directory, and set the environment variable.

We built Archestra, a simple desktop orchestrator for open source MCP servers, enabling you to install and use self-hosted & remote MCP servers with just a few clicks. It's running local MCP servers in a Podman sandbox to prevent access to the host, dynamically adjusts the set of enabled tools, and maintains permanent memory. Most importantly, it handles authentication through the UI via OAuth or by retrieving API keys from the browser and launches MCP servers accordingly.

Archestra is open source and MIT: https://github.com/archestra-ai/archestra

A short demo, using GitHub, Gmail and Slack MCPs: https://www.loom.com/share/84ea6a684f014ebba5e39dd0dd0242a2

You can try it yourself by downloading the app and using it with local models, OpenAI, or some of our free tokens: https://archestra.ai.

Comments URL: https://news.ycombinator.com/item?id=43920127

Points: 1

# Comments: 0

Almost every tech company has private code—typically stored in private repositories. When working on Keep, we faced a decision: should we place certain code in the EE folder under a different license or keep it in a private repo, only sharing it with a small group of enterprise customers who explicitly requested it?

We chose to put that code on GitHub.

Ironically, putting more code in the GitHub repo made it appear "less open source," even though we could have simply hidden it, making the repo look like "clean OSS" as multiple companies do. For example, those who put their products without Web UI to the open source, build UI privately and serve the "full" version in the cloud.

While I understand (and share) the caution around licenses, I don’t think this concern applies to Keep. With 99% of our codebase under the MIT license, it’s a far cry from just having "parts of the code with an open source license."

I recommend running Keep locally and comparing the Open Source version to the playground where full version is running. You might find it challenging to spot the differences.

I also reccomend comparing Keep Open Source to BigPanda and Moogsoft. It may be surprising how much of it Keep OSS, real MIT-licensed Keep has.

Helm (https://github.com/grafana/oncall/tree/dev/helm/oncall), docker-composes for hobby and dev environments.

Besides deployment, there are two main priorities for OnCall architecture: 1) It should be as "default" as possible. No fancy tech, no hacking around 2) It should deliver notifications no matter what.

We chose the most "boring" (no offense Django community, that's a great quality for a framework) stack we know well: Django, Rabbit, Celery, MySQL, Redis. It's mature, reliable, and allows us to build a message bus-based pipeline with reliable and predictable migrations.

It's important for such a tool to be based on message bus because it should have no single point of failure. If worker will die, the other will pick up the task and deliver alert. If Slack will go down, you won't loose your data. It will continue delivering to other destinations and will deliver to Slack once it's up.

The architecture you see in the repo was live for 3+ years now. We were able to perform a few hundreds of data migrations without downtimes, had no major downtimes or data loss. So I'm pretty happy with this choice.