Hacker News Reader

Comment by kellpossible2 | Hacker News Reader

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)

View on HN

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.

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.

The replacement is on a url/host basis.

Reply on news.ycombinator.com