Coding agents can read more than code.

A readable workspace is part of the agent's input.

Local coding agents inspect files and invoke development tools. Their exact boundaries differ, but the useful modes can read a project and the more autonomous modes can run commands. OpenAI documents workspace access, sandbox modes and full-access modes for Codex. Anthropic documents file reading, shell permissions and a mode which bypasses permission prompts for Claude Code.

If a project contains a plaintext credential, a tool which can read the project may be able to read that credential too. Git ignoring the file only keeps it out of a normal commit.

project/
  src/
  tests/
  .env              # code and secret values share one readable workspace

This does not mean every agent sends every file to a model or uses it for training. It means the value is inside the agent's accessible tool boundary and can enter command output, logs or model context.

Let the project expose names, not values.

Move the values into the encrypted Kimen vault outside the project:

kimen vault init
kimen secret set app.dev.database_url
kimen secret set app.dev.payments_api_key

Commit a profile which describes the runtime contract:

# .kimen/profiles/dev.kmap
env DATABASE_URL=app.dev.database_url
env PAYMENTS_API_KEY=app.dev.payments_api_key
env APP_ENV=const:development

The agent can now see that the application expects DATABASE_URL, PAYMENTS_API_KEY and APP_ENV. It can change configuration code, write tests and inspect the projection plan without seeing a value:

kimen map lint --profile dev --strict
kimen plan --profile dev

kimen plan prints names, sources and projection modes. It does not open the vault.

Unlock the vault only when a trusted process needs it.

Start the application or a trusted integration test through Kimen:

kimen run --profile dev -- ./start-development-server

With no active session, Kimen asks you for the vault passphrase on every invocation. The passphrase opens the local vault for that command, and only the selected values are projected. It is not added to the project.

For several trusted runs in one work period, open a short session:

kimen session start --ttl 15m
kimen session status

# run the application or trusted tests several times
kimen run --profile dev -- ./start-development-server

kimen session lock

The session avoids repeated passphrase prompts until it expires or is locked.

kimen run gives the child process the values.

Kimen removes the permanent plaintext copy from the project. It does not hide a value from the process which legitimately receives it.

If an agent can change the receiving program or choose an arbitrary command, that program can print, save or send its environment. Treat this as trusted runtime projection:

good boundary
  agent reads project contract
  human unlocks selected values
  trusted application receives them

not a boundary
  agent chooses arbitrary code
  arbitrary code receives production credentials

Use low-privilege development credentials, keep secret-dependent commands explicit and use the agent's sandbox or a separate identity when you need a stronger operating-system boundary.

Kimen Operations describes the planned extension for cases where a caller should receive one named operation, such as inspect_logs(service, since), without receiving the credential at all. That is not a property of today's kimen run.

Kimen complements agent permissions. It does not replace them.

Agent permissions decide which files, commands and networks the agent can use. Kimen decides where selected local values are stored and how they reach a runtime.

• Keep the Kimen vault and session path outside the writable project.
• Do not export secret values in the parent shell before starting the agent.
• Let the agent inspect committed profiles and use kimen plan.
• Require a human passphrase for secret-dependent runs, or use a deliberately short session only within a boundary you accept.
• Assume a process started through kimen run can read everything projected to it.

Why Kimen instead of a password manager?

1Password CLI can also inject secrets into subprocesses and configuration files. It is often the better choice when a team already stores and shares credentials in 1Password and wants central account administration.

Kimen is useful when you want a small open-source tool, an encrypted local vault, no account or service dependency, offline operation and project-owned profiles which describe exactly what each runtime expects.

A cloud secret manager is usually the better production choice when the workload already has a narrow cloud identity. Kimen is most distinct in local development and portable project configuration. Read the full Kimen, 1Password and cloud secret manager comparison.

Sources and current tool behavior

The agent examples are grounded in the vendors' current documentation:

• OpenAI, Running Codex safely
• OpenAI, Codex sandbox and approval modes
• Anthropic, Claude Code CLI permissions and flags

Agent products change quickly. Check the current permission and sandbox documentation for the tool and mode you actually run.