Give your agent .env variables without giving it their values

I’ve been thinking about how much configuration a coding agent actually needs.

It often needs to know which services a project uses. For example, that the project has a GITHUB_TOKEN_, _DATABASE_URL, or LINEAR_APIKEY.

But that doesn’t mean it should be able to read the real .env file.

With Stashbase, you can export a redacted schema:

stashbase secrets schema pull \
  --project my-project \
  --environment api-dev

The generated env.schema.yaml contains the project and environment metadata, secret names, and comments. Secret values are never included.

That gives the agent enough context to understand the project without handing over the credentials themselves.

I can also block access to the local .env file:

[filesystem]
deny_read = [".env"]
deny_write = [".env"]

The agent can inspect the schema, but it cannot read or modify the file containing the actual values.

When the agent needs to call an API, the Agent Proxy gives it a placeholder and injects the real credential only when the request matches the configured policy.

For example, the agent might be allowed to make:

GET https://api.github.com/user

while requests to unrelated hosts, different paths, or destructive endpoints are denied.

This creates a useful separation:

• configuration discovery is not credential disclosure
• having access to a credential is not unrestricted API access -filesystem access is not automatically part of agent access

The important part is that the real values are not placed in the agent’s environment in the first place. Blocking .env reads protects the file, while the proxy controls when a credential is actually used.

Agents need context to work effectively. They don’t necessarily need every secret in that context.

CLI schema command: https://docs.stashbase.dev/cli/commands/secrets#schema

Agent Proxy and filesystem restrictions: https://docs.stashbase.dev/agents

Stashbase: https://stashbase.dev