been thinking about this exact problem for a while. my own setup uses OS keyring with a <secret:name> token substitution pattern — the agent requests a credential by name, the substitution happens at execution time, the LLM never sees the raw value in context or logs. works reasonably well.
but the problem with that model is it's static protection. if the agent process itself becomes hostile or gets prompt-injected, keyring doesn't really help — it can still request the secret and get it, it just doesn't see it in the context window.
the shift i've been landing on and building into Orbital(my own project) is that it's less about blocking credential access and more about supervising it. you want to know exactly when and why the agent is requesting something, and have the ability to approve or deny in the moment. pre-set policies are hard because you genuinely can't anticipate what tools an agent will call before it runs — claude code might use curl, bash, or a completely random command depending on the problem. the approval needs to happen at runtime, not preset.
the proxy model here is interesting because it creates a natural supervision boundary. curious whether you're planning runtime approval flows or if the design stays policy-based.
@10keane The proxy approach also solves the audit trail problem implicit in what you're describing. With OS keyring substitution, the agent receives the credential and you can't observe what happens next — the log shows intent (substitution happened) but not effect (what API calls were actually made). Routing through a proxy gives you an immutable record of every call made with each credential, which is the more useful thing for incident response: not "did the agent have access?" but "what did it actually do with it?"
The capability-scoping gap you're pointing at (static vs. dynamic trust) is the next layer up — effectively per-session IAM roles minted at task time, scoped to the specific endpoints the task actually needs. That's harder but it's the right direction.