Comment by verdverm

4 days ago

See my peer comment for some other thoughts.

What stops your agent from adding a new MCP server on its own? Would you consider that a gap in security posturing?

Pi notably ships without MCP support (or it did, I can't remember if they're adding it to Pi main or just the durable one). From a vanilla Pi perspective, I'm pretty sure but not positive that it can't. It would have to install an MCP plugin, and you would have to re-launch Pi to load that plugin.

It does have native tools, but they're also in plugins that aren't hot-reloaded. The LLM would have to write the tool, you close Pi and re-open it before it was available.

> Would you consider that a gap in security posturing?

Honestly, I think trying to secure the harness is a lost cause for the same reasons SELinux never really took off. They solve a real problem in a way so painful people would rather just live dangerously.

I actually wrote a thing to implement my security posture https://github.com/SethCurry/abyss TLDR it pretends to be an ACP agent, but runs the agent inside Docker (with optional bind mounts) and proxies the ACP connection into the container.

I'm also tinkering with WASM-based plugins in the ACP proxy to add some additional security and compliance posturing at the protocol layer (ie agnostic to what the underlying agent is). E.g. I slapped together a plugin that will automatically cancel a prompt mid-turn if an OpenRouter API token shows up in a) the prompt, b) agent output/thinking, c) agent tool calls. ([1], [2], [3]). The grand vision is slapping centralized management on that so security and compliance teams get a "firewall" of sorts to prevent leaking secrets, filter bash commands, censor PII, yada, yada.

1. Screenshot of it blocking something in Zed https://abyss.scurry.io/docs/guides/what-is-abyss/#i-am-not-... (I need to add buffering so it doesn't output any of the key)

2. Implementation of ^ https://github.com/SethCurry/abyss/blob/main/plugins/secrets...

3. Plugin architecture docs https://abyss.scurry.io/docs/guides/04-plugins/02-developing...

  • Hey, I agree that trying to secure the harness with bubblewrap or other case-by-case limitations is inherently unsatisfactory, and I also wrote an open-source agent container tool (on top of gVisor + Kubernetes, since it can run pretty much anywhere at the cost of some performance). In case you're interested, I'd love your feedback, and obviously feel free to take any pieces that are helpful. The transparent egress proxy in particular was a pain to figure out: https://yaac.dev/

    • I looked and will give it a try, but haven’t had a chance yet because life.

      I had debated building something like this, and I really want to see what the other fork in the path looks like.

      One of the core tenants of mine is to not impose a workflow or set of tooling on the user. I specifically opted not to go with k8s because access to local files is going to be a pain, and I think people will still expect that. There’s all sorts of “I need this binary that’s not in APT”, or “you need this cert to test, and we can’t commit it” stumbling blocks.

      Yours feels like it’s pushing me into an unfamiliar workflow, but opinionated tools are often better so it’s worth a try.

      My only direct criticism is that I think k8s is a bad way to go for this (but is probably what people expect). For personal use, k8s is more than I want to deal with. For work use, I suspect lambdas would be cheaper and avoid a ton of maintenance junk. We tend to think of agents as a persistent process, but they’re sort of not. They’re a stateless process that is effectively dead until a new message comes in, let it be dead until something else comes down the pipe.

      1 reply →

    • I was talking about how I was looking for something like this earlier.

      1. I can feel the claudisms coming through, a turnoff for me personally

      2. You're shaving yourself short on a good pun

      I'll still give it a look since I am in the market for a kubernetes based platform for dealing with lots of agents across harnesses. Scion was my goto, but I'm not so keen on that project anymore.

      My ideal solution does not require a running server (CRDs should be sufficient) nor a UI, I want to start new agents in my existing automations.

      3 replies →

  • Pi ships with MCP support

    https://pi.dev/docs/latest/mcp

    I'm using a number of @gotgene's plugins, they are really nice

    I'm looking at porting my Dagger based env to Pi, mainly because it allows me to fork / time-travel the complete environment. One thing I really like about Pi is that /tree command and friends. It aligns really well with how container layer based env can be realized with the Dagger SDK.