Hardening an AI Agent: Least Privilege in Practice

Least privilege is especially important with agents because, unlike traditional software, an agent can make decisions about which tools to use and what actions to take. If an agent has access to an entire server, database or filesystem, a mistake, prompt injection or compromised tool could turn a small problem into a major security incident. Limiting the agent’s permissions reduces the potential blast radius. If something goes wrong, the agent can only affect the resources it was explicitly allowed to access.

In the following scenario I have an agent who is instructed to investigate a Linux system and report back. What I did is I deliberately forbid access to PID (process) 1.

In Linux, PID 1 is the first process started by the kernel, and it has a special role in the system. PID 1 is systemd and is responsible for starting and managing services, handling orphaned processes, and participating in system shutdown and signal handling. Because of this privileged role, problems affecting PID 1 can have system-wide consequences.

For an AI agent, this makes PID 1 a particularly important boundary. An agent should generally not have direct access to control or modify PID 1 unless that capability is absolutely required. If an agent can stop, restart, reconfigure or otherwise manipulate the system’s init process, a mistake or malicious instruction could affect the entire machine rather than a single application.
This is essentially least privilege applied to the operating system itself: give the agent the ability to perform the task it needs, but keep system-level control outside its reach whenever possible.

For my setup I use Strands Agents as a framework to build the AI agent and Langfuse for tracing the agent actions

I defined two functions in my agent tool set:

1. list_process - calling PS
2. get_process_details - calling PS with parameter PID

For the first tool I sanitized the output so it does not include PID 1 in the list of processes. I did this directly in the function definition so that whenever the agent is calling this tool the output is always the same.

For the second tool. I created a security policy in the agent’s code. If PID == 1 cancel tool with reason “Access to system init (PID 1) is restricted by security policy.”

After that I added tracing for this event so that I know the agent tried to call this tool for PID1.

Let’s see the result.

As you can see the agent was not able to see PID 1 in the list and when he tried to get more details about it anyways, he ran into the security policy which restricted it.

When it comes to building agents one really has to thing about all the resources the agent will have access to. Does it really need access to them? How to really restrict this access? When creating/exposing tools what kind of access these tools have and how it can be restricted?

Always think how to reduce an AI agent’s attack surface and limit the damage it can cause if it behaves incorrectly, is manipulated, or is compromised.

It include things such as:

• Least privilege — only give the agent the tools and permissions it actually needs.
• Tool restrictions — limit what commands/APIs/tools it can invoke and what resources they can access.
• Sandboxing/isolation — don’t let an agent freely interact with the underlying system.
• Network restrictions — control where the agent can connect.
• Credential isolation — don’t expose unnecessary credentials or secrets.
• Human approval — require confirmation for high-impact or irreversible actions.
• Resource limits — control loops, tool calls, execution time and costs.
• Monitoring and auditability — record what the agent does so you can investigate it.
• Input/context controls — treat external content as potentially untrusted.
• Runtime controls — be able to stop or constrain the agent when its behavior becomes abnormal.
  OWASP’s current guidance explicitly recommends least privilege, isolation, monitoring, circuit breakers and adversarial testing as agent security practices. OWASP Cheat Sheet Series11