AI Agent Security Checklist: 10 Things Cortex Does That Self-Hosted Agents Don't
Security in production AI isn't one thing. It's a checklist. A long one. When you're running autonomous agents that call external APIs and interact with databases, you need defense in depth: encryption, isolation, monitoring, logging, and automation all working together.
Most self-hosted agent platforms hand you the keys to the kingdom and walk away. You're responsible for SSL, DNS, firewall rules, secret management, monitoring, and updates. One mistake, one missed step, and you've got a security incident.
Cortex flips this model. We've baked these ten critical security practices into the platform, and they apply automatically to every agent you deploy. No configuration required. No manual setup. No room for human error.
Here's the checklist. If you're evaluating agent platforms, use this as your scorecard.
1. Automated SSL/TLS Certificates
What Goes Wrong Without It
- You generate a self-signed certificate and forget about the expiration date
- Six months later, your agent stops working because clients reject the expired certificate
- You scramble at 2 AM to renew it, fumbling through OpenSSL commands
- Meanwhile, your agent is offline and requests are failing
Or worse:
- You forget SSL entirely and run your agent over plain HTTP
- All communication is visible in transit
- API keys, request payloads, response data: all sniffable by anyone on the network
- A DNS hijack or man-in-the-middle attack compromises your entire system
How Cortex Handles It
Cortex automatically provisions SSL/TLS certificates for every agent using Let's Encrypt. Certificates are renewed automatically before expiration. The process is transparent: you don't think about it, it just works.
- Every agent gets a valid, publicly trusted certificate
- Renewals happen automatically 30 days before expiration
- All communication is encrypted in transit
- You get an A grade on SSL Labs
- Zero configuration required
2. DNS Routing with Subdomain Isolation
What Goes Wrong Without It
- You deploy multiple agents on the same server with the same IP address
- DNS routing becomes a mess: you're juggling reverse proxies, load balancers, path-based routing
- An attacker discovers one agent, ports its endpoint, and suddenly has access to all agents on that server
- One compromised agent can pivot to others because they share infrastructure
How Cortex Handles It
Each agent gets its own subdomain: agent-name.agents.launchcortex.ai. DNS routing is automatic and consistent.
- Agent isolation by DNS means each agent has its own "address" in the system
- One agent's misconfiguration doesn't affect others
- DNS is globally distributed, no single point of failure
- You can revoke access to one agent without touching others
- Clean, predictable URLs for integrations
3. Firewall Configuration on Every Server
What Goes Wrong Without It
- You provision a server for your agent and skip firewall setup to "save time"
- The server is exposed to the entire internet
- Port scanners find open ports on your system
- An attacker connects directly to your database, SSH service, or monitoring dashboard
- You've got a breach before you even deploy the agent
How Cortex Handles It
Every agent runs on a dedicated server with automatic firewall configuration. Only necessary ports are open:
- Port 443 (HTTPS) for agent communication
- Port 80 (HTTP) redirects to HTTPS
- All other ports are blocked by default
- SSH is available only from Cortex's management network
- Firewall rules are enforced at the kernel level (iptables/netfilter)
- No manual configuration: the firewall is set up during provisioning
4. BYOK with Encrypted Key Storage (Supabase Vault)
What Goes Wrong Without It
- You store API keys in plaintext environment files
- A developer's laptop gets stolen: attacker has all your keys
- A server is compromised: attacker exports the entire
.envfile - You rotate a key and have to manually update and redeploy: downtime, coordination headaches
- Months later, you still don't know if the old key was accessed by attackers
How Cortex Handles It
Keys are encrypted at rest using pgsodium (libsodium in PostgreSQL). They're stored as encrypted blobs in Supabase Vault. Your agent references them by ID, never by plaintext value.
- Keys encrypted with XChaCha20-Poly1305 authenticated encryption
- Plaintext keys never stored on disk
- Secrets accessed by ID, reducing attack surface
- Key rotation without downtime (agent keeps running, new requests use new key)
- Zero-knowledge: Cortex cannot read your secrets
5. Audit Logging for Every Secret Access
What Goes Wrong Without It
- Someone accesses an API key from an unauthorized agent
- You have no idea it happened until the bill for API calls arrives
- You can't prove you didn't expose the key intentionally
- Compliance auditors ask "who accessed this secret?" and you have no answer
How Cortex Handles It
Every access to a secret is logged in secret_access_log. The log includes agent ID, secret ID, timestamp, and access result.
- Immutable audit trail: logs can't be deleted
- Every secret pull is recorded with precise timing
- Alerts trigger on unusual access patterns
- Compliance queries are simple: "Show me all accesses to this secret in the last 90 days"
- Investigation-ready: if a key is compromised, you know exactly which agents accessed it
6. Dedicated Isolated Servers (Not Shared Multi-Tenant)
What Goes Wrong Without It
- A multi-tenant platform runs your agent on a shared server with other customers' agents
- Another customer has an agent with a memory leak that consumes resources
- Your agent gets starved of CPU and memory, becomes slow and unresponsive
- Performance is unpredictable because you're competing for resources with unknown workloads
- A security vulnerability in another customer's agent could cascade to yours (shared libraries, shared OS)
How Cortex Handles It
Each agent runs on its own dedicated server. No sharing. No resource contention. No noisy neighbors.
- Predictable performance: you own all the resources
- Security isolation: your agent's environment is isolated at the kernel level
- You can configure resources (CPU, memory, disk) without affecting anyone else
- Easier debugging: performance issues are yours alone, not a multi-tenant mystery
- Compliance-friendly: no shared infrastructure means no data commingling
7. Root-Owned Environment Files (Mode 0600)
What Goes Wrong Without It
- Secrets are written to an environment file with world-readable permissions
- Any user on the system can read the secrets
- A vulnerability in an unrelated application lets an attacker execute code as a low-privilege user
- That low-privilege process reads the world-readable environment file
- Attacker now has all your API keys
How Cortex Handles It
Secrets are provisioned into files owned by root with mode 0600 (read/write for owner only).
- Only the root-owned systemd service can read secret files
- Application processes inherit access through the file descriptor, not direct filesystem access
- A compromised application process running as a non-root user cannot read the secret files
- Filesystem permissions enforced at the kernel level
- Even SSH access (as a regular user) cannot read the secrets
8. Automatic OpenClaw Updates Propagated to All Deployments
What Goes Wrong Without It
- A critical security vulnerability is discovered in the AI agent runtime
- The patch is released, but you have to manually apply it to each of your servers
- You miss one server, and a critical flaw remains unpatched
- An attacker exploits that one unpatched server
- You patch reactively, after the breach, instead of proactively
How Cortex Handles It
OpenClaw, our agent runtime, is automatically updated across all deployments. Security patches are applied within hours of release.
- No manual updates: patches apply automatically
- All agents stay synchronized on the same runtime version
- Security fixes don't require downtime (systemd restarts services gracefully)
- Compliance auditors see: "Yes, all agents are on the latest secure version"
- You focus on your agent logic, not runtime maintenance
9. Health Monitoring and Systemd Services
What Goes Wrong Without It
- Your agent process crashes for an unknown reason
- There's no automatic restart, so it stays down
- Requests fail silently while you sleep
- Hours later, you wake up to a Slack notification that service has been degraded
How Cortex Handles It
Each agent runs under systemd with health monitoring and automatic restart policies.
- Agent crashes trigger automatic restarts (configurable: immediate, after delay, max retries)
- Health checks run continuously; if an agent becomes unresponsive, it's restarted
- Systemd logs all service events to the system journal, providing a complete history
- Resource limits are enforced (memory, CPU, file descriptors) to prevent runaway processes
- You can query the status of any agent instantly:
systemctl status cortex-agent-*
10. Scoped Secret Naming to Prevent Cross-Agent Collisions
What Goes Wrong Without It
- You have two agents, both needing an OpenAI key
- In your haste, you name the secret
OPENAI_API_KEYfor both - A developer working on agent A accidentally references agent B's secret
- Configuration is now mixed between deployments, and they can't figure out why requests are failing
- Or worse: agent A is now using agent B's API key quota, and all requests are going to the wrong account
How Cortex Handles It
Secrets are scoped per-organization and per-deployment. Naming is clear and collision-free.
- Secret naming follows a hierarchical pattern:
org.deployment.agent.key - The system prevents you from creating duplicate names within a scope
- Each agent can only access secrets explicitly granted to it
- Cross-agent secret access requires explicit authorization
- Configuration management becomes straightforward and auditable
Your Security Scorecard
As you evaluate agent platforms, go through this checklist:
- Does the platform automatically provision SSL certificates and keep them updated?
- Is each agent isolated on its own infrastructure, or sharing resources with others?
- Are API keys encrypted at rest, and referenced by ID rather than stored as plaintext?
- Is every secret access logged and auditable?
- Are security updates applied automatically across all deployments?
- Is there a firewall protecting each agent, or is it exposed to the internet?
- Are environment files protected by restrictive filesystem permissions?
- Can you distinguish between agents in your system, or do they blend together?
- Is there continuous health monitoring and automatic recovery?
- Can you prevent secrets from being accidentally shared between agents?
If your current platform is missing even a few of these, you've got a security debt. Cortex includes all ten, out of the box, on every agent, automatically.
Because when you're running AI in production, security shouldn't be something you bolt on. It should be the foundation.
Get security as the foundation. Visit launchcortex.ai and deploy agents with all ten security checklist items built in automatically.
Get new posts + free skills in your inbox
One email per post. Unsubscribe anytime.
Related posts
The BYOK Security Model: How Cortex Keeps Your LLM Keys Safe
Why Your API Keys Aren't Safe on Self-Hosted AI Agents
OpenClaw's Security Crisis: What Every Team Should Know Before Self-Hosting
Want an AI agent that runs skills like these automatically?
Cortex deploys your own AI agent in 10 minutes. No DevOps required.
Start free trial →