Security

How to Secure Your AI Agent Infrastructure: A Practical Checklist

Security checklist for AI agent deployments: isolation, networking, secrets, monitoring, and incident response. Actionable steps you can use today.

Oblien Team

2026-02-11•1 min read

How to Secure Your AI Agent Infrastructure: A Practical Checklist

Deploying AI agents introduces security challenges that traditional application security doesn't cover. Agents execute arbitrary code, make autonomous decisions, and interact with sensitive systems based on natural language input you can't fully control.

This isn't a theoretical threat model. It's a practical checklist - things you can audit and implement today to reduce your attack surface and contain potential breaches.

Execution environment

✅ Use hardware isolation, not containers

AI agents run arbitrary code based on LLM output and user input. This code is unpredictable and potentially malicious (via prompt injection).

Each agent should run in its own virtual machine (microVM), not a shared container
A container escape gives attackers access to every other container on the host. A VM escape is orders of magnitude harder
Firecracker microVMs provide VM-level isolation with millisecond boot time

Test: Can your agent's code access processes, files, or network interfaces belonging to other workloads on the same host? If yes, your isolation is insufficient.

✅ Use ephemeral environments for code execution

When your agent needs to run untrusted code (generated code, user-submitted code, third-party packages):

Create a fresh environment for each execution
Set a short TTL (30-120 seconds)
Destroy the environment after getting the result
Never reuse execution environments between tasks

Test: After completion, does the execution environment still exist? Can you find any traces of the previous execution? Both answers should be "no."

✅ Limit resources at the hardware level

Set CPU limits per workspace (prevents cryptomining)
Set memory limits per workspace (prevents OOM attacks on the host)
Set disk limits per workspace (prevents disk fill attacks)
Set execution timeouts (prevents infinite loops)

Test: Run a fork bomb in the agent's environment. Does it affect other workloads? Does the host become unresponsive? Neither should happen.

Networking

✅ Default to zero-trust

Every agent environment should start with:

No inbound connections from any source
No connectivity to other agent environments
No connectivity to internal services

Then add only the connections you need.

Test: From a new agent environment, try to reach any other service on your internal network. Try to discover other agents. All attempts should fail silently.

✅ Control egress (outbound traffic)

Disable internet access for environments that don't need it
For environments that need internet, allowlist specific domains (LLM APIs, package registries)
Block all other outbound traffic

Common mistake: Allowing full internet access "for convenience." An agent compromised via prompt injection can exfiltrate data to any server on the internet if egress isn't controlled.

Test: From the agent environment, try to curl a random external URL. If it shouldn't have internet access, this should fail.

✅ Use directed private links

When two services need to communicate:

Create a one-way link (A can reach B, but B can't reach A)
Open only the specific port needed
Use internal IP addresses, never public endpoints

Test: Can the target service initiate connections back to the source? It shouldn't, unless you've explicitly configured a bidirectional link.

✅ Never expose databases to the internet

Database workspaces should have allow_internet: false
Access only through private links from authorized workspaces
Even with a password, a publicly accessible database is a target

Test: Can you telnet to your database port from the internet? The connection should time out or be refused.

Secrets management

✅ Scope API tokens

Each agent should have its own token with minimum necessary permissions
Don't share tokens between agents or environments
Set token expiry (30 days is a reasonable default)
Rotate tokens regularly

Test: Can a token from Agent A access or manage Agent B's workspace? It shouldn't.

✅ Use environment variables, not hardcoded secrets

Store API keys, database passwords, and tokens in workspace environment variables
Never commit secrets to git repositories
Never pass secrets as command-line arguments (visible in process lists)

Test: Run ps aux in the agent environment. Are any secrets visible in command-line arguments? They shouldn't be.

✅ Separate LLM API keys from infrastructure API keys

The key your agent uses to call OpenAI/Anthropic should be separate from the key it uses to manage infrastructure
If the LLM key leaks, the attacker can generate text but can't create workspaces or access data
If the infrastructure key leaks, the attacker can manage workspaces but doesn't automatically get LLM access

Data protection

✅ Encrypt disks per-workspace

Each workspace should have its own encrypted block device with a unique encryption key
Use AES-256 or equivalent
The encryption key should be destroyed on workspace deletion

Test: After deleting a workspace, is the data recoverable? If your provider supports cryptographic erasure, it should be mathematically impossible.

✅ Implement cryptographic erasure

When a workspace is deleted:

Encryption key is destroyed
Data is sanitized
Network interfaces are removed

This ensures data is unrecoverable even with physical access to the storage.

✅ Audit data flows

Know the answer to these questions:

What data does each agent have access to?
Where does that data flow? (Which services, which external endpoints?)
Who can see the data at rest? At transit?
What happens to the data when the workspace is destroyed?

Monitoring and incident response

✅ Monitor per-agent resource usage

Watch for:

Sudden CPU spikes - Could indicate cryptomining or a compromised agent in a loop
Unusual network traffic - Large outbound data transfers to unknown IPs
Disk usage growth - Agent accumulating data it shouldn't have
Unexpected processes - New processes running that the agent didn't start

Action: Set alerts on per-workspace metrics. Investigate anomalies within minutes, not days.

✅ Log agent actions

Log every workspace creation and deletion
Log every command execution with timestamps
Log every network connection established
Log every token issued and revoked

These logs are essential for post-incident investigation.

✅ Have a containment plan

When a compromise is detected:

Stop the workspace immediately - Halts all processes
Revoke the workspace's API token - Prevents further API calls
Take a snapshot - Preserves the compromised state for forensic analysis
Check private links - Identify what else the workspace could have reached
Audit connected services - Look for unauthorized data access in database logs, file access patterns

Don't: Delete the workspace before investigation. The snapshot preserves evidence.

✅ Practice recovery

Can you restore a workspace from a snapshot?
Can you recreate your entire agent infrastructure from configuration files?
How long does recovery take? (On Oblien, workspace creation takes milliseconds, but rebuilding application state takes longer.)

Prompt injection defense

AI-specific threats deserve AI-specific defenses:

✅ Assume all user input is hostile

Never trust user messages to determine what commands to run
The LLM might be tricked into executing commands embedded in user messages
Validate and sanitize the LLM's tool calls before executing them

✅ Use read-only contexts where possible

If the agent only needs to read data, don't give it write access
If the agent only needs to query a database, connect through a read-only user
Limit the blast radius of any prompt injection to the minimum necessary capabilities

✅ Separate planning from execution

The agent's reasoning (LLM calls) should happen in a different context than code execution
The planner proposes actions; a validator checks them; the executor runs them
This creates checkpoints where malicious instructions can be caught

Quick audit

Run through this in 10 minutes:

Question	Good Answer	Red Flag
Where does agent code execute?	Own microVM	Shared container/server
What can the agent reach on the network?	Explicitly configured services only	Everything in the VPC
How long do execution environments persist?	TTL-based, destroyed after use	Indefinitely
Are agent tokens scoped?	Yes, minimum necessary permissions	One token for everything
Are disks encrypted per-workspace?	Yes, unique key per workspace	Shared or unencrypted
What happens when you delete a workspace?	Cryptographic erasure	Files remain on disk
Can you detect a compromised agent?	Per-workspace monitoring + alerts	No monitoring
Do you have a containment plan?	Yes, documented and tested	No plan

If you have more than two red flags, prioritize fixing them before adding new agent capabilities.

Summary

Securing AI agent infrastructure isn't dramatically different from securing any multi-tenant system. The principles are the same: isolate, minimize privileges, encrypt, monitor, and plan for incidents.

What's different with AI agents is the attack surface - they execute arbitrary code, handle untrusted input, and make autonomous decisions. These properties demand stronger isolation (VMs over containers), stricter network controls (zero-trust over VPC), and more aggressive cleanup (ephemeral over persistent).

Oblien's security model is designed for this exact use case. Every workspace is a hardware-isolated microVM with encrypted disks, zero-trust networking, and cryptographic erasure. The defaults are secure - you explicitly open access rather than hoping your restrictions hold.

Start with the checklist above. Fix the red flags. Your agents are as secure as their infrastructure.

Read the security documentation →