Security Best Practices for Production AI Agents

AI agents are not chatbots with better marketing. They execute code, call APIs with real credentials, touch production data, and act without a human watching every step. Their security surface is genuinely different from a web app's, and most of the difference comes down to one uncomfortable fact: the model cannot reliably tell instructions from data.

The Agent Threat Model

A web app's threat model is mature. Untrusted input, sanitize, authenticate, authorize. Agents add failure modes with no clean web-app equivalent:

• Prompt injection. The model consumes instructions and data in the same token stream, so anything the agent reads (an email, a webpage, a support ticket) can try to become an instruction. It is a confused-deputy problem, and there is no parser to patch
• Tool misuse. The attacker does not need code execution if the agent already has tools. "Send the report to the customer" and "send the credentials to the attacker" are the same API call with different arguments
• Data exfiltration. Every tool with network egress is a channel out. A crafted URL parameter is enough
• Lateral movement. Shared credentials turn one compromised agent into all of them
• Cost attacks. Adversarial input that maximizes token usage and tool calls is a denial-of-wallet attack. It does not need to accomplish anything else to hurt you

Design for the assumption that some input, someday, will steer your agent. Then arrange the infrastructure so that a steered agent is worth as little as possible.

Practice 1: Isolate Agent Execution

Every agent should run in its own isolated environment. At Maritime, each agent gets:

• Its own dedicated container. On serverless hosts, its own Firecracker microVM with its own guest kernel and a minimal virtio device model
• Its own persistent volume, with no shared filesystem between agents
• Its own container network, not a shared bridge with other tenants
• CPU and memory limits that stop a runaway process from starving its neighbors

This is not optional. Isolation is the difference between an incident and a breach: a hijacked agent that cannot reach other agents' volumes, networks, or credentials is a contained problem.

Practice 2: Rotate and Scope Credentials

Never give an agent more access than the task in front of it requires:

• Scoped API keys. Read-only tasks get read-only keys
• Short-lived tokens. Prefer credentials that expire over keys that live forever
• Per-agent credentials. Two agents hitting the same service still get two keys, because revocation and audit both happen per key
• Encrypted storage. Secrets should be encrypted at rest and decrypted only at injection time

Maritime stores agent secrets AES-256-GCM encrypted at rest and injects them into the runtime at boot. They are never baked into container images.

Practice 3: Log Everything

When something goes wrong, the log is the only witness. Every tool call, every API request, every decision needs a trail.

Critical events to log:

• Tool invocations and their parameters
• External API calls and responses
• Token usage per request
• Error states and recovery actions
• Input/output pairs for each invocation

Maritime captures structured logs for all agent activity, queryable through the dashboard or API.

Practice 4: Set Resource Boundaries

An agent in a loop is a billing incident in progress. A poorly written prompt, or a cleverly written attack, can trigger recursive tool calls that burn through API credits in minutes.

Set hard limits on:

• Maximum execution time per invocation
• Maximum token budget per request
• Maximum number of tool calls per execution
• Maximum concurrent invocations

Hard limits turn a runaway loop from an open-ended bill into a bounded, observable failure.

Practice 5: Treat Tool Outputs as Hostile

Prompt injection does not only arrive through the front door. If your agent searches the web, reads email, or fetches a URL, every one of those tool results is untrusted input flowing straight back into the model's context. That is a second injection surface, and it is usually the bigger one.

Treat tool output exactly like user input in a web app: validate it, constrain what the agent may do after reading it, and be suspicious of high-privilege actions that immediately follow low-trust reads.

The Bottom Line

Agent security is normal production rigor plus one new discipline: assume the model can be talked into things, and make sure the infrastructure does not amplify that into a breach. Isolate the runtime, scope the credentials, bound the resources, log the evidence. When an input eventually does steer your agent, the blast radius decides whether it was an incident or a headline.