u/radim11

Curious what people are actually running day to day with coding agents.

Not the perfect security model on paper. The setup that still lets the agent get useful work done without you approving every command.

For example, are you closer to:

• Project folder only, with .env, SSH keys, and other sensitive paths blocked, but normal internet access for packages and docs
• A Docker or VM setup with no home directory, a small network allowlist, and no credentials inside the agent
• Full local access, but you stay involved whenever it wants to do something destructive or production-related

Or something else entirely?

I’m less interested in "theoretical" answer and more in what has actually held up once the agent is working on a real project.

I’m curious how people are handling permissions when agents use MCP servers.

We’ve been building an Agent Proxy that lets you:

• Keep API keys outside the agent context
• Restrict which hosts, methods, and paths the agent can access
• Allow or deny individual MCP tools
• Expose only the selected tools to the agent
• Run the same policy with agents like Codex
• Keep an audit trail of proxied requests

For example, an agent can connect to Linear, but the profile can allow only specific tools instead of exposing everything the MCP server provides.

Are you relying on the MCP server’s default tool list and approving or declining tool calls as they happen, or are you controlling which tools are exposed to each agent beforehand?

One thing becoming clear as agents move from chat into code and API calls: “give the agent access to GitHub” is far too broad.

If an agent can read repository issues, should it also be able to create pull requests, modify workflows, delete branches, or access repository secrets? In many cases, the token allows all of those actions even when the task requires only one.

We’re building an agent proxy around this problem. The real credential stays outside the agent process, while each request is checked separately. We currently separate:

1. Network egress
2. Credential availability
3. API host, method, and path rules
4. Filesystem and command access
5. Audit logs for allowed and denied actions

So the same GitHub token could allow reading an issue while blocking repository deletion.

The part I’m still thinking through: should this low-level layer remain deterministic, with a higher-level guardian handling intent and action sequences? Or should policies be expressed directly in agent/tool terms? What are people actually deploying?

One thing becoming clear as agents move from chat into code and API calls: “give the agent access to GitHub” is far too broad.

If an agent can read repository issues, should it also be able to create pull requests, modify workflows, delete branches, or access repository secrets? In many cases, the token allows all of those actions even when the task requires only one.

We’re building an agent proxy around this problem. The real credential stays outside the agent process, while each request is checked separately. We currently separate:

1. Network egress
2. Credential availability
3. API host, method, and path rules
4. Filesystem access
5. Audit logs for allowed and denied actions

So the same GitHub token could allow reading an issue while blocking repository deletion.

The part I’m still thinking through: should this low-level layer remain deterministic, with a higher-level guardian handling intent and action sequences? Or should policies be expressed directly in agent/tool terms? What are people actually deploying?

I’m looking for feedback from people who manage production access, CI runners, or developer tooling.

Passing a broad GITHUB_TOKEN, cloud key, or API key into an agent environment is simple, but it means the agent can use whatever the underlying credential permits.

We’ve been exploring a declarative policy layer around that access:

project = "billing"
environment = "agent-local"

[secrets.GITHUB_TOKEN]
env = "GH_TOKEN"

[[secrets.GITHUB_TOKEN.rules]]
effect = "allow"
hosts = ["api.github.com"]
methods = ["GET"]
paths = ["/repos/acme/*/issues*"]

[[secrets.GITHUB_TOKEN.rules]]
effect = "allow"
hosts = ["api.github.com"]
methods = ["POST"]
paths = ["/repos/acme/*/pulls"]

[[secrets.GITHUB_TOKEN.rules]]
effect = "deny"
hosts = ["api.github.com"]
methods = ["DELETE"]
paths = ["/repos/acme/production-api*"]

The intent is that the same credential can still be used by a developer locally or by an agent in production, but each request is checked against a reviewable policy. The agent does not receive the raw value, and use is recorded.

I’m interested in the operational side more than the agent side:

• Is allow-plus-explicit-deny clearer than allow-only?
• Would host, method, and path rules be useful in practice?
• What would make this safe to review in a PR and workable across dev/staging/prod?

I’d appreciate blunt feedback—especially on what would make this unusable in a real workflows.

I’m looking for feedback from people who manage production access, CI runners, or developer tooling.

Passing a broad GITHUB_TOKEN, cloud key, or API key into an agent environment is simple, but it means the agent can use whatever the underlying credential permits.

We’ve been exploring a declarative policy layer around that access:

project = "billing"
environment = "agent-local"

[secrets.GITHUB_TOKEN]
env = "GH_TOKEN"

[[secrets.GITHUB_TOKEN.rules]]
effect = "allow"
hosts = ["api.github.com"]
methods = ["GET"]
paths = ["/repos/acme/*/issues*"]

[[secrets.GITHUB_TOKEN.rules]]
effect = "allow"
hosts = ["api.github.com"]
methods = ["POST"]
paths = ["/repos/acme/*/pulls"]

[[secrets.GITHUB_TOKEN.rules]]
effect = "deny"
hosts = ["api.github.com"]
methods = ["DELETE"]
paths = ["/repos/acme/production-api*"]

The intent is that the same credential can still be used by a developer locally or by an agent in production, but each request is checked against a reviewable policy. The agent does not receive the raw value, and use is recorded.

I’m interested in the operational side more than the agent side:

• Is allow-plus-explicit-deny clearer than allow-only?
• Would host, method, and path rules be useful in practice?
• What would make this safe to review in a PR and workable across dev/staging/prod?

I’d appreciate blunt feedback—especially on what would make this unusable in a real workflows.

I’m looking for feedback from people who manage production access, CI runners, or developer tooling.

Passing a broad GITHUB_TOKEN, cloud key, or API key into an agent environment is simple, but it means the agent can use whatever the underlying credential permits.

I’ve been exploring a declarative policy layer around that access:

project = "billing"
environment = "agent-local"

[secrets.GITHUB_TOKEN]
env = "GH_TOKEN"

[[secrets.GITHUB_TOKEN.rules]]
effect = "allow"
hosts = ["api.github.com"]
methods = ["GET"]
paths = ["/repos/acme/*/issues*"]

[[secrets.GITHUB_TOKEN.rules]]
effect = "allow"
hosts = ["api.github.com"]
methods = ["POST"]
paths = ["/repos/acme/*/pulls"]

[[secrets.GITHUB_TOKEN.rules]]
effect = "deny"
hosts = ["api.github.com"]
methods = ["DELETE"]
paths = ["/repos/acme/production-api*"]

The intent is that the same credential can still be used by a developer locally or by an agent in production, but each request is checked against a reviewable policy. The agent does not receive the raw value, and use is recorded.

I’m interested in the operational side more than the agent side:

• Would you keep this alongside application config, or manage it separately?
• Is allow-plus-explicit-deny clearer than allow-only?
• Would host, method, and path rules be useful in practice?
• What would make this safe to review in a PR and workable across dev/staging/prod?

I’d appreciate blunt feedback—especially on what would make this unusable in a real workflows.

I’m curious how others are handling credentials for coding agents and agent applications in practice.

The simplest approach is passing a GITHUB_TOKEN, API key, or similar credential through environment variables.

It works, but it also means the agent can potentially:

• Read the credential
• Print it in logs
• Accidentally commit it
• Send it to an unintended destination

We’re building Stashbase, and this is a capability we’re adding to the product.

Our approach:

• The agent makes a normal API request, but the credential is injected only at request time.
• The agent never receives the raw credential value.
• Each credential can be restricted to approved destinations—for example, a GitHub token can only be used with GitHub.

We’re now adding HTTP-level rules on top: allow or deny specific methods and paths per destination.

For example, an agent could be allowed to read GitHub issues and create pull requests, while repository-deletion requests are blocked—even if the underlying token technically has that permission.

This isn’t meant to replace scoped credentials, short-lived tokens, sandboxing, or normal security practices. The goal is to reduce blast radius and put a policy boundary around what an agent can actually do with a credential it needs to use.

This feels especially relevant for agents that execute commands, use MCP tools, or interact with several third-party APIs.

How are you approaching this today: environment variables, scoped or short-lived credentials, sandboxed environments, an internal proxy/gateway, or something else?

Is this something useful you would actually use or not?

I’m curious how others are handling credentials for coding agents and agent applications in practice.

The simplest approach is passing a GITHUB_TOKEN, API key, or similar credential through environment variables.

It works, but it also means the agent can potentially:

• Read the credential.
• Print it in logs.
• Accidentally commit it.
• Send it to an unintended destination.

We’ve been exploring a different approach as part of what we’re building:

• Developers can use the CLI to let local coding agents access approved credentials.
• Agent applications integrate through an SDK in production.
• The agent makes an API call, but the credential is injected only at request time.
• Each credential can be restricted to approved destinations. For example, a GitHub token only works with GitHub.
• The agent can use the API without ever receiving the raw token value.

The goal isn’t to replace scoped permissions, short-lived tokens, sandboxing, or normal security practices.

It’s to reduce the blast radius when an agent needs to call an external service but has no reason to know the credential itself.

This feels especially relevant for agents that can execute commands, use MCP tools, or interact with multiple third-party APIs.

For transparency, I’m building this as part of Stashbase. I’m mainly interested in hearing how others are solving this in real agent workflows.

How are you approaching this today: environment variables, scoped or short-lived credentials, sandboxed environments, an internal proxy, or something else?

I’m curious how others are handling credentials for coding agents and agent applications in practice.

The simplest approach is passing a GITHUB_TOKEN, API key, or similar credential through environment variables. It works, but it also means the agent can potentially read it, print it in logs, accidentally commit it, or send it to an unintended destination.

We’ve been exploring a different approach as part of what we’re building:

• Developers can use the CLI to let local coding agents access approved credentials.
• Agent applications integrate through an SDK in production.
• The agent makes an API call, but the credential is injected only at request time.
• Each credential can be restricted to approved destinations—for example, a GitHub token only works with api.github.com.
• The agent can use the API without ever receiving the raw token value.

The goal isn’t to replace scoped permissions, short-lived tokens, sandboxing, or normal security practices. It’s to reduce the blast radius when an agent needs to call an external service but has no reason to know the credential itself.

This feels especially relevant for agents that can execute commands, use MCP tools, or interact with multiple third-party APIs.

For transparency, I’m building this as part of Stashbase.dev. I’m mainly interested in hearing how others are solving this in real agent workflows.

How are you approaching this today—environment variables, scoped or short-lived credentials, sandboxed environments, an internal proxy, or something else?

I’m curious what everyone’s workflow looks like for managing API keys, environment variables, database credentials, and other application secrets.

How do you handle different environments like development, staging, and production? How do you share secrets with your team and coordinate changes? Do you use a dedicated secrets manager, cloud provider tools, .env files, or something else?

What’s working well with your current setup, and what’s your biggest source of friction?

Full disclosure: we’re building a secrets manager ourselves, which is why we’re interested in hearing how other developers approach this problem. We’re looking to learn what works well today and where existing workflows still fall short.