AgentSH v0.18.0: Real Secrets Stay Out of the Agent

Two customer requests kept coming up.

Can an agent use real credentials without ever being handed the real credentials?

And can we let an agent talk to a third-party API or an internal service, but only on the methods and paths we actually approve?

AgentSH v0.18.0 is our answer to both.

This release adds two major capabilities:

• a Secrets Manager with support for external secret stores and third-party vaults
• an HTTP service gateway that lets you control outbound API traffic by service, method, and path

The repo is here: github.com/canyonroad/agentsh

It is not enough to say an agent may reach api.github.com or api.stripe.com. Once the agent has a live token and broad network access, the difference between acceptable behavior and a production side effect is usually just a verb and a path on the same host.

Policy at the HTTP layer, not just the host

The most important design choice in v0.18.0 is that declared upstream services are fail-closed by default.

Because AgentSH runs inside the execution boundary, it can inject a service-specific base URL into the child process environment so traffic flows through the governed gateway.

For less cooperative clients, AgentSH still gives you a hard control point. If a host is declared as a governed upstream, direct HTTP and HTTPS access to that host is blocked unless you explicitly allow it.

That is not an implementation detail. It is the security posture.

Without that boundary, "we monitor requests" usually means "we noticed the write after it happened." With it, policy can decide whether the request is allowed before the side effect leaves the machine.

The new HTTP gateway lets you express that policy directly:

• allow or deny specific URLs
• allow or deny specific HTTP verbs
• require approval for sensitive operations
• audit traffic that should be observed but still forwarded

A hostname is too coarse for real agent permissions. The difference between reading GitHub issues and opening one is not a different host. It is GET /repos/*/*/issues versus POST /repos/*/*/issues.

That matters because agents do not always stay inside the interface you expected them to use. When one path is blocked or a tool does not work, they may look for another way to accomplish the same task. An agent that cannot run npm publish directly may figure out the underlying HTTP requests needed to publish anyway. If your control is only at the tool layer, the side effect can still slip through. If your control is at the HTTP method-and-path layer, you can stop the write even when the agent changes tactics.

That is the boundary v0.18.0 lets you control.

Secrets Manager with third-party vault support

Most teams do not want long-lived API keys sitting in prompts, shell history, .env files, or process environments. They want the agent to use a credential without actually possessing it.

That is what the new Secrets Manager is built for.

In v0.18.0, AgentSH can pull secrets from external providers including Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, 1Password Connect, and the local OS keyring.

At session start, AgentSH fetches the real secret, generates a fake credential for the agent to work with, and keeps the real value on the governed side of the boundary.

The agent sees the fake value. On egress, AgentSH swaps the fake value for the real one before the request leaves the machine.

Substitution can happen in headers, bodies, query strings, and URL paths. And if a service expects the credential in a specific header, AgentSH can inject it directly there.

That gives teams a much better operating model. The agent does not need raw production credentials in memory, logs are less likely to capture real secrets, rotation stays in the vault instead of getting pushed into agent code, and response scrubbing can remove sensitive values before they come back.

Because this lives in AgentSH rather than in a specific hosted sandbox, the same secrets model travels with you across sandbox providers and self-managed environments wherever AgentSH runs.

There is another important piece here: leak guard.

If the fake credential shows up in the wrong place, AgentSH can block the request before it leaves. That helps catch cross-service misuse and exfiltration attempts where a credential-shaped value is being sent somewhere it does not belong.

A concrete example

A common customer ask looks like this:

"Let the agent read issues from GitHub, but do not let it create or modify anything. Also do not hand it the real token."

With v0.18.0, that becomes a policy problem instead of an application rewrite.

providers:
  vault:
    type: vault
    address: https://vault.corp.internal
    auth:
      method: token
      token_ref: keyring://agentsh/vault_token

  keyring:
    type: keyring

http_services:
  - name: github
    upstream: https://api.github.com
    aliases: [api.github.com]
    default: deny
    secret:
      ref: vault://kv/data/github#token
      format: "ghp_{rand:36}"
    inject:
      header:
        name: Authorization
        template: "Bearer "
    rules:
      - name: read-issues
        methods: [GET]
        paths:
          - /repos/*/*/issues
          - /repos/*/*/issues/*
        decision: allow

      - name: create-issue-needs-approval
        methods: [POST]
        paths:
          - /repos/*/*/issues
        decision: approve
        message: "Agent wants to create an issue. Approve?"
        timeout: 5m

The agent gets a GitHub base URL that points at the local AgentSH gateway. It does not get the real GitHub token. Reads go through. Writes can be blocked or held for approval. Direct access to the upstream host can be closed by default.

Why this matters

The usual alternatives are broken: hand the agent a real secret and hope prompts and tool descriptions keep it contained, allow an entire host and pretend that is a meaningful permission boundary, or bolt on audit after the fact and call it control.

None of that holds up once the agent is making real outbound requests against real systems.

The agent proposes. The policy decides.

In v0.18.0, that principle now extends further into the HTTP layer: this request, on this path, with this verb, using a real credential the agent never gets to see.

Also in v0.18.0

This release also adds HMAC-chain tamper evidence for audit logs and a broad set of enforcement fixes across seccomp, cgroups, Landlock, ptrace, and arm64 support. For the full release details, see the changelog in the repo.

Try v0.18.0

If you are running agents against third-party APIs, internal services, or production-adjacent systems, v0.18.0 gives you a practical way to let agents act without giving them raw authority.

AgentSH is open source: github.com/canyonroad/agentsh

← All posts