Hacker News Reader

Comment by eli | Hacker News Reader

It’s injected into an outbound api call, not into an env var the agent can read.

what's to stop an agent creating an outbound call with the var to a malicious endpoint? (unless you whitelist what it has access to)

You just don't inject the real secret unless hostname/whatever rule matches the request, right? I don't know if that's how this works but it's my assumption.

On the Docker DevRel team... yes! This is it. The secret is injected only into headers in which the hostname matches.

There's also an ability to create kits where you can setup credential injection into other services as well.

At least for gondolin and microsandbox, you bind a specific secret placeholder to the target host. i.e. your GH token is only replaced/injected for calls to api.github.com, not other hosts. And you can set up both with deny-by-default

But then... why is replacent needed at all: just use sone permissions system.

Couldn't the agent post then the key in some public comment?

Only if the replacement is global and not, say, only looking and inserting it into the actual (eg) Authorization header. If something is only transparently altering the Authorization header, then an agent inserting the dummy value somewhere else is totally safe.

For clarity, there is no "search and replace" function going on. It's only setting the header.

The main reason a "proxy-managed" env var is set is because most CLI tools assume if the env var is set, auth is set. If the env var is unset, it will assume auth needs to occur. Fortunately, most don't do a pattern matching on what the value actually is.

The replacement is on a url/host basis.

or an outbound call to a trusted endpoint with the env var in a way that can get exposed to the agent via a subsequent call?

It's possible reflected instances are masked too, like GitHub Actions. But I don't know.

How would that work, exactly? What are you envisioning?

Reply on news.ycombinator.com