I know it’s what the security folk think about, exfiltrating to a model endpoint is the least of my concerns.

I work on commercial OSS. My fear is that it’s exfiltrated to public issues or code. It helpfully commits secrets or other BS like that. And that’s even ignoring prompt injection attacks from the public.

> I'm actively trying to find a way we can unblock innovators to move quickly at scale

So did "Move fast and break things" not work out? /i

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.

The main problem with many IT and security people at many tech companies is that they communicate in a way that betrays their belief that they are superior to their colleagues.

"unlock innovators" is a very mild example; perhaps you shouldn't be a jailor in your metaphors?

I was worried about the security risk of running it on my infrastructure, so I made my own:

https://github.com/skorokithakis/stavrobot

At least I can run this whenever, and it's all entirely sandboxed, with an architecture that still means I get the features. I even have some security tradeoffs like "you can ask the bot to configure plugin secrets for convenience, or you can do it yourself so it can never see them".

You're not going to be able to prevent the bot from exfiltrating stuff, but at least you can make sure it can't mess with its permissions and give itself more privileges.

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.

If you're really into optimizing:

You don't need to store any credentials at all (aside from your provider key, unless you want to mod pi).

Your claw also shouldn't be able to talk to the open internet, it should be on a VPN with a filtering proxy and a webhook relay.

Genuinely curious, what are you doing with OpenClaw that genuinely improves your life?

The security concerns are valid, I can get anyone running one of these agents on their email inbox to dump a bunch of privileged information with a single email..

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.

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.

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.

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".

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.

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)

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?"