Why Your API Keys Aren't Safe on Self-Hosted AI Agents

Your AI agent needs API keys. OpenAI, Stripe, Slack, Twilio, Anthropic, Google Cloud. Some agents are connected to ten different services. Some are connected to thirty. These keys are the keys to your kingdom; anyone who steals them can impersonate your agent and act on your behalf.

Most teams self-hosting AI agents store these keys the same way they store database passwords: in a .env file or as environment variables on the server. This approach has a critical vulnerability. If the server is compromised (and with 224,000 exposed instances, many are), the keys are immediately visible to the attacker.

This post explains why that's dangerous, how attacks actually work, and what a truly secure API key management system looks like.

The .env File Problem

When you deploy an OpenClaw agent, you create a configuration file that looks something like this:

OPENAI_API_KEY=sk-proj-abc123...
STRIPE_SECRET_KEY=rk_live_xyz789...
SLACK_BOT_TOKEN=xoxb-1234567890...
DATABASE_URL=postgresql://user:password@host:5432/db

This file lives on your server. It's loaded when the agent starts. The keys are now available as environment variables that the agent (and any code running in its context) can access.

The security model here is: "If someone gains shell access to the server, they can read the .env file."

That's not a theoretical concern. That's a practical reality for exposed agents. Here's how an attacker would do it:

Step 1: Discover the exposed OpenClaw instance (as we covered in the previous post).

Step 2: Exploit CVE-2026-25253 to inject a malicious skill.

Step 3: In the skill's initialization code, read the environment variables: os.environ.get('OPENAI_API_KEY').

Step 4: The skill logs the environment variables to a file that it then exfiltrates to the attacker's server.

Step 5: The attacker now has all the API keys stored in plaintext.

From this point, the attacker can:

• Use your OpenAI key to make API calls and generate huge bills
• Use your Stripe key to reverse transactions or refund fraudulent charges
• Use your Slack token to post messages to your workspace
• Use your database credentials to export customer data

And because the keys are being used programmatically (via API calls), the compromises might not be immediately obvious. A few unexpected API charges look like normal fluctuation. A few unusual database queries look like automation. By the time you notice the pattern, weeks of compromise have already occurred.

Why Teams Use .env Files

The question is: why do teams store keys in plaintext when they know it's risky?

The answer is simplicity. Plaintext environment variables are:

• Easy to set up: just edit a text file
• Easy to manage: update the file, redeploy
• Easy to understand: anyone can see what keys are configured
• Portable: the .env format works in Docker, Kubernetes, or bare metal

More secure alternatives (like cloud secret management systems) require additional setup:

• Learning a new tool (AWS Secrets Manager, Google Secret Manager, HashiCorp Vault)
• Managing access policies and permissions
• Integrating the secret manager into your deployment pipeline
• Handling secret rotation

For a team shipping a proof of concept, this overhead is unappealing. They use .env files instead.

And then, once the agent is in production, refactoring to a more secure system feels risky. It's easier to leave well enough alone.

The Hidden Cost of Plaintext Keys

Even if your server is never compromised, plaintext keys create other vulnerabilities:

Logging: If your agent logs environment variables for debugging purposes, those keys end up in logs. Logs are often stored for weeks or months. Any person or process with access to logs can extract the keys.

Backups: If you back up your server or your code repository, the .env file is often included in backups. The backup storage might have weaker security than your production server. Your keys are now stored in multiple places.

Version Control: Teams sometimes accidentally commit .env files to Git repositories. Even if you delete the file later, it remains in the Git history. Anyone who clones the repo can extract the keys from older commits.

Container Images: If you build Docker images with API keys baked in (instead of mounted as environment variables), those keys are now in the image layers. Anyone who has access to the image repository can extract them.

Shared Access: Multiple team members might have SSH access to the server. Each additional person is another vector for key exposure. A disgruntled employee. A contractor whose access wasn't revoked. A junior engineer who doesn't understand the security implications.

Each of these scenarios is common. Most of them have happened at some point in your organization (even if you weren't aware of it at the time).

What a Secure API Key System Looks Like

A truly secure key management system has these properties:

Keys Are Encrypted At Rest: Keys are stored in an encrypted form. If someone gains access to the storage medium (database, filesystem, backup), the keys are not readable without the encryption key.

Keys Are Never Visible in Dashboards: Even if you have admin access to the system, you can't view keys in plaintext. You can only view identifiers or metadata about the keys (when they were created, when they expire, etc.).

Keys Are Referenced by ID: When code needs to use a key, it references it by a unique identifier. The system looks up the key, decrypts it, and uses it. The code never sees the plaintext key.

Key Access Is Scoped: Each agent deployment can only access the keys it needs. An agent configured to use OpenAI and Stripe can't access Slack keys. If a malicious actor compromises one agent, they can't steal keys for other agents.

Every Access Is Logged: When a key is accessed, that access is logged with metadata: which agent, when, for what purpose, from which IP address. This creates an audit trail that helps you detect suspicious activity.

Keys Can Be Rotated Quickly: If you suspect a key is compromised, you can rotate it (generate a new one and revoke the old one) without changing your agent configuration or redeploying code.

Key Lifecycle Is Managed: Keys have expiration dates. You can enforce rotation policies. Old keys are automatically revoked. Lost or stolen keys have a limited window of usefulness.

This is not a theoretical model. Enterprise secret management systems (like AWS Secrets Manager, Google Secret Manager, Vault, or Supabase Vault) implement all of these properties.

The catch: they're additional infrastructure that someone has to manage. That's why many teams don't use them.

How Cortex Implements Secure Key Management

Cortex uses a Bring Your Own Key (BYOK) model that implements all of the above properties:

Encryption in Supabase Vault: When you provide an API key to Cortex, it's encrypted using Supabase Vault, which is backed by Postgres pgsodium encryption. Keys are encrypted at rest with AES-256 encryption derived from a hardware security module (HSM) or a managed key service.

Keys Are Stored by ID: Your agent doesn't store the key itself. It stores a reference ID. When the agent needs to use the key, it requests it from Cortex's key service, which decrypts it and returns the value.

Scoped Access: Each agent deployment has a list of keys it's authorized to access. If agent-A is compromised, the attacker can only access keys that agent-A is configured to use. They can't access keys for agent-B or agent-C.

Per-Organization Isolation: Keys are namespaced by organization. Your keys are completely isolated from other Cortex customers' keys. There's no cross-contamination.

Audit Logging: Every access to a key is logged. You can see exactly when the key was accessed, which agent accessed it, and for what purpose. If you suspect a compromise, you can review the audit log to understand the scope of the breach.

Key Rotation: You can rotate keys through the Cortex dashboard. When you generate a new key, old keys are revoked. Agents automatically use the new key on their next request. No redeployment needed.

Secure Transport: When a key is transmitted from Cortex's key service to an agent, it travels over an encrypted channel (TLS). The agent uses the key and doesn't log or store it. Once the request is complete, the key is discarded from memory.

The Practical Difference

Let's compare the security posture of a self-hosted agent versus a Cortex agent:

Self-Hosted Agent: API keys are in a .env file on the server. If the server is compromised, keys are immediately visible. The attacker can use the keys indefinitely until you discover the compromise (which might take weeks). You have no audit log of when the keys were accessed. Rotating keys requires redeploying code.

Cortex Agent: API keys are encrypted in Supabase Vault and referenced by ID. If an attacker compromises the agent, they can't access the keys directly; they can only request keys they're authorized for. Every request is logged. You can rotate keys instantly from the dashboard. Even if an attacker steals a key, you can detect it immediately through the audit log.

The difference isn't marginal. It's fundamental. Cortex's architecture makes key compromise significantly harder and significantly more detectable.

The Real Cost of Weak Key Management

It's tempting to think of API key security as a "nice to have." But the real cost of a key compromise is enormous:

• Unexpected API charges (thousands to hundreds of thousands of dollars)
• Data exfiltration (customer PII, trade secrets, financial records)
• Reputational damage (customers lose trust when they learn their data was exposed)
• Regulatory fines (GDPR, CCPA, and other regulations include penalties for data breaches)
• Incident response costs (forensics, notifications, legal, remediation)

A robust key management system (like Cortex's BYOK model) prevents these costs by making compromises harder to achieve and easier to detect.

A Better Foundation

If you're self-hosting OpenClaw, don't use .env files. Migrate to a secret management system immediately:

• AWS Secrets Manager
• Google Secret Manager
• HashiCorp Vault
• Supabase Vault
• Azure Key Vault

Each of these provides encryption at rest, audit logging, and key rotation.

But if you don't have a DevOps team to manage the integration, this might feel like additional work. And you'd be right. It is additional work.

Cortex builds this into the product from day one. Your keys are secure by default. You don't need to integrate secret managers or manage encryption keys. You just provide your API keys to Cortex, and they're protected automatically.

For teams without DevOps expertise, that's a game-changer. For teams with DevOps expertise, it's a way to remove operational complexity.

Either way, the conclusion is the same: plaintext API keys on self-hosted agents are a liability. A secure key management system isn't optional. It's essential.

Ready to secure your API keys? Visit launchcortex.ai to deploy agents with BYOK security and encrypted key management.