Your MCP Server Has Secrets. Can the AI Read Them?

The short answer

If a coding agent can run shell commands in a workspace that contains a .env file, assume it can read that file. If an AI client launches a tool with production credentials in its environment, assume the model may be able to ask that tool to use those credentials. Prompt instructions are not a security boundary.

But an MCP server connected to a secrets platform does not automatically mean the AI can read secret values. The answer depends on the server's identity model and tool contract.

SikkerKey's MCP server is built around a read-blind management model: the AI agent can manage vault configuration, inspect metadata, create or rotate secrets, and audit what happened, but no MCP tool returns plaintext for an existing stored secret. The AI agent is not a machine identity, and it cannot call the machine routes that read runtime secrets.

That distinction matters for teams searching for:

• should AI agents access secrets
• can AI agents read environment variables
• AI agent secret access
• protect secrets from AI agents
• coding agent .env security
• Claude Code secrets management
• Codex secrets management
• AI coding agent secrets

The practical rule is simple: do not give an AI coding agent ambient access to raw credentials. Give it a separate, scoped identity whose tools are designed so sensitive values do not come back into the conversation.

Why .env files are the wrong boundary

A .env file is convenient because it is close to the code. That is also why it is dangerous around coding agents.

Tools like Claude Code, Codex, Cursor, and other agentic development environments often have some combination of file access, terminal access, test execution, and package manager access. If DATABASE_URL, STRIPE_SECRET_KEY, or a cloud access key is sitting in the repository or inherited by the shell the agent can use, then the agent may be able to read it, print it, include it in logs, pass it to a script, or accidentally expose it while debugging.

This is not a model-brand problem. It is an access-design problem. Claude Code secrets management, Codex secrets management, and AI coding agent secrets all come down to the same question: what credentials are reachable from the agent's tools?

A safer setup removes plaintext credentials from the workspace entirely. The app gets secrets at runtime through a machine identity. The AI gets a different identity for management work, with no read-value path.

What an AI agent should be allowed to do

AI agents are useful around secrets, but not because they need to see every value.

A useful agent can help you:

• list projects and secret metadata
• create placeholder or supplied secrets during setup
• rotate values
• update notes, names, access policies, and machine grants
• inspect audit history
• create enrollment tokens for ephemeral machines
• investigate which machine or policy can reach which secret
• open or update support tickets with relevant metadata

None of those tasks require returning existing plaintext secret values to the model.

Some actions do require a new value as input. For example, if you ask an agent to create a new secret with a value you provide, the value necessarily appears in that request. That is different from letting the agent read arbitrary existing secrets from the vault. For production credentials, prefer server-side generation, rotation, or human-in-the-loop entry where possible.

How SikkerKey's MCP identity works

The SikkerKey MCP server runs locally as a child process of your AI client. During setup, the dashboard issues a one-time AI-agent bootstrap token. The sikkerkey-mcp install command generates an Ed25519 keypair on your machine, sends only the public key to SikkerKey, and stores the private key locally.

After registration, the agent is pending until approved in the dashboard. Once approved, each MCP call is signed with that agent key. SikkerKey verifies the signature, timestamp, nonce, source IP allowlist, enabled state, approval state, account state, scopes, and project access before a route runs.

This matters because the AI agent is not borrowing your browser session and it is not sharing a machine identity. It has its own revocable identity, its own audit trail, and its own permission set.

The read-blind contract

SikkerKey separates two identity classes:

• Machines consume secrets at runtime through SDK and CLI read routes.
• AI agents manage configuration through the /v1/ai management surface.

Those are separate tables, separate bootstrap token types, and separate auth lookups. A machine key cannot be used as an AI agent identity. An AI agent key cannot authenticate to the machine routes that read secret values.

On the MCP side, secret tools are intentionally read-blind:

• Listing secrets returns metadata such as id, name, type, fields, note, version, and timestamps.
• Getting one secret returns the same kind of metadata.
• Creating a secret accepts plaintext input, and returns only metadata.
• Updating a value accepts plaintext input, and returns only id and version.
• Rotating a secret generates the new value and returns only id and version.
• Version history is metadata only.

The important phrase is: no tool returns the plaintext of an existing stored secret.

There is one separate case to understand. Temporary human-share secrets can return a one-time share-link credential on creation, because the whole purpose is to hand that link to a human recipient. That is not a general vault read API, and it should be treated as a different workflow.

Scopes are bounded by the creator, live

A common failure mode in automation is frozen delegation: a person creates a powerful token, then loses access later, but the token keeps working forever.

SikkerKey avoids that for AI agents. An agent's effective permission is bounded by the user who created it, not just at creation time but on every request. If the creator is demoted, the agent's effective management permissions shrink. If the creator is removed from the vault, the agent becomes inert for delegated project access.

Project operations are also gated by project scope and capability. For example, managing a normal secret, structured secret, managed secret, canary, machine grant, or policy axis can require different project-level capabilities. The agent's access role is intersected with the creator's current access.

That gives you a practical answer to “should AI agents access secrets?” They should access secret-management tasks only through a scoped, revocable identity that cannot exceed the human who delegated it.

What MCP tools are deliberately not allowed to do

The SikkerKey AI-agent surface deliberately excludes high-risk paths, including:

• direct secret value reads
• bulk secret export
• machine-auth SDK routes
• vault destruction
• billing and user-account operations
• AI-agent bootstrap token issuance from the MCP agent itself
• changing another agent's scopes or project access from MCP

That last point is important. An AI agent can list, inspect, approve, disable, rename, or revoke agents if it has the right management scope. But issuing new AI-agent bootstrap tokens and editing scopes remain dashboard-only, because letting one agent grant broader access to itself or a peer would create a privilege-escalation path.

Can AI agents read environment variables?

In many coding environments, yes. If the agent can run a command like env, inspect process configuration, read a .env file, or execute code that prints environment variables, then it may be able to see them.

Do not rely on instructions such as “do not read .env.” That is a policy preference, not a durable control.

Better controls include:

• keep production .env files out of AI-accessible workspaces
• avoid launching coding agents with production credentials in their environment
• use separate development and production vault projects
• give the AI a management identity, not a runtime secret-reading identity
• let runtime machines fetch secrets through SDKs under machine-specific grants
• rotate any credential that was exposed to an AI session or transcript

For coding agent .env security, the best .env is the one the agent cannot reach.

Claude Code and Codex secrets management

Claude Code and Codex are powerful because they can inspect code, run tests, edit files, and operate tools. That is exactly why they should not be handed raw production secrets by default.

With SikkerKey, the MCP config for these clients points to the sikkerkey-mcp server. The MCP server signs requests as the approved AI-agent identity. The AI can call the SikkerKey tools, but the tools only expose the allowed management surface.

For Claude Code secrets management, that means you can ask about project configuration, policies, machine grants, rotations, audit events, or whether a secret exists without dumping the secret value into the chat.

For Codex secrets management, the same boundary applies: the coding agent can help wire SDK usage, reason about missing grants, or rotate a credential server-side, while stored plaintext values remain outside the MCP response path.

This does not mean you should put .env files in the repo. It means the secrets platform should be the boundary, not the prompt.

A practical policy for AI agent secret access

Use this policy as a starting point:

1. AI agents may manage secret metadata, policies, rotations, and grants.
2. AI agents should not read existing stored secret values.
3. Runtime applications should use machine identities with the narrowest secret grants that work.
4. Production .env files should not be present in AI-accessible workspaces.
5. Every AI-agent action should be signed, scoped, audited, and revocable.
6. Agent permissions should be bounded by the creator's current access.
7. Secret rotation should prefer server-side generation when a human does not need to know the new value.

This approach lets teams use AI assistance without turning the model transcript into another secrets store.

The actual security question

The question is not “can an AI read secrets?” in the abstract. It is “which identity did we give the AI, and what can that identity return?”

If the AI has shell access to a repo full of .env files, it can probably read secrets. If the AI has a cloud API key in its process environment, it can probably use that key. If an MCP server exposes a read_secret_value tool, the model can ask for the value.

SikkerKey's MCP server is designed differently. The AI gets a dedicated management identity. It signs every request. It is scoped by vault and project policy. It is bounded by the creator's live access. Its actions are audited. And the tools do not return plaintext for stored secrets.

That is the boundary you want: AI agents can help operate your secrets platform without becoming a new place where your secrets live.