Securing API Keys in Agent Workflows: A Practical Guide

Every AI agent needs API keys. Your research agent calls OpenAI. Your code agent calls Anthropic. Your notification agent calls Slack and SendGrid. A 5-agent chain might touch 4 different API providers, each with their own credentials.

The question isn't whether your agents need keys. It's where those keys live, who can see them, and what happens when one gets compromised.

The API key problem in agent orchestration

Traditional applications have one set of API keys, managed by one team, stored in one place. Agent orchestration multiplies this by the number of agents, chains, and providers in your system.

A typical production setup might look like:

3 LLM providers (OpenAI for GPT-5.4, Anthropic for Claude, a local model for classification)
2 data sources (database credentials, third-party API keys)
2 output targets (Slack webhook, email service API key)
1 monitoring service (logging API key)

That's 8 secrets for a single chain. Multiply by the number of chains running in your organization, and you have a credential management problem that most platforms don't address well.

What happens when you paste keys into SaaS platforms

Most agent orchestration platforms are cloud-hosted. When you configure an agent, you paste your OpenAI API key into their web interface. Here's what that means in practice:

Your key is transmitted over HTTPS to their servers. It's stored in their database, encrypted (hopefully) with their encryption keys. When your agent runs, their infrastructure decrypts your key and uses it to call OpenAI on your behalf.

This creates several problems:

You're trusting their infrastructure. If their database is breached, your keys are exposed. You're inheriting their security posture whether it matches your requirements or not.

You can't audit access. You don't know who at the platform company can access your keys. You don't know what their internal access controls look like. You don't know if an employee, a contractor, or a compromised service account has read your credentials.

You're creating a high-value target. A platform that stores thousands of customers' API keys is an attractive target. One breach exposes every customer's credentials simultaneously.

Compliance becomes murky. If you're subject to SOC 2, HIPAA, or similar frameworks, storing API keys with a third party creates documentation and audit requirements that many teams don't anticipate.

This isn't FUD. It's the basic reality of shared infrastructure. The platform might be doing everything right. But you're taking their word for it, and you have no visibility into their practices.

The self-hosted advantage: keys never leave your machine

When the orchestration platform runs on your infrastructure, the key management story changes completely.

Your API keys go from your machine to the LLM provider. That's it. No intermediary. No third-party storage. No additional trust boundary.

With Mentiko's self-hosted architecture, the flow is:

You store your API key in Mentiko's local secrets vault
When a chain runs, the key is decrypted in memory on your machine
The key is injected as an environment variable into the agent's workspace
The agent calls the LLM provider directly from your machine
After execution, the key exists only in the vault -- not in logs, not in event files, not in chain definitions

There's no proxy server. No platform relay. No man-in-the-middle. Your network traffic goes directly to api.openai.com or api.anthropic.com from your own IP.

Encryption at rest: AES-256-GCM

Mentiko's secrets vault encrypts all stored credentials using AES-256-GCM (Galois/Counter Mode). This isn't a choice we made for marketing -- it's the NIST-recommended authenticated encryption algorithm that provides both confidentiality and integrity.

What this means in practice:

Confidentiality: The encrypted data is unreadable without the key
Integrity: Any tampering with the encrypted data is detected on decryption
Authentication: The GCM tag verifies the data hasn't been modified

The vault key itself is derived from your instance configuration. If someone copies your vault file without the instance key, they get meaningless bytes.

Secrets are decrypted only at execution time, held in memory for the duration of the agent's run, and never written to disk in plaintext. Chain definitions, event files, and logs never contain raw credentials.

Per-chain key scoping

Not every chain should have access to every secret. Your content generation chain doesn't need your production database password. Your monitoring chain doesn't need your payment processor API key.

Mentiko supports per-chain secret scoping:

{
  "chain": "content-pipeline",
  "secrets": ["OPENAI_API_KEY", "SLACK_WEBHOOK"],
  "agents": {
    "researcher": ["OPENAI_API_KEY"],
    "publisher": ["SLACK_WEBHOOK"]
  }
}

Each chain declares which secrets it needs. Each agent within the chain can be further scoped to only the secrets it requires. An agent that doesn't have a secret in its scope simply doesn't have that environment variable -- there's nothing to leak.

This is the principle of least privilege applied to API keys. A compromised agent can only expose the secrets it was given, not every secret in your vault.

Rotation strategies that don't break running chains

API key rotation is critical but often neglected because teams are afraid of breaking things. Here's how to rotate without downtime:

For scheduled rotation:

Generate a new key with your provider (most providers support multiple active keys)
Update the secret in Mentiko's vault
New chains automatically use the updated key on next run
Verify new runs succeed
Revoke the old key at the provider

Running chains continue with the key they were given at startup. New runs get the new key. There's no moment where both keys are invalid.

For emergency rotation (key compromised):

Revoke the compromised key at the provider immediately
Generate a new key
Update Mentiko's vault
Any currently running chains using the old key will fail -- this is intentional. A compromised key should stop being used immediately
Re-trigger any failed chains

For rotation schedules:

Set a rotation cadence based on risk. LLM provider keys with usage-based billing should rotate monthly at minimum. Database credentials should rotate on your compliance schedule. Webhook URLs are lower risk but should still rotate quarterly.

Audit logging: who accessed what, when

When a security incident happens, the first question is always "what was accessed?" Mentiko's audit log captures every secret access:

Which chain requested the secret
Which agent within the chain received it
When the access occurred
The run ID (so you can correlate with execution logs)
Whether the access was successful or denied

This log is append-only and stored separately from the secrets themselves. If you need to answer "did any chain access the Stripe API key between March 1 and March 15?" -- that's a single query.

For compliance workflows, export the audit log to your SIEM or logging platform. The structured format (JSON lines) integrates with standard log aggregation tools without custom parsing.

Setting up Mentiko's secrets vault

Getting started takes about two minutes:

1. Open the secrets manager:

Navigate to Settings > Secrets in your Mentiko instance.

2. Add a secret:

Name: OPENAI_API_KEY
Value: sk-proj-...
Scope: All chains (or select specific chains)

The value is encrypted the moment you save. The plaintext never hits disk.

3. Reference in your chain:

{
  "agent": "researcher",
  "env": ["OPENAI_API_KEY"],
  "prompt": "Research the following topic..."
}

The agent receives OPENAI_API_KEY as an environment variable at runtime. The chain definition contains only the variable name, never the value.

4. Verify access control:

Check Settings > Secrets > Access Log to confirm only the expected chains are accessing each secret. If you see unexpected access, investigate immediately.

5. Set up rotation reminders:

Tag each secret with a rotation schedule. Mentiko will surface reminders when secrets are due for rotation -- it won't auto-rotate (that's a dangerous default), but it won't let you forget either.

The bottom line

API key security in agent workflows comes down to three principles: minimize who has access (self-hosted, per-chain scoping), protect at rest (AES-256-GCM encryption), and know what happened (audit logging).

Most breaches aren't sophisticated attacks. They're an API key that was pasted into a config file, committed to git, stored in a shared spreadsheet, or left in a SaaS platform that got breached. Remove those paths and you've eliminated the most common attack vectors.

Want to see Mentiko's security architecture in detail? Visit the security page or start building your first chain.