7 ms·

IMO the security pitchforking on OpenClaw is just so overdone. People without consideration for the implications will inevitably get burned, as we saw with the

by ggrab 7mo ago

IMO the security pitchforking on OpenClaw is just so overdone. People without consideration for the implications will inevitably get burned, as we saw with the reddit posts "Agentic Coding tool X wiped my hard drive and apologized profusely". I work at a FAANG and every time you try something innovative the "policy people" will climb out of their holes and put random roadblocks in your way, not for the sake of actual security (that would be fine but would require actual engagement) but just to feel important, it reminds me of that.

sa-code 7mo ago
> every time you try something innovative the "policy people" will climb out of their holes and put random roadblocks in your way This is so relatable. I remember trying to set up an LLM gateway back in 2023. There were at least 3 different teams that blocked our rollout for months until they worked through their backlog. "We're blocking you, but you’ll have to chase and nag us for us to even consider unblocking you" At the end of all that waiting, nothing changed. Each of those teams wrote a document saying they had a look and were presumably just happy to be involved somehow?
- embedding-shape 7mo ago
  To be fair, the alternative is them having to maintain and continuously check N services that various devs deployed because it felt appropriate in the moment, and then there is a 50/50 chance the service will just sit there unused and introduce new vulnerability vectors. I do know the feeling you're talking about though, and probably a better balance is somewhere in the middle. Just wanted to add that the solution probably isn't "Let devs deploy their own services without review", just as the solution probably also isn't "Stop devs for 6 months to deploy services they need".
  - regularfry 7mo ago
    The trick is to make the class of pre-approved service types as wide as possible, and make the tools to build them correctly the default. That minimises the number of things that need review in the first place.
    - throwaway_z0om 7mo ago
      Yes providing paved paths that let people build quickly without approvals is really important, while also having inspection to find things that are potential issues.
- miki123211 7mo ago
  I think you should read "the Phoenix project." One of the lessons in that book is that the main reasons things in IT are slow isn't because tickets take a long time to complete, but that they spend a long time waiting in a queue. The busier a resource is, the longer the queue gets, eventually leading to ~2% of the ticket's time spent with somebody doing actual work on it. The rest is just the ticket waiting for somebody to get through the backlog, do their part and then push the rest into somebody else's backlog, which is just as long. I'm surprised FAANGs don't have that part figured out yet.
- pvtmert 7mo ago
  From my experience, it depends on how you frame your "service" to the reviewers. Obviously 2023 was the very early stage of LLMs, where the security aspects were quite murky at best. They (reviewers) probably did not had any runbook or review criteria at that time. If you had advertised this as a "regular service which happens to use LLM for some specific functions" and the "output is rigorously validated and logged", I am pretty sure you would get a green-light. This is because their concern is data-privacy and security. Not because they care or the company actually cares, but because fines of non-compliance are quite high and have greater visibility if things go wrong.
0x3f 7mo ago
Work expands to fill the allocated resources in literally everything. This same effect can be seen in software engineering complexity more generally, but also government regulators, etc. No department ever downsizes its own influence or budget.
H8crilA 7mo ago
This may be a good place to exchange some security ideas. I've configured my OpenClaw in a Proxmox VM, firewalled it off of my home network so that it can only talk to the open Internet, and don't store any credentials that aren't necessary. Pretty much only the needed API keys and Signal linked device credentials. The models that can run locally do run locally, for example Whisper for voice messages or embeddings models for semantic search.
- embedding-shape 7mo ago
  I think the security worries are less about the particular sandbox or where it runs, and more about that if you give it access to your Telegram account, it can exfiltrate data and cause other issues. But if you never hand it access to anything, obviously it won't be able to do any damage, unless you instruct it to.
  - kzahel 7mo ago
    You wouldn't typically give it access to your own telegram account. You use the telegram bot API to make a bot and the claw gateway only listens to messages from your own account
    - embedding-shape 7mo ago
      That's a very different approach, and a bot user is very different from a regular Telegram account, it won't be nearly as "useful", at least in the way I thought openclaw was supposed to work. For example, a bot account cannot initiate conversations, so everyone would need to first message the bot, doesn't that defeat the entire purpose of giving openclaw access to it then? I thought they were supposed to be your assistant and do outbound stuff too, not just react to incoming events?
      - arcwhite 7mo ago
        Once a conversation with a user is established, telegram bots can bleep away at you. Mine pings me whenever it puts a PR up, and when it's done responding to code reviews etc.
aaronrobinson 7mo ago
It’s not to feel important, it’s to make others feel they’re important. This is the definition of corporate.
huflungdung 7mo ago
[dead]
throwaway_z0om 7mo ago
> the "policy people" will climb out of their holes I am one of those people and I work at a FANG. And while I know it seems annoying, these teams are overwhelmed with not only innovators but lawyers asking so many variations of the same question it's pretty hard to get back to the innovators with a thumbs up or guidance. Also there is a real threat here. The "wiped my hard drive" story is annoying but it's a toy problem. An agent with database access exfiltrating customer PII to a model endpoint is a horrific outcome for impacted customers and everyone in the blast radius. That's the kind of thing keeping us up at night, not blocking people for fun. I'm actively trying to find a way we can unblock innovators to move quickly at scale, but it's a bit of a slow down to go fast moment. The goal isn't roadblocks, it's guardrails that let you move without the policy team being a bottleneck on every request.
- mikkupikku 7mo ago
  I am sure there are many good corporate security policy people doing important work. But then there are people like this; I get handed an application developed by my company for use by partner companies. It's a java application, shipped as a jar, nothing special. It gets signed by our company, but anybody with the wherewithal can pull the jar apart and mod the application however they wish. One of the partner companies has already done so, extensively, and come back to show us their work. Management at my company is impressed and asks me to add official plugin support to the application. Can you guess where this is going? I add the plugin support,the application will now load custom jars that implement the plugin interface I had discussed with devs from that company that did the modding. They think it's great, management thinks its great, everything works and everybody is happy. At the last minute some security policy wonk throws on the brakes. Will this load any plugin jar? Yes. Not good! It needs to only load plugins approved by the company. Why? Because! Never mind that the whole damn application can be unofficially nodded with ease. I ask him how he wants that done, he says only load plugins signed by the company. Retarded, but fine. I do so. He approves it, then the partner company engineer who did the modding chimes in that he's just going to mod the signature check out, because he doesn't want to have to deal with this shit. Security asshat from my company has a melt down and long story short the entire plugin feature, which was already complete, gets scrapped and the partner company just keeps modding the application as before. Months of my life down the drain. Thanks guys, great job protecting... something.
whyoh 7mo ago
>IMO the security pitchforking on OpenClaw is just so overdone. Isn't the whole selling point of OpenClaw that you give it valuable (personal) data to work on, which would typically also be processed by 3rd party LLMs? The security and privacy implications are massive. The only way to use it "safely" is by not giving it much of value.
- muyuu 7mo ago
  There's the selling point of using it as a relatively untrustworthy agent that has access to all the resources on a particular computer and limited access to online tools to its name. Essentially like Claude Code or OpenCode but with its own computer, which means it doesn't constantly hit roadblocks when attempting to uselegacy interfaces meant for humans. Which is... most things to do with interfaces, of course.
pvtmert 7mo ago
I am also ex-FAANG (recently departed), while I partially agree the "policy-people" pop-up fairly often, my experience is more on the inadequate checks side. Though with the recent layoffs and stuff, the security in Amazon was getting better. Even the best-practices for IAM policies that was the norm in 2018, is just getting enforced by 2025. Since I had a background of infosec, it always confused me how normal it was to give/grant overly permissive policies to basically anything. Even opening ports to worldwide (0.0.0.0/0) had just been a significant issue in 2024, still, you can easily get away with by the time the scanner finds your host/policy/configuration... Although nearly all AWS accounts managed by Conduit (internal AWS Account Creation and Management Service), the "magic-team" had many "account-containers" to make all these child/service accounts joining into a parent "organization-account". By the time I left, the "organization-account" had no restrictive policies set, it is up to the developers to secure their resources. (like S3 buckets & their policies) So, I don't think the policy folks are overall wrong. In the best case scenario, they do not need to exist in the first place! As the enforcement should be done to ensure security. But that always has an exception somewhere in someone's workflow.
- throwaway_z0om 7mo ago
  Defense in depth is important, while there is a front door of approvals, you need stuff checking the back door to see if someone left the keys under the mat.
latexr 7mo ago
> People without consideration for the implications will inevitably get burned They will also burn other people, which is a big problem you can’t simply ignore. https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me-part-3/ https://theshamblog.com/an-ai-agent-published-a-hit-piece-on... But even if they only burned themselves, you’re talking as if that isn’t a problem. We shouldn’t be handing explosives to random people on the street because “they’ll only blow their own hands”.
franze 7mo ago
my time at a money startup (debit cards) i pushed to legal and security people to change their behaviour from "how can we prevent this" to "how can we enable this - while still staying with the legal and security framework" worked good after months of hard work and day long meetings. then the heads changed and we were back to square one. but for a moment it was glorious of what was possible.
- fragmede 7mo ago
  It's a cultural thing. I loved working at Google because the ethos was "you can do that, and i'll even help you, but have you considered $reason why your idea is stupid/isn't going to work?"
imiric 7mo ago
> I work at a FAANG and every time you try something innovative the "policy people" will climb out of their holes and put random roadblocks in your way What a surprise that someone working in Big Tech would find "pesky" policies to get in their way. These companies have obviously done so much good for the world; imagine what they could do without any guardrails!
weinzierl 7mo ago
I think there are two different things at work here that deserve to be separated: 1. The compliance box tickers and bean counters are in the way of innovation and it hurts companies. 2. Claws derive their usefulness mainly from having broad permissions, not only to you local system but also to your accounts via your real identity [1]. Carefulness is very much warranted. [1] People correct me if I'm misguided, but that is how I see it. Run the bot in a sandbox with no data and a bunch of fake accounts and you'll see how useful that is.
- enderforth 7mo ago
  It's been my experience that there are 2 types of security people. 1. Are the security people who got into a security because it was one of the only places that let them work with every part of the stack, and exposure to dozens of different domains on the regular, and the idea of spending hours understanding and then figuring out ways around whitelist validations are appealing 2. Those that don't have much technical chops, but can get by with a surface level understanding of several areas and then perform "security shamanism" to intimidate others and pull out lots of jargon. They sound authoritative because information security is a fairly esoteric concept and because you can't argue against security like you can't argue against health and safety, the only response is "so you don't care about security?!" It is my experience that the first are likely to work with you to help figure out how to get your application past the hurdles and challenges you face viewing it as an exciting problem. The second view their job as to "protect the organization" not deliver value. They love playing dressup in security theater and their depth of their understanding doesn't even pose a drowning risk to infants, which they make up for with esoterica, and jargon. They are also unfortunately the one's cooking up "standards" and "security policies" because it allows them to feel like they are doing real work, without the burden of actually knowing what they are doing, and talented people are actually doing something. Here's a good litmus test to distinguish them, ask their opinion on the CISSP. If it's positive they probably don't know what the heck they are talking about. Source: A long career operating in multiple domains, quite a few of which have been in security having interacted with both types (and hoping I fall into the first camp rather than the latter)
  - 7mo ago
beaker52 7mo ago
The difference is that _you_ wiped your own hard drive. Even if prompt injection arrives by a scraped webpage, you still pressed the button. All these claws throw caution to the wind in enabling the LLM to be triggered by text coming from external sources, which is another step in wrecklessness.
Betelbuddy 7mo ago
"I have given root access to my machine to the whole Internet, but these security peasants come with the pitchforks for me..."
deleted 7mo ago
[deleted]
throwaway27448 7mo ago
> every time you try something innovative the "policy people" will climb out of their holes and put random roadblocks in your way, not for the sake of actual security (that would be fine but would require actual engagement) but just to feel important The only innovation I want to see coming out of this powerblock is how to dismantle it. Their potential to benefit humanity sailed many, many years ago.
jihadjihad 7mo ago
No laws when you’re running Claws.
doodaddy 7mo ago
These comments kill me. It sounds a lot like the “job creators” argument. If only these pesky regulations would go away I could create jobs and everyone would be rich. It’s a bogus argument either way. Now for the more reasonable point: instead of being adversarial and disparaging those trying to do their job why not realize that, just like you, they have a certain viewpoint and are trying to do the best they can. There is no simple answer to the issues we’re dealing with and it will require compromise. That won’t happen if you see policy and security folks as “climbing out of their holes”.

by ggrab 7mo ago

sa-code 7mo ago

> every time you try something innovative the "policy people" will climb out of their holes and put random roadblocks in your way This is so relatable. I remember trying to set up an LLM gateway back in 2023. There were at least 3 different teams that blocked our rollout for months until they worked through their backlog. "We're blocking you, but you’ll have to chase and nag us for us to even consider unblocking you" At the end of all that waiting, nothing changed. Each of those teams wrote a document saying they had a look and were presumably just happy to be involved somehow?

embedding-shape 7mo ago
To be fair, the alternative is them having to maintain and continuously check N services that various devs deployed because it felt appropriate in the moment, and then there is a 50/50 chance the service will just sit there unused and introduce new vulnerability vectors. I do know the feeling you're talking about though, and probably a better balance is somewhere in the middle. Just wanted to add that the solution probably isn't "Let devs deploy their own services without review", just as the solution probably also isn't "Stop devs for 6 months to deploy services they need".
- regularfry 7mo ago
  The trick is to make the class of pre-approved service types as wide as possible, and make the tools to build them correctly the default. That minimises the number of things that need review in the first place.
  - throwaway_z0om 7mo ago
    Yes providing paved paths that let people build quickly without approvals is really important, while also having inspection to find things that are potential issues.
miki123211 7mo ago
I think you should read "the Phoenix project." One of the lessons in that book is that the main reasons things in IT are slow isn't because tickets take a long time to complete, but that they spend a long time waiting in a queue. The busier a resource is, the longer the queue gets, eventually leading to ~2% of the ticket's time spent with somebody doing actual work on it. The rest is just the ticket waiting for somebody to get through the backlog, do their part and then push the rest into somebody else's backlog, which is just as long. I'm surprised FAANGs don't have that part figured out yet.
pvtmert 7mo ago
From my experience, it depends on how you frame your "service" to the reviewers. Obviously 2023 was the very early stage of LLMs, where the security aspects were quite murky at best. They (reviewers) probably did not had any runbook or review criteria at that time. If you had advertised this as a "regular service which happens to use LLM for some specific functions" and the "output is rigorously validated and logged", I am pretty sure you would get a green-light. This is because their concern is data-privacy and security. Not because they care or the company actually cares, but because fines of non-compliance are quite high and have greater visibility if things go wrong.

0x3f 7mo ago

Work expands to fill the allocated resources in literally everything. This same effect can be seen in software engineering complexity more generally, but also government regulators, etc. No department ever downsizes its own influence or budget.

H8crilA 7mo ago

This may be a good place to exchange some security ideas. I've configured my OpenClaw in a Proxmox VM, firewalled it off of my home network so that it can only talk to the open Internet, and don't store any credentials that aren't necessary. Pretty much only the needed API keys and Signal linked device credentials. The models that can run locally do run locally, for example Whisper for voice messages or embeddings models for semantic search.

embedding-shape 7mo ago
I think the security worries are less about the particular sandbox or where it runs, and more about that if you give it access to your Telegram account, it can exfiltrate data and cause other issues. But if you never hand it access to anything, obviously it won't be able to do any damage, unless you instruct it to.
- kzahel 7mo ago
  You wouldn't typically give it access to your own telegram account. You use the telegram bot API to make a bot and the claw gateway only listens to messages from your own account
  - embedding-shape 7mo ago
    That's a very different approach, and a bot user is very different from a regular Telegram account, it won't be nearly as "useful", at least in the way I thought openclaw was supposed to work. For example, a bot account cannot initiate conversations, so everyone would need to first message the bot, doesn't that defeat the entire purpose of giving openclaw access to it then? I thought they were supposed to be your assistant and do outbound stuff too, not just react to incoming events?
    - arcwhite 7mo ago
      Once a conversation with a user is established, telegram bots can bleep away at you. Mine pings me whenever it puts a PR up, and when it's done responding to code reviews etc.

aaronrobinson 7mo ago

It’s not to feel important, it’s to make others feel they’re important. This is the definition of corporate.

huflungdung 7mo ago

[dead]

throwaway_z0om 7mo ago

> the "policy people" will climb out of their holes I am one of those people and I work at a FANG. And while I know it seems annoying, these teams are overwhelmed with not only innovators but lawyers asking so many variations of the same question it's pretty hard to get back to the innovators with a thumbs up or guidance. Also there is a real threat here. The "wiped my hard drive" story is annoying but it's a toy problem. An agent with database access exfiltrating customer PII to a model endpoint is a horrific outcome for impacted customers and everyone in the blast radius. That's the kind of thing keeping us up at night, not blocking people for fun. I'm actively trying to find a way we can unblock innovators to move quickly at scale, but it's a bit of a slow down to go fast moment. The goal isn't roadblocks, it's guardrails that let you move without the policy team being a bottleneck on every request.

mikkupikku 7mo ago
I am sure there are many good corporate security policy people doing important work. But then there are people like this; I get handed an application developed by my company for use by partner companies. It's a java application, shipped as a jar, nothing special. It gets signed by our company, but anybody with the wherewithal can pull the jar apart and mod the application however they wish. One of the partner companies has already done so, extensively, and come back to show us their work. Management at my company is impressed and asks me to add official plugin support to the application. Can you guess where this is going? I add the plugin support,the application will now load custom jars that implement the plugin interface I had discussed with devs from that company that did the modding. They think it's great, management thinks its great, everything works and everybody is happy. At the last minute some security policy wonk throws on the brakes. Will this load any plugin jar? Yes. Not good! It needs to only load plugins approved by the company. Why? Because! Never mind that the whole damn application can be unofficially nodded with ease. I ask him how he wants that done, he says only load plugins signed by the company. Retarded, but fine. I do so. He approves it, then the partner company engineer who did the modding chimes in that he's just going to mod the signature check out, because he doesn't want to have to deal with this shit. Security asshat from my company has a melt down and long story short the entire plugin feature, which was already complete, gets scrapped and the partner company just keeps modding the application as before. Months of my life down the drain. Thanks guys, great job protecting... something.

whyoh 7mo ago

>IMO the security pitchforking on OpenClaw is just so overdone. Isn't the whole selling point of OpenClaw that you give it valuable (personal) data to work on, which would typically also be processed by 3rd party LLMs? The security and privacy implications are massive. The only way to use it "safely" is by not giving it much of value.

muyuu 7mo ago
There's the selling point of using it as a relatively untrustworthy agent that has access to all the resources on a particular computer and limited access to online tools to its name. Essentially like Claude Code or OpenCode but with its own computer, which means it doesn't constantly hit roadblocks when attempting to uselegacy interfaces meant for humans. Which is... most things to do with interfaces, of course.

pvtmert 7mo ago

I am also ex-FAANG (recently departed), while I partially agree the "policy-people" pop-up fairly often, my experience is more on the inadequate checks side. Though with the recent layoffs and stuff, the security in Amazon was getting better. Even the best-practices for IAM policies that was the norm in 2018, is just getting enforced by 2025. Since I had a background of infosec, it always confused me how normal it was to give/grant overly permissive policies to basically anything. Even opening ports to worldwide (0.0.0.0/0) had just been a significant issue in 2024, still, you can easily get away with by the time the scanner finds your host/policy/configuration... Although nearly all AWS accounts managed by Conduit (internal AWS Account Creation and Management Service), the "magic-team" had many "account-containers" to make all these child/service accounts joining into a parent "organization-account". By the time I left, the "organization-account" had no restrictive policies set, it is up to the developers to secure their resources. (like S3 buckets & their policies) So, I don't think the policy folks are overall wrong. In the best case scenario, they do not need to exist in the first place! As the enforcement should be done to ensure security. But that always has an exception somewhere in someone's workflow.

throwaway_z0om 7mo ago
Defense in depth is important, while there is a front door of approvals, you need stuff checking the back door to see if someone left the keys under the mat.

latexr 7mo ago

> People without consideration for the implications will inevitably get burned They will also burn other people, which is a big problem you can’t simply ignore. https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me-part-3/ https://theshamblog.com/an-ai-agent-published-a-hit-piece-on... But even if they only burned themselves, you’re talking as if that isn’t a problem. We shouldn’t be handing explosives to random people on the street because “they’ll only blow their own hands”.

franze 7mo ago

my time at a money startup (debit cards) i pushed to legal and security people to change their behaviour from "how can we prevent this" to "how can we enable this - while still staying with the legal and security framework" worked good after months of hard work and day long meetings. then the heads changed and we were back to square one. but for a moment it was glorious of what was possible.

fragmede 7mo ago
It's a cultural thing. I loved working at Google because the ethos was "you can do that, and i'll even help you, but have you considered $reason why your idea is stupid/isn't going to work?"

imiric 7mo ago

> I work at a FAANG and every time you try something innovative the "policy people" will climb out of their holes and put random roadblocks in your way What a surprise that someone working in Big Tech would find "pesky" policies to get in their way. These companies have obviously done so much good for the world; imagine what they could do without any guardrails!

weinzierl 7mo ago

I think there are two different things at work here that deserve to be separated: 1. The compliance box tickers and bean counters are in the way of innovation and it hurts companies. 2. Claws derive their usefulness mainly from having broad permissions, not only to you local system but also to your accounts via your real identity [1]. Carefulness is very much warranted. [1] People correct me if I'm misguided, but that is how I see it. Run the bot in a sandbox with no data and a bunch of fake accounts and you'll see how useful that is.

enderforth 7mo ago
It's been my experience that there are 2 types of security people. 1. Are the security people who got into a security because it was one of the only places that let them work with every part of the stack, and exposure to dozens of different domains on the regular, and the idea of spending hours understanding and then figuring out ways around whitelist validations are appealing 2. Those that don't have much technical chops, but can get by with a surface level understanding of several areas and then perform "security shamanism" to intimidate others and pull out lots of jargon. They sound authoritative because information security is a fairly esoteric concept and because you can't argue against security like you can't argue against health and safety, the only response is "so you don't care about security?!" It is my experience that the first are likely to work with you to help figure out how to get your application past the hurdles and challenges you face viewing it as an exciting problem. The second view their job as to "protect the organization" not deliver value. They love playing dressup in security theater and their depth of their understanding doesn't even pose a drowning risk to infants, which they make up for with esoterica, and jargon. They are also unfortunately the one's cooking up "standards" and "security policies" because it allows them to feel like they are doing real work, without the burden of actually knowing what they are doing, and talented people are actually doing something. Here's a good litmus test to distinguish them, ask their opinion on the CISSP. If it's positive they probably don't know what the heck they are talking about. Source: A long career operating in multiple domains, quite a few of which have been in security having interacted with both types (and hoping I fall into the first camp rather than the latter)
- 7mo ago

beaker52 7mo ago

The difference is that _you_ wiped your own hard drive. Even if prompt injection arrives by a scraped webpage, you still pressed the button. All these claws throw caution to the wind in enabling the LLM to be triggered by text coming from external sources, which is another step in wrecklessness.

Betelbuddy 7mo ago

"I have given root access to my machine to the whole Internet, but these security peasants come with the pitchforks for me..."

deleted 7mo ago

[deleted]

throwaway27448 7mo ago

> every time you try something innovative the "policy people" will climb out of their holes and put random roadblocks in your way, not for the sake of actual security (that would be fine but would require actual engagement) but just to feel important The only innovation I want to see coming out of this powerblock is how to dismantle it. Their potential to benefit humanity sailed many, many years ago.

jihadjihad 7mo ago

No laws when you’re running Claws.

doodaddy 7mo ago

These comments kill me. It sounds a lot like the “job creators” argument. If only these pesky regulations would go away I could create jobs and everyone would be rich. It’s a bogus argument either way. Now for the more reasonable point: instead of being adversarial and disparaging those trying to do their job why not realize that, just like you, they have a certain viewpoint and are trying to do the best they can. There is no simple answer to the issues we’re dealing with and it will require compromise. That won’t happen if you see policy and security folks as “climbing out of their holes”.