Many are scared of the potential harm and security problems Agentic AI can cause to our systems. Today I will teach you the basics and fundamentals of how to protect your computers and servers from this emerging threat.

We have all been hyped a lot about AI. We sometimes treat it as an all-powerful agent with almighty powers that can go in and out of computer systems like a true hacker and do whatever it likes.

Nothing is further from the truth. AI is, in essence, just a sophisticated I/O machine. Its true name, behind the marketing, is LLM: Large Language Model. It's a series of mathematical permutations chained together in a specific array in such a way that you give the LLM a string, and it outputs a string. That's all, it's a string conversion function in the end. It's really cool, right? But that's what it is.

Where we start blurring the line between an LLM and AI is when we connect this LLM to an agentic framework. Now things change. We suddenly wrap the I/O machine that is the LLM into a program that reads the LLM output, writes it to a file, and then tries to execute that file on behalf of the user.

Do you see the problem here? The risk lies in giving a program READ, WRITE, and EXECUTE rights on an unsanitized, non-deterministic output. And that's where we are opening Pandora's box.

Imagine for a second we remove the EXECUTE permission from that program. The program would read a file, send the string to the LLM, get a response back, and write it to a file. That's all. Worst-case scenario? We run out of disk storage to write files.

So as you see, the number one key to AI security is getting rid of the EXECUTE permissions. If we want to get technical, this is just applying the principle of least privilege. And honestly, the absolute least privilege for an AI is simply: do not allow it to execute.

The reason why people are forgetting about this basic security principle is because marketing and hype are blinding us to how to use the tools properly. We have all heard about Openclaw, the very famous agentic framework that's plagued by security flaws. Since Openclaw has execute permissions and is full of user credential access, it's a security nightmare.

We are connecting an LLM to our terminals with R/W/E (Read/Write/Execute) permissions. You might as well just give it sudo permission, right? Well, surprise, it doesn't need sudo to be sudo. It just needs to craft a single exploit for privilege escalation and then execute it. Since you gave it execute permissions, it can run a privilege escalation exploit to be sudo. See the problem here? The problem is the execute function.

We are amazed to see an AI doing automated work. CEOs and the mainstream want these systems to act like humans, to be able to do R/W/E on their computers, in their systems.

Core Architecture: The System Calls the LLM, Never the Reverse

If you want a secure AI implementation, lock down your architecture with one hard boundary: The system executes and consults the LLM. The LLM never dictates execution.

We have all been lectured on prompt injection attacks and how unsanitized input is risky for our AI implementations. But in my opinion, prompt injection is just half of the story. We have to focus on the outputs far more than we focus on the inputs.

How we handle the output is ultimately more important, because the LLM is just an I/O machine — an input simply generates an output. If we sanitize, isolate, and strictly restrict the output capabilities, the input doesn't really matter. You can prompt inject my LLM all day long; if my outputs are sent straight to /dev/null, you are never going to get RCE (Remote Code Execution) on my system.

To enforce this isolation when integrating an LLM into your business logic, apply this strict permission matrix: Can it read? Yes. Can it write? Yes. Can it delete? No. Can it execute? No.

By following those basic principles, you are reducing your attack surface. This doesn't mean you are unhackable, but you are way more secure than most AI users out there.

That brings us to the next vulnerability: downstream execution. Your LLM output should never be fed into execution logic in another script (daisy-chain attacks are a serious security vector here). Make sure the LLM output remains strictly READ-ONLY during the entire chain. Yes, depending on your business logic, you might want to query a database full of LLM outputs, but beware: that can easily lead to SQL Injection because you are handling unsanitized data. Always sanitize the LLM output before processing any of it, even if you do not directly execute it.

So in order to make the tool fundamentally secure, follow this rule of thumb: Treat LLM output as if it were external inputs coming from the wild web. Run it through a WAF, sanitize the inputs, take every single LLM output as if it were potentially malicious inputs coming from a form in the open internet.

Risks Outside Your Control

Not everything is as smooth as it sounds. So far, we have talked about how to prevent AI from hacking your system using your own permissions. That's very important — you don't want to give your AI permission to hack you. The other problem comes when an AI without permission tries to hack us.

That's not an internal threat anymore. It's external. Someone with an AI could be crafting exploits at lightning speed and executing all of them against our public-facing web server, or against our Wi-Fi network. That's where things get more dangerous. It's outside our control, so let's see what we can do about it:

Always keep your system up to date

This is classic advice. Always keep your system up to date. Most exploitable servers are compromised not because of 0-day vulnerabilities, but because they are unpatched and very common exploits still work on them. By updating your system, you remain protected.

Be wired when possible

Wi-Fi is just a massive security risk, period. A wired connection is more secure because it's never exposed to the wild.

Reduce your attack surface

Do not expose your endpoints to the public internet when possible. If you have to do it, use a WAF like Cloud Armor and make sure you have a filtering mechanism in place for malicious payloads.

Use LLMs to determine the maliciousness of a payload

LLMs can create malicious payloads, but they can also identify them. You can filter incoming payloads with an LLM to review their maliciousness. Notice: This entire setup is only safe as long as the LLM does not have EXECUTE permissions. Do not forget that.

Use AI-assisted investigations

We can give an LLM READ-ONLY access to our system logs to find potential threats or malicious activity. Since it cannot execute, there's no risk in giving read access only. It can just output to a file whether it found something malicious or not — no need to execute anything.

AI cannot replace all humans

There's a reason why humans will remain critical in every company and IT department. Because LLMs do not have anything to lose if they make a mistake; humans do. That's the ultimate motivation to do good work, to not execute an exploit on a production server, to behave ethically. The potential of losing your job, the fear of jail, and accountability — that is the final security layer. Humans are fearful, and this fear is what keeps systems up to date and working without random exploit executions. The LLM does not have any fear, nor consequences. This makes it dangerous if you give it R/W/E permissions.

Conclusion

This is not a comprehensive end-to-end security strategy for AI — not even close. A well-structured and deep security strategy requires a full overview of the architecture. But this guide covers the absolute fundamentals. It all boils down to the one question I will ask at every single step of the software execution chain:

"Does the LLM have execution rights here? Is the LLM output executed here at any point?"

If the answer is NO, that's a good sign. If the answer is YES, beware: you might be opening Pandora's box in your system, and that is exactly what we want to avoid.