I currently use Claude web with an MCP component for my workflows but axe looks like it could be a nicer and quicker way to work with the tools I have.

It's a different conversation when we talk about people learning to code now though. I'd probably not recommend going for the power tool until you have a solid understanding of the manual tools.

Components only have access to what you explicitly grant (e.g. a single directory). They're written in any language (Rust, Go, Python, JS) and pulled from the asterai registry.

Under the hood, asterai is a WASM component model registry and runtime built on wasmtime. You publish a component, set an env var to authorize it as a tool, and asterbot discovers and calls it automatically.

I built this because I think the WASM component model is a great way to build software but the ecosystem is missing key infrastructure (especially an open, central registry). AI agents felt like a natural fit since tool security is a real problem, and WASM sandboxing addresses it by default.

Still early stage, but all functionality in the repo is tested and working. Happy to answer questions!

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

Points: 2

# Comments: 0

Asterbot is a modular AI agent where every capability (such as tools, memory, LLM provider etc.) is a swappable WASM component.

Components are written in any language (Rust, Go, Python, JS), sandboxed via WASI, and pulled from the open asterai registry. Think microkernel architecture for AI agents.

Recently I saw how ClawHub had "341 malicious skills", and couldn't help but think how WASM/WASI resolves most of these issues by default, since everything is sandboxed.

So I've spent my weekend building Asterbot, a modular AI agent where every capability is a swappable WASM component.

Want to add web search? That's just another WASM component. Memory? another component. LLM provider? component.

The components are all sandboxed, they only have access to what you explicitly grant, e.g. a single directory like ~/.asterbot (the default). It can't read any other part of the system.

Components are written in any language (Rust, Go, Python, JS), sandboxed via WASI, and pulled from the asterai registry. Publish a component, set an env var to authorise it as a tool, and asterbot discovers and calls it automatically. Asterai provides a lightweight runtime on top of wasmtime that makes it possible to bundle components, configure env vars, and run it.

It's still a proof of concept, but I've tested all functionality in the repo and I'm happy with how it's shaping up.

Happy to answer any questions!

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

Points: 1

# Comments: 0

I suppose I'm thinking of it as a more elegant way of doing something equivalent to top-down agent routing, where the top agent routes to 2-legged agents.

I'd be interested to hear more about how you handle the provenance tracking in practice, especially when the agent chains multiple data sources together. I think my question would be: what's the practical difference between dynamic attenuation and just statically removing the third leg upfront? Is it "just" a more elegant solution, or are there other advantages that I'm missing?

Sometimes you only care about the high level aspect of it. The requirements and the high-level specification. But writing the implementation code can take hours if you're unfamiliar with a specific library, API or framework.

"review every diff line by line" is maybe not the best way to have described it, I essentially I meant that I review the AI's code as if it were a PR written by a team member, so I'd still care about alignment with the rest of the codebase, overall quality, reasonable performance, etc.

I can only think of two ways to address it:

1. Gate all sensitive operations (i.e. all external data flows) through a manual confirmation system, such as an OTP code that the human operator needs to manually approve every time, and also review the content being sent out. Cons: decision fatigue over time, can only feasibly be used if the agent only communicates externally infrequently or if the decision is easy to make by reading the data flowing out (wouldn't work if you need to review a 20-page PDF every time).

2. Design around the lethal trifecta: your agent can only have 2 legs instead of all 3. I believe this is the most robust approach for all use cases that support it. For example, agents that are privately accessed, and can work with private data and untrusted content but cannot externally communicate.

I'd be interested to know if you have reached similar conclusions or have a different approach to it?

The distinction drawn between both concepts matters. The expertise is in knowing what to spec and catching when the output deviates from your design. Though, the tech is so good now that a carefully reviewed spec will be reliably implemented by a state-of-the-art LLM. The same LLM that produces mediocre code for a vague request will produce solid code when guided by someone who understands the system deeply enough to constrain it. This is the difference between vibe coding and zen coding.

Zen coders are masters of their craft; vibe coders are amateurs having fun.

And to be clear, nothing wrong with being an amateur and having fun. I "vibe code" several areas with AI that are not really coding, but other fields where I don't have professional knowledge in. And it's great, because LLMs try to bring you closer to the top of human knowledge on any field, so as an amateur it is incredible to experience it.

For example, say you have a shell script to make a bank transfer. This just makes an API call to your bank.

You can't trust the AI to reliably make a call to your traceability tool, and then to your OTP confirmation gate, and only then to proceed with the bank transfer. This will eventually fail and be compromised.

If you're running your agent on a "composable tool runtime", rather than raw shell for tool calls, you can easily make it so the "transfer $500 to Alice" call always goes through the route trace -> confirm OTP -> validate action. This is configured at build time.

Your alternative with raw shell would be to program the tool itself to follow this workflow, but then you'd end up with a lot of duplicate source code if you have the same workflow for different tool calls.

Of course, any AI agent SDK will let you configure these workflows. But they are locked to their own ecosystems, it's not a global ecosystem like you can achieve with WASM, allowing for interop between components written in any language.

OpenClaw is just an idea of what's coming. Of what the future of human-software interface will look like.

People already know what it will look like to some extent. We will no longer have UIs there you have dozens or hundreds of buttons as the norm, instead you will talk to an LLM/agent that will trigger the workflows you need through natural language. AI will eat UI.

Of course, OpenClaw/Moltbot/Clawdbot has lots of security issues. That's not really their fault, the industry has not yet reached consensus on how to fix these issues. But OpenClaw's rapid rise to popularity (fastest growing GH repo by star count ever) shows how people want that future to come ASAP. The security problems do need to be solved. And I believe they will be, soon.

I think the demand comes also from the people wanting an open agent. We don't want the agentic future to be mainly closed behind big tech ecosystems. OpenClaw plants that flag now, setting a boundary that people will have their data stored locally (even if inference happens remotely, though that may not be the status quo forever).

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

Points: 1

# Comments: 0

For most actions that don't have much content, this could work well as a simple phone popup where you authorise or deny.

The annoying parts would be if you want the agent to reply to an email that has a full PDF or a lot of text, you'd have to review to make sure the content does not include prompt injections. I think this can be further mitigated and improved with static analysis tools specifically for this purpose.

But I think it helps to think of it not as a way to prevent LLMs to be prompt injected. I see social engineering as the equivalent of prompt injection but for humans. So if you have a personal assistant, you'd also them to be careful with that and to authorise certain sensitive actions every time they happen. And you would definitely want this for things like making payments, changing subscriptions, etc.

From that perspective, the idea of microservices is basically "IKEA for software" relying on (primarily) HTTP as the interface between components. But this doesn't really solve it entirely, or very elegantly, because you still need to write the server boilerplate and deploy it, which will be different depending on the programming language being used. Also, your app may require different protocols, so you'll be relying on different standards for different component interactions, therefore the interface is not constant across your entire application.

I believe there's one way we can achieve this reliably, which is via WebAssembly, specifically via the WASM component model [1].

But we need an ecosystem of components, and building an ecosystem that everyone uses and contributes to will likely be the challenging part. I'm actually working on this right now, the platform I've been building (asterai.io) started out as an agent building platform (using WASM components for tool calls) but is evolving into being mostly a registry and (open source) lightweight runtime for WASM components.

The idea of using WASM to solve for this is very simple in concept. Think about a tool like Docker, but instead of images you have an "environment" which is a file that defines a set of WASM components and ENV vars. That's basically it, you can then run that environment which will run all components that are executable. Components can call each other dynamically, so a component can act as a library as well, or it may be only a library and not an executable. A component can also only define an interface (which other components can implement), rather than contain any implementation code.

This architecture solves the main challenges that stop "IKEA for software" from being a reality: 1. You can write WASM components in any programming language. 2. You can add components to your environment/app with a single click, and interfacing is standardised via WIT [2]. 3. Deploying it is the same process for any component or app.

Of course, it still would require significant WASM adoption to become a reality. But I think WASM is the best bet for this.

[1]: https://component-model.bytecodealliance.org [2]: https://component-model.bytecodealliance.org/design/wit.html