How can we reduce secret exposure when running AI coding agents?

[timothysparg]

When you run a coding agent in a shell where fnox is active, the agent inherits all the secrets that fnox has injected. The agent can read them, include them in prompts sent to a remote LLM, write code that logs them, or pass them to subprocesses it spawns.

Has anyone found a good approach - whether inside fnox or around it - to limit what the agent actually has access to?

[jdx]

this is what the mcp is for

[timothysparg]

@jdx ahh this is new functionality 😄

Do you mind helping me understand how to use it to the best benefit?

If I setup my project to use _.fnox-env = { tools = true }

mise.toml

[tools]
fnox = "1.12.1"

[env]
_.fnox-env = { tools = true }

[plugins]
fnox-env = "https://github.com/jdx/mise-env-fnox"

fnox.toml

[providers]
age = { type = "age" }

[secrets]
GITHUB_TOKEN   = { provider = "age", value = "AGE-SECRET-KEY-..." }
DATABASE_URL   = { provider = "age", value = "AGE-SECRET-KEY-..." }

[mcp]
secrets = ["GITHUB_TOKEN"]
tools   = ["get_secret"]

then claude can only access the GITHUB_TOKEN via the MCP server, however it can also access DATABASE_URL as it is available in the shell.

I feel like I must be missing something here - is the intended workflow to use either mise injection or MCP, but not both at the same time?
If so, what does the recommended setup look like for a project where humans need secrets in their shell, but AI agents should only have access to a restricted subset?

[Nyrok]

The infra isolation approach is the right layer to fix. Worth adding a behavioral layer on top too: an explicit constraints block in the agent's prompt specifying what it's not allowed to do. Never read env vars directly, never log tokens, never pass credentials to subprocesses.

It doesn't replace proper isolation, but it narrows the agent's intent before it acts. A model told explicitly "do not access or transmit secrets" will avoid opportunities it might otherwise stumble into. Combined with fnox scoping, you get defense in depth.

I've been building flompt for structured prompts like this: decompose the task into typed blocks including a constraints block, compile to Claude-optimized XML. Makes security constraints explicit and repeatable across agent runs. Open-source: github.com/Nyrok/flompt

[jdx]

The key piece you're missing is env = false. If you set DATABASE_URL = { ..., env = false }, it won't be injected into the shell at all — so agents can't see it. Humans can still retrieve it with fnox get DATABASE_URL.

Combined with the [mcp] secrets allowlist from #358, the recommended pattern is:

• Secrets agents need: leave env = true (default) + add to [mcp] secrets
• Secrets only humans need: set env = false — accessible via fnox get but invisible to agents
• Secrets neither should see in env: env = false and omit from [mcp] secrets

So yes, you can use both mise injection and MCP together — just use env = false on secrets you want to keep away from agents.

This comment was generated by Claude Code.