Coding agents can run tests, call APIs, manage infrastructure, and work with local developer tools. That usefulness eventually collides with credentials.
The common options are uncomfortable: paste a token into a prompt, leave it in a broad environment variable, or let every subprocess inherit the same secret.
I built s-gw to put a local approval boundary between the agent and the credential.
Give the agent a handle, not the secret
The agent receives a typed handle that identifies the credential it needs. When it wants to act, s-gw shows the exact command, credential, environment binding, working directory, policy, and destination for local review.
The agent can request useful access without reading or retaining the raw value.
Keep execution inside one local trust loop
After approval, s-gw resolves the credential locally and injects it into one bounded child process. The command runs with the approved scope, then the output is sanitized before it returns to the agent.
The flow is:
- The agent sends a typed handle and an action request.
- The policy engine validates the request.
- You review and approve the command locally.
- The credential enters only the approved process.
- Sanitized output returns to the agent.
- The local activity log records the request, decision, and destination without recording the raw secret.
This is not meant to make a coding agent trusted. It makes credential use narrower, visible, and revocable.
See where credentials are being used
The local usage map connects agents to authentication types and destinations. It helps answer practical questions: Which agent used an AWS key? Which targets are receiving the most credentialed actions? Is an old handle still active?
Current status
s-gw is open source preview software, not a hardened enterprise secrets platform. macOS is the primary path today, Windows is preview, and Linux is experimental.
Install it from npm:
npm install -g @s-gw/s-gw
Repository: github.com/sgateway/s-gw
Interactive demo: s-gw.com
I would especially value feedback from people using coding agents with API tokens, SSH keys, cloud credentials, local MCP tools, or 1Password. What would you need to see before letting an agent use a real credential?



Top comments (0)