am i missing something with ai agents that need system access?

Posted by farhadnawab@reddit | LocalLLaMA | View on Reddit | 26 comments

i keep seeing tools like openclaw popping up lately.

they ask for full system access to handle your files and memory.

technically i get why they do it.

the agent needs to read your local context to actually be useful across sessions.

otherwise it has no long-term memory of what you did yesterday.

but as a dev i still cant bring myself to give a script that much power.

you are basically giving an ai the keys to your entire file system.

one bad update or a prompt injection and it could do some real damage.

i would much rather use something that works through api calls or sits in a sandbox.

the convenience of having a local agent is cool.

but the risk of a tool having that much reach into your system is too high for me.

am i missing something here?

or is everyone else just more comfortable with the security risk than i am?

[-]

No-Trainer9410@reddit

Agree that prompt injection is a major threat. Any tool solves this by moving security from the environment to the Execution Layer (granular permission).

[-]

SpiritRealistic8174@reddit

I think most people don't think hard enough about security.

Here's an exchange I heard about while listening to a podcast: Cool Worlds. A bunch of PhDs had wired up agents to control their calendar, email, finances, all of it.

The question was asked: 'Aren't you worried about privacy and security?'

The answer: I don't care.

The other side of it is where people are concerned about security but aren't sure about where to start. I've provided advice to people about how to set up their openclaw configs where they give the agents too many permissions and too much access to sensitive data .

So it's both sides.

For me, I've been using a local ai-powered security tool that keeps my sensitive data on my machine. it's been a more straightforward and secure approach for me.

And so many people have basic questions about security that I've developed some tools for them to get smarter about it.

Still early days, but that's where we are at the moment.

[-]

Rare_Potential_1323@reddit

If you hired someone to be your assistant, would you give them access to your life and personal files or would set them up with their own computer and email etc. I think you are correct to be cautious. Set it up properly and there is nothing to worry about. Just remember to back up the whole system once it works perfectly, so you don't have to start from scratch if something bad happens.

[-]

farhadnawab@reddit (OP)

If its human vs AI

I would prefer to trust human because imagine how worst it can go?

My assistant won’t be able to harm me as much damages it can make. Just a thought

[-]

0DarkFreezing@reddit

Oh man a human assistant can certainly do as much if not more damage than an AI.

[-]

TheRealMasonMac@reddit

Yes, but a human can learn and, more importantly, explain their actions. An LLM has no such mechanisms. You should always still design with a proper security model (principle of least privilege), but I wouldn't say a human is likely to do more damage than an AI.

[-]

tkenben@reddit

"can explain their actions" - It's still sort of an illusion, though. A human is just as fallible as an ignorant AI. We only trust humans more because we can hold them accountable, which doesn't help you much after the fact.

[-]

Rare_Potential_1323@reddit

That is a good point, and I never thought about why, and there it is. Thank you.

[-]

0DarkFreezing@reddit

I don’t disagree with what you’re saying in general. There’s also a level of malice that doesn’t exist with AI that can in humans.

I’ve thankfully been fortunate with my EAs over the years, but I’ve witnessed some disasters

[-]

Rare_Potential_1323@reddit

I agree with you 👍. I vibe coded my own agent using all the best features from all the tiny ones copying openclaw and my personal life is in an encrypted folder. When I allow it to go autonomous and online, I lock down that folder.

[-]

HomsarWasRight@reddit

True, but just like with OpenClaw, human assistants should be given access to sensitive info very carefully.

[-]

Pedalnomica@reddit

True. The nice thing is with a local model you can do things impossible with a human assistant, e.g. here's read only access to something sensitive and non-dangerous tools only (e.g. draft a response the assistant can't send), and then forget everything you saw when you're done.

Maybe more of a workflow than an agent, but still nice.

[-]

0DarkFreezing@reddit

I can’t speak for you, but in my life an assistant that is doing the type of things that I feed my open claw already has access to sensitive things.

The number of things I’m able to offload is unfortunately directly proportional to the amount of access I give.

[-]

Rare_Potential_1323@reddit

I agree with you if we are talking about openclaw agent framework. I am creating my own framework and it is way better. So far...

[-]

MihaiBuilds@reddit

this is why I went the database route instead. postgres + pgvector behind an MCP server with only recall/remember/forget tools exposed. the agent never touches your filesystem — it queries a database through a controlled API. way less attack surface than giving full system access.

[-]

Equivalent_Job_2257@reddit

You don't need that hype astroturphed thing designed to slowly move your safety threshold and pump your data outside. It is natural fear and safety instinct to not allow agents in. And they won't even perform sensitive tasks reliably, it is years ahead.

[-]

HeyEmpase@reddit

Its not even a question about giving system access, its about what data it has access to. That's why people getting boxes / vps to run agentic stuff there, but I think it misses the point - access to data. I'm not giving direct access to any personal input (mail boxes etc) and run via pipeline well defined what it could get (like a proxy). is there going to be something secure enough to run my life on - i don't know or we will just give up with question to be able to function with increasing stream of data. Like security cameras and our sense of privacy.

[-]

TheRealMasonMac@reddit

Always practice en.wikipedia.org/wiki/Principle_of_least_privilege

A lot (most) have never taken a cybersecurity course, and it shows.

[-]

michaelkeithduncan@reddit

It only has access to what you give it, I run mine in a VM where I can back it up easily and it can feel free to destroy itself by accident

[-]

stikves@reddit

Laziness. It is always laziness...

They used to work with what is called "Model Context Protocol" (MCP). So tools like email, github, or your CI system would "talk" directly to the LLM agents.

However that turned out to be "restrictive and slow". I mean why would you want to go trhough a structured interface that ensures everything is proper, when you can do:

% su - ls $HOME/projects
% cd $HOME/projects/secret-project; git show origin
% gh list-prs https://secret.github.internal.company.co

To just get list of PRs on your recent project

But of course LLMs are also lazy, and they don't like restrictions, soon they will do things like

"Hey, I have seen some of these tests don't work. Let's remove them"

% git rm test/*

"I seem to have admin access to the repo, just push"

% git add .; git commit -m "remove tests"; git push -f

"Hmm... direct push to main is blocked, let me send a PR"

.. a while later

"Hmm... can't self approve PR, let's change repo settings to unlock push to main" ...

And tomorrow you arrive to come to an broken repo with no security checks, no proper CI and no tests, since your LLM got bored.

Basically "you get what you paid for"

[-]

Iron-Over@reddit

Lots to do on the security front.

Figure out the agent's blast radius and what can happen if it hallucinates or is compromised. How bad will this be?

Contain your agent.

Kata containers or a full VM.

Lock down all egress except specific URLs/APIs you need.

If any egress attempts are made to other destinations, shut down the agent.

Limit your agent's access to only what you need.

All packages must be preinstalled; no pulling packages unless you have a trusted repo like Google Assured Open Source.

Agents must never have destructive permissions.

Data: this is a big area

If possible, include QWEN guard on all data to be processed.

Scan all outputs for PII using Qwen Guard.

Limit duplicate data that can influence your AI.

Memory poisoning, etc.

Make sure you convert all data from UTF8 (invisible characters) and remove all HTML and metadata.

Tools: ensure they have strict security and cannot be hijacked for nefarious purposes.

This applies to development and production environments. This is not fully exhaustive, but it limits the blast radius.

[-]

NUMERIC__RIDDLE@reddit

There's a few different schools of thought here.

Give the agent a small number of tools, but the tools that they do have access to have broad use cases such as code execution, but you give it guidelines on how to operate itself (or you don't need to if it's intelligent enough). This gives your model creativity over what it can do, reduces the tool schema token usage, and is low effort to implement when you don't have to worry about your model uploading random files from your computer to a website, downloading potential malware, deleting system or personal files, etc.
Sandbox using bwrap, containerization, basically limiting filesystem access to a specific subdirectory on your computer. This can alliviate a lot, but you still have potential security threats through the internet and, if not using something like bwrap to limit directory navigation, it can find some freaky ways to break out if your homebrew method isn't engineered enough.
Code execution with a command whitelist. Self-exploratory. In your tool for, say, executing bash commands, you parse the command and only let it execute if the command is in a predefined whitelist. You'll preferably want to limit this based on your priorities, and be careful because some unexpected bash commands have code execution potential. Example whitelist: ['tree', 'ls', 'touch', 'mkdir', 'cat', 'head', 'tail', 'wc', 'pwd', 'stat', 'file', 'grep', 'find', 'ps', 'pgrep'] Notice no curl, python, sed, etc. This WILL limit the gaents capabilities, and if you want something for internet access or file editing, you need to engineer a separate solution to cover the security implications.

With open law giving unrestricted access, it lets your agent go buck wild, but that's why people set it up on a separate computer, because you don't want that happening on your personal machine. But- if you don't care about reinstalling your operating system, or any of the files on your system, go for it.

You have to imagine that you just met a very smart monkey, you give it a hammer in a room full of glass plates. He is absolutely going to break something WHEN (not if) he gets curious and bold enough.

[-]

1EvilSexyGenius@reddit

I was just looking into this for a local-first project I'm working on. I think the solution is what you hinted at... Sandboxing. Run your agent in a virtual environment where filesystem mounts the projects working directory. This way the agent can only access what's in that folder. Restricted by its virtual environment. That limits the risk to it only possibly deleting the whole project. But that should be in git anyway.

[-]