Centralizing API keys is convenient, but should the agent ever see them?

I came across a Show HN post this week about an open source project called OneCLI, and one part of the design has been stuck in my head.The agent never gets the real credential. It receives a placeholder, sends the request through a separate gateway, and the gateway swaps in the actual key only if the service and path are allowed.That feels lowkey different from putting every secret on an environment variables page.For context, I work on Enter Pro, so I am obviously not a neutral observer here. We already centralize project secrets and model access, but the OneCLI design made me realize that central storage still does not answer the harder question: should the agent ever receive the credential at all? Centralization helps with management. It does not fully solve trust.I keep wondering if AI builders should treat secrets less like strings and more like temporary permissions. The agent could receive something like `PAYMENTS_READ` or `GITHUB_PR_WRITE` instead of the underlying token. The platform would inject the real credential only for approved hosts and actions, log each use, and pause for confirmation before payments, destructive database changes, or requests to a new domain.The tradeoff is pretty obvious. You add another gateway, more policy config, and probably a pile of annoying approval prompts if it is designed badly.But once agents are doing more than generating files, ""the key is stored securely"" feels like a much lower bar than ""the agent never had the key in the first place.""Would that actually make you trust an AI builder more, or would you rather manage that extra layer yourself?