Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running NanoClaw in a Docker Shell Sandbox

docker.com

Post reply on HN
Print view View original

41–50 of 83 posts

Re: Running NanoClaw in a Docker Shell Sandbox

#41

Post by gostsamo »

botusaurus wrote: post #36
ryanrasti wrote: post #33

Earlier quoted context omitted.

This is a really good question because it hits on the fundamental issue: LLMs are useful because they can't be statically modeled. The answer is to constrain effects, not intent. You can define capabilities where agent behavior is constrained within reasonable limits (e.g., can't post private email to #general on Slack without consent). The next layer is UX/feedback: can compile additional policy based as user reques…

but how do you check that an email is being sent to #general, agents are very creative at escaping/encoding, they could even paraphrase the email in words decades ago securesm OSes tracked the provenience of every byte (clean/dirty), to detect leaks, but it's hard if you want your agent to be useful

you can restrict the email send tool to have to/cc/bcc emails hardcoded in a list and an agent independent channel should be the one to add items to it. basically the same for other tools. You cannot rewire the llm, but you can enumerate and restrict the boundaries it works through.

exfiltrating info through get requests won't be 100% stopped, but will be hampered.

Re: Running NanoClaw in a Docker Shell Sandbox

#42

Post by ATechGuy »

ryanrasti wrote: post #33
ATechGuy wrote: post #4

Earlier quoted context omitted.

And how are you going to define what ocaps/flows are needed when agent behavior is not defined?

This is a really good question because it hits on the fundamental issue: LLMs are useful because they can't be statically modeled. The answer is to constrain effects, not intent. You can define capabilities where agent behavior is constrained within reasonable limits (e.g., can't post private email to #general on Slack without consent). The next layer is UX/feedback: can compile additional policy based as user reques…

TBH, this looks like an LLM-assisted response.

Re: Running NanoClaw in a Docker Shell Sandbox

#43

Post by botusaurus »

gostsamo wrote: post #41
botusaurus wrote: post #36

Earlier quoted context omitted.

but how do you check that an email is being sent to #general, agents are very creative at escaping/encoding, they could even paraphrase the email in words decades ago securesm OSes tracked the provenience of every byte (clean/dirty), to detect leaks, but it's hard if you want your agent to be useful

you can restrict the email send tool to have to/cc/bcc emails hardcoded in a list and an agent independent channel should be the one to add items to it. basically the same for other tools. You cannot rewire the llm, but you can enumerate and restrict the boundaries it works through. exfiltrating info through get requests won't be 100% stopped, but will be hampered.

parent was talking about a different problem. to use your framing, how you ensure that in the email sent to the proper to/cc/bcc as you said there is no confidential information from another email that shouldnt be sent/forwarded to these to/cc/bcc

Re: Running NanoClaw in a Docker Shell Sandbox

#44

Post by ryanrasti »

botusaurus wrote: post #36
ryanrasti wrote: post #33

Earlier quoted context omitted.

This is a really good question because it hits on the fundamental issue: LLMs are useful because they can't be statically modeled. The answer is to constrain effects, not intent. You can define capabilities where agent behavior is constrained within reasonable limits (e.g., can't post private email to #general on Slack without consent). The next layer is UX/feedback: can compile additional policy based as user reques…

but how do you check that an email is being sent to #general, agents are very creative at escaping/encoding, they could even paraphrase the email in words decades ago securesm OSes tracked the provenience of every byte (clean/dirty), to detect leaks, but it's hard if you want your agent to be useful

> decades ago securesm OSes tracked the provenience of every byte (clean/dirty), to detect leaks, but it's hard if you want your agent to be useful

Yeah, you're hitting on the core tradeoff between correctness and usefulness.

The key differences here: 1. We're not tracking at byte-level but at the tool-call/capability level (e.g., read emails) and enforcing at egress (e.g., send emails) 2. Agent can slowly learn approved patterns from user behavior/common exceptions to strict policy. You can be strict at the start and give more autonomy for known-safe flows over time.

Re: Running NanoClaw in a Docker Shell Sandbox

#46

Post by zmmmmm »

ATechGuy wrote: post #42
ryanrasti wrote: post #33

Earlier quoted context omitted.

This is a really good question because it hits on the fundamental issue: LLMs are useful because they can't be statically modeled. The answer is to constrain effects, not intent. You can define capabilities where agent behavior is constrained within reasonable limits (e.g., can't post private email to #general on Slack without consent). The next layer is UX/feedback: can compile additional policy based as user reques…

TBH, this looks like an LLM-assisted response.

and then the next:

> you're hitting on the core tradeoff between correctness and usefulness

The question is, is it a completely unsupervised bot or is a human in the loop. I kind of hope a human is not in the loop with it being such a caricature of LLM writing.

Re: Running NanoClaw in a Docker Shell Sandbox

#47

Post by gostsamo »

botusaurus wrote: post #43
gostsamo wrote: post #41

Earlier quoted context omitted.

you can restrict the email send tool to have to/cc/bcc emails hardcoded in a list and an agent independent channel should be the one to add items to it. basically the same for other tools. You cannot rewire the llm, but you can enumerate and restrict the boundaries it works through. exfiltrating info through get requests won't be 100% stopped, but will be hampered.

parent was talking about a different problem. to use your framing, how you ensure that in the email sent to the proper to/cc/bcc as you said there is no confidential information from another email that shouldnt be sent/forwarded to these to/cc/bcc

The restricted list means that it is much harder for someone to social engineer their way in on the receiving end of an exfiltration attack. I'm still rather skeptical of agents, but a pattern where the agent is allowed mostly readonly access, its output is mainly user directed, and the rest of the output is user approved, you cut down the possible approaches for an attack to work.

If you want more technical solutions, put a dumber clasifier on the output channel, freeze the operation if it looks suspicious instead of failing it and provoking the agent to try something new.

None of this is a silver bullet for a generic solution and that's why I don't have such an agent, but if one is ready to take on the tradeoffs, it is a viable solution.

Re: Running NanoClaw in a Docker Shell Sandbox

#48

Post by buremba »

TheTaytay wrote: post #34
buremba wrote: post #25

Neat! I wasn’t aware that Docker has an embedded microVM option. I use Kata Containers on Kubernetes (Firecrackers) and restrict network access with a proxy that supports you to block/allow domain access. Also swap secrets at runtime so agents don’t see any secrets (similar to Deno sandboxes) If anybody is interested in running agents ok K8S, here is my shameless plug: https://github.com/lobu-ai/lobu

Woah, that looks great. I’ve been looking for something like this. Neither thr readme or the security doc go into detail on the credential handling in the gateway. Is it using tokens to represent the secrets, or is the client just trusting that the connection will be authenticated? I’m trying to figure out how similar this is to something like Fly’s tokenizer proxy.

I’m working on the documentation right now but I had to build 3 prototypes to get here. :)

After seeing Deno and Fly, I rewrote the proxy being inspired by them. I integrates nicely with existing MCP proxy so agent doesn’t see any MCP secrets either.

Re: Running NanoClaw in a Docker Shell Sandbox

#49

Post by jimminyx »

jimminyx wrote: post #35
dotty- wrote: post #17

Earlier quoted context omitted.

At first glance, this feels like just an internal testing prompt at their company for some sort of sales pipeline. Feels more like an accident. None of the referenced files are actually in the repository. If the prompts had more of a "If the user mentions xyz, mention our product" that would absolutely give more credence that this is an advertising prompt, but none of that is here.

Gavriel (creator of NanoClaw) here. This is the correct answer. It's more dogfooding than testing though. This is describing the structure of an Obsidian vault that is mounted in the container as an additional directory that claude has access to. Me and my co-founder chat with NanoClaw in WhatsApp and get daily briefings on sales pipeline status, get reminders on tasks, give it updates after calls, etc. You can see t…

Gonna change things so it uses CLAUDE.local.md for user-specific updates and the regular CLAUDE.md is static. This will help prevent this from happening to contributors.

CLAUDE.local.md is deprecated but I'm sure anthropic will continue supporting it for a long time.

Post reply on HN