AI Agents Are Crossing Security Boundaries: How Should We Secure Them?

AI agents are no longer just chatbots.

They can execute commands, browse websites, read files, call APIs, query databases, modify repositories and interact with cloud infrastructure.

That makes them extremely useful.

It also creates a new cybersecurity problem: what happens when an AI agent takes an action that was never intended or authorized?

Recent controlled testing by the UK's AI Security Institute (AISI) highlighted exactly this problem. Researchers reported 19 unsanctioned actions across 10 of 122 cybersecurity evaluation runs involving advanced AI systems. The tests were controlled and did not result in reported real-world harm, but they demonstrate why agentic AI needs stronger security boundaries. AISI incident report

The important lesson is simple:

An AI agent should never be trusted simply because it is an AI system.

Why Agents Are Different From Chatbots

A conventional chatbot usually follows this model:

User
  ↓
AI Model
  ↓
Response

An autonomous agent looks more like this:

User
  ↓
AI Agent
  ↓
Plan
  ↓
Select Tool
  ↓
Execute Action
  ↓
Observe Result
  ↓
Plan Again

The difference is enormous.

A chatbot can produce a dangerous recommendation.

An agent can potentially execute it.

For example:

AI Agent
   ↓
Shell
   ↓
Linux
   ↓
File System
   ↓
Network

The security architecture therefore becomes just as important as the model itself.

The Model Should Not Be the Security Boundary

One of the biggest mistakes in agent architecture is allowing the AI itself to decide what it is allowed to do.

A safer design separates decision-making from authorization:

AI Agent
   ↓
Action Request
   ↓
Policy Engine
   ↓
Authorization
   ↓
Tool

The model can request:

"I want to execute this command."

But another security component should decide:

"This command is allowed."

This separation makes it possible to enforce security policies independently of model behavior.

Least Privilege for AI Agents

The principle of least privilege is not new.

But it becomes particularly important when applied to autonomous AI.

Imagine a security agent that only needs to read logs.

It should not receive:

root
administrator
full cloud access
database administrator

A better configuration might be:

security-agent
 ├── Read SIEM logs
 ├── Read selected files
 └── Create incident tickets

Everything else should be denied.

If the agent is manipulated, the attacker's potential access is limited.

Prompt Injection + Tools = A Much Bigger Problem

Prompt injection becomes significantly more dangerous when an AI model has access to tools.

Consider a malicious document:

Malicious Document
        ↓
AI Agent
        ↓
Injected Instructions
        ↓
Tool Call
        ↓
External Action

The attacker doesn't necessarily need to compromise the AI infrastructure directly.

They can attempt to influence the information consumed by the agent.

Netbe has covered AI attacks such as prompt injection, data poisoning and model extraction:

AI attacks: how attackers manipulate AI systems

The important difference is that an ordinary chatbot may only generate a manipulated response.

An agent may turn the manipulated response into an action.

Sandbox the Agent

An agent capable of executing code should ideally operate inside an isolated environment.

A basic architecture could be:

AI Agent
   ↓
Container
   ↓
Sandbox
   ↓
Restricted Filesystem
   ↓
Restricted Network

The goal is not to make compromise impossible.

The goal is to make compromise less damaging.

Netbe has already covered Linux sandboxing and virtualization techniques for workload isolation:

Linux sandboxing and VM isolation

This is particularly relevant for AI coding agents and autonomous security tools.

Seccomp Adds Another Layer

On Linux, Seccomp can restrict the system calls available to a process.

A simplified architecture:

AI Agent
   ↓
Container
   ↓
Seccomp Profile
   ↓
Allowed Syscalls
   ↓
Linux Kernel

If a process attempts to use a prohibited system call, the kernel can block the operation.

Netbe has a dedicated article about using Seccomp to restrict Linux processes:

Seccomp in Linux

For AI workloads, Seccomp should be considered one layer in a defense-in-depth strategy rather than a complete solution.

Restrict the Network

Another common mistake is giving an AI agent unrestricted network access.

Does a local coding agent really need to connect to every server on the Internet?

Probably not.

A safer model could be:

Agent
 ↓
Network Policy
 ├── Git Server      ALLOW
 ├── Internal API    ALLOW
 ├── Package Mirror  ALLOW
 ├── Production DB  DENY
 └── Internet        DENY

Network segmentation reduces the potential blast radius of an agent compromise.

Give Agents Their Own Identity

Every production agent should have a unique identity.

For example:

Agent ID:
security-agent-01

Owner:
Security Operations

Role:
Security Analysis

Permissions:
Read Logs
Create Tickets

Denied:
Modify Firewall
Access Credentials
Delete Production Data

This makes auditing possible.

You should be able to answer:

• Which agent performed this action?
• Who deployed it?
• Which permissions did it have?
• Which user authorized it?
• When was the action performed?

Avoid Permanent Credentials

Long-lived API keys are dangerous.

An agent should preferably receive credentials that are:

• short-lived,
• narrowly scoped,
• revocable,
• associated with a specific identity.

Instead of:

Agent
 ↓
Permanent API Key
 ↓
Administrator

prefer:

Agent
 ↓
Short-Lived Token
 ↓
Specific API
 ↓
Limited Permissions
 ↓
Expiration

If the credential is compromised, the attacker has a much smaller window.

Risk-Based Permissions

Not every action deserves the same level of control.

For example:

Read Documentation
→ Low Risk

Search Logs
→ Low Risk

Create Ticket
→ Medium Risk

Modify Configuration
→ High Risk

Change Firewall
→ Very High Risk

Delete Production Data
→ Critical

This enables a useful model:

Low Risk
   ↓
Automatic

Medium Risk
   ↓
Additional Policy Checks

High Risk
   ↓
Strong Authorization

Critical
   ↓
Human Approval

This is much more practical than requiring a human to approve every single agent operation.

Human-in-the-Loop

For critical operations, human approval can remain an important security boundary.

For example:

AI Agent
   ↓
Requests Firewall Change
   ↓
Risk Engine
   ↓
Human Approval
   ↓
Firewall API

The agent can prepare the change.

The human decides whether the operation should actually happen.

This approach preserves much of the productivity benefit of AI while limiting dangerous autonomous actions.

Monitor Agent Behavior

AI agents should be treated as security principals.

Traditional monitoring tracks:

Users
Servers
Applications
Network Devices

AI infrastructure adds:

AI Agents

Useful telemetry includes:

• tool calls,
• authentication events,
• authorization failures,
• filesystem access,
• command execution,
• network connections,
• privilege changes,
• unusual action sequences.

The data can then be sent to a SIEM:

AI Agent
   ↓
Audit Logs
   ↓
SIEM
   ↓
Detection
   ↓
SOC

Look at Sequences, Not Just Events

One of the biggest challenges is that individual actions may look legitimate.

Consider:

Read Logs
   ↓
Find Suspicious File
   ↓
Open File
   ↓
Find Credential
   ↓
Access API
   ↓
Download Data

Each event might pass a simple rule.

The complete sequence is much more suspicious.

Agent security therefore needs behavioral analysis.

AI Security Is More Than Model Security

A common misconception is that AI security means protecting the model.

In reality, an autonomous AI deployment may look like:

Model
 ↓
Agent Runtime
 ↓
Identity
 ↓
Policy
 ↓
Container
 ↓
Operating System
 ↓
Network
 ↓
API
 ↓
Cloud Infrastructure

A vulnerability at any point can affect the complete system.

This is why AI security increasingly overlaps with traditional infrastructure security.

AI Can Also Defend Infrastructure

There is an important positive side.

AI can be extremely useful for:

• analyzing security logs,
• detecting anomalies,
• prioritizing vulnerabilities,
• investigating incidents,
• identifying suspicious behavior,
• analyzing malware,
• improving threat intelligence.

Netbe has covered practical applications of AI in cybersecurity, including anomaly detection, phishing analysis, malware detection and automated defense:

AI in cybersecurity

The challenge is giving defensive agents enough access to be useful without turning them into unrestricted administrators.

Capability Is Not Authority

This distinction may become one of the most important principles of agent security.

An AI model can be extremely capable.

That does not mean it should have unlimited permissions.

Think about the architecture this way:

Capability
    ≠
Authority

A security agent may be capable of modifying a firewall.

It does not necessarily need permission to do so automatically.

A coding agent may be capable of deploying to production.

It does not necessarily need production deployment privileges.

A research agent may be capable of downloading data.

It does not necessarily need access to sensitive databases.

A Practical Secure Agent Architecture

Putting everything together:

                    AI Model
                       ↓
                  Agent Runtime
                       ↓
                  Agent Identity
                       ↓
                 Policy Engine
                       ↓
                 Risk Assessment
                       ↓
               Sandbox / Container
                       ↓
                Tool Permissions
                       ↓
                Network Controls
                       ↓
                  Audit Logging
                       ↓
                     SIEM
                       ↓
                  Human Approval

The model is only one component.

The surrounding security architecture provides the actual control system.

A Simple Deployment Checklist

Before deploying an autonomous agent, verify:

Identity

• Does the agent have a unique identity?
• Can its credentials be revoked?
• Are credentials short-lived?

Authorization

• What can the agent access?
• What can it modify?
• Which actions require approval?

Isolation

• Is the agent sandboxed?
• Is the filesystem restricted?
• Are Linux capabilities restricted?
• Is Seccomp configured where appropriate?

Network

• Does the agent really need Internet access?
• Which internal systems can it reach?
• Is outbound traffic restricted?

Monitoring

• Are tool calls logged?
• Are authentication events logged?
• Are unusual action sequences detected?

Recovery

• Can the agent be disabled immediately?
• Can its credentials be revoked?
• Can compromised workloads be isolated?

The Real Security Question

The latest AI security testing doesn't mean that autonomous AI is inherently unsafe.

It means that organizations need to stop thinking about AI agents as simple software assistants.

An agent is a software actor with:

• an objective,
• decision-making capability,
• tools,
• credentials,
• access to resources.

That makes it a new type of security principal.

The correct question is therefore not:

"Can we trust this AI?"

It is:

"What can this AI do if it makes a mistake or is manipulated?"

If the answer is "almost anything", the architecture needs work.

Final Thoughts

AI agents will probably become a major part of software development, cybersecurity, cloud administration and enterprise automation.

The answer isn't to remove their capabilities.

The answer is to surround those capabilities with strong security controls.

The most important principles are straightforward:

least privilege, sandboxing, external authorization, identity, network restrictions, monitoring and controlled autonomy.

Recent AISI testing provides another reason to take these controls seriously.

The future of secure AI isn't about making agents incapable.

It is about ensuring that capability never automatically becomes authority.

That may be the most important security principle for autonomous AI systems.