Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Keeping the real credential out of model context is a meaningful improvement, but the gateway still becomes a confused-deputy boundary. How granular are policies below the endpoint level? An agent allowed to call a CRM API may still be tricked into exporting the wrong customer or changing a field it should only read. I'd be interested in whether policies can constrain method, path, request fields, resource ownership, and response volume, and how those rules are tested against prompt injection.


The testing half of your question is where I'd push hardest, because it's the part that tends to be untested by construction.

Method + path + body matching is necessary but blind to provenance. GET /customers?limit=5000 looks identical whether the operator asked for it or a retrieved document did. The gateway sees a well-formed request that a policy permits what makes it an exfiltration is what entered the context window three steps earlier, and the egress boundary structurally cannot see that.

The approach we landed on binds the decision to the trajectory rather than the request: which retrieved content or tool result preceded this call, and whether any argument value originated in untrusted text. "This field traces back to a retrieved document" turns out to be a much stronger signal than any endpoint allowlist.

On testing them static policy unit tests pass trivially. What actually finds things is adversarial replay: take real traces, inject at the retrieval and tool-result boundaries, re-run, check the policy still holds. Multi-turn matters most, since single-turn injection suites miss the case where every individual step is permitted and only the sequence is the attack.

Response volume is the most under-implemented control on your list, and probably the cheapest one to add.


OneCLI controls what the agent can reach. It doesnt control where it runs. Block a leaked key and the process is still on your host, so a bad rm or a prompt injected "clean up this repo" still hits real files. So I would stack them, not pick one. Sandbox the agent so it can't touch anything you care about, then route egress through a policy layer like this. Reach and blast radius are different problems:)


record level credential scoping



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: