Secure AI Agent Deployment: Pre-Launch to Production

Lock it down before you turn it on.

Most teams deploy AI agents the way they deploy a new npm package: install it, give it credentials, and hope for the best. That works until the agent reads your .env file and sends it somewhere it shouldn’t.

Secure AI agent deployment is not a single checklist item. It starts before you turn the agent on and continues through every production request. This guide covers the controls that matter, in the order you should apply them.

Threat model first

Before writing a single config file, answer four questions:

What can the agent access? List every credential, API key, token, and secret the agent process can reach. Include environment variables, config files, credential stores, and anything mounted into the agent’s filesystem.

What network endpoints can it reach? By default, most agents can hit any public IP. That includes attacker-controlled servers, cloud metadata endpoints, and internal services on your network.

What MCP servers does it connect to? Each MCP server is a trust boundary. A malicious or compromised server can poison tool descriptions, inject prompts in responses, or change behavior mid-session.

What’s the blast radius? If the agent is fully compromised through prompt injection, what’s the worst outcome? Leaked cloud credentials? Deleted production data? Lateral movement into internal services?

Your threat model determines which controls are mandatory vs nice-to-have. An agent with read-only access to public docs needs less protection than one with AWS admin keys and shell access.

Pre-deploy controls

These run once, before the agent goes live.

Secret isolation

The agent process should not have direct access to production secrets. Use short-lived tokens, scoped API keys, and credential vending machines instead of long-lived keys in environment variables.

If the agent must have credentials (most do), limit the scope. A GitHub token with read:repo only is less dangerous than one with admin:org. An AWS key scoped to a single S3 bucket is less dangerous than one with AdministratorAccess.

MCP server vetting

Every MCP server you connect to your agent is code running with access to your agent’s context. Before adding one:

Tool allowlisting

Define exactly which tools the agent can call. If your agent only needs read_file and search, don’t give it execute_command and write_file. Deny by default, allow explicitly.

Runtime controls

These run continuously while the agent is active.

Egress proxy

Route all outbound traffic through a scanning proxy. The proxy inspects HTTP requests, MCP tool calls, and WebSocket frames before they leave the network.

What the proxy checks:

Domain allowlists

Restrict where the agent can connect. If it only needs api.github.com and registry.npmjs.org, block everything else. This limits the blast radius of any compromise: even if an attacker injects an exfiltration URL, the proxy rejects the domain.

MCP tool description monitoring

A rug-pull attack sends clean tool descriptions initially, then swaps in poisoned versions mid-session. Runtime monitoring fingerprints every tool description and alerts if one changes after initial discovery.

Logging and rollback

Flight recorder

Log every agent action in a tamper-evident audit trail. A flight recorder captures:

Hash-chain each entry so tampering is detectable. Use signed checkpoints at intervals so an auditor can verify the log hasn’t been modified.

Signed checkpoints

Periodically sign the current state of the audit log with Ed25519 keys. This gives you a cryptographic proof of what the agent did at a specific point in time. Useful for compliance, incident response, and post-mortem analysis.

Kill switch

Build a way to stop all agent traffic immediately. Not “gracefully shut down over 30 seconds.” Stop. Now. When you detect an active exfiltration or a compromised agent session, you need the ability to cut the connection within seconds.

A proxy-based kill switch is straightforward: the proxy stops forwarding. The agent can’t bypass it because the agent doesn’t have direct network access.

Reference architecture

                ┌──────────────┐
                │   AI Agent   │
                │  (no direct  │
                │   network)   │
                └──────┬───────┘
                       │
              ┌────────▼────────┐
              │    Pipelock     │
              │  Egress Proxy   │
              │                 │
              │  DLP ▸ Injection│
              │  SSRF ▸ Domain  │
              │  Allowlist ▸ Log│
              └───┬─────────┬───┘
                  │         │
         ┌────────▼──┐  ┌──▼────────┐
         │  Internet  │  │MCP Servers│
         │  (HTTP/S)  │  │ (wrapped) │
         └────────────┘  └───────────┘

The agent process has credentials but no network access. The proxy has network access but no credentials. MCP servers are wrapped through the proxy, so tool calls and responses pass through the same scanning pipeline as HTTP traffic.

This is capability separation. Neither component alone can exfiltrate data. Both must be compromised simultaneously for secrets to leave the network.

Getting started

Install Pipelock and set up your agent in under a minute:

# Install
brew install luckyPipewrench/tap/pipelock

# Set up Claude Code (hooks + MCP proxy in one command)
pipelock claude setup

# Or set up Cursor
pipelock cursor setup

For any agent that makes HTTP requests:

# Start the proxy
pipelock run

# Route traffic through it
export HTTPS_PROXY=http://127.0.0.1:8888

Combine with network isolation (iptables, container networking, or Kubernetes NetworkPolicy) for enforcement that prompt injection can’t bypass.

Further reading

Ready to validate your deployment?

Get Pipelock See Assess Reports