Agents can request secrets only when they need them
On-demand secret access in Neuro OS: agents request approved secrets through the API when a task needs them — not for the whole session — and every request is audited.
Discuss this post in AI
Send a pre-filled prompt to ChatGPT, Claude, Gemini, or Perplexity — get a summary, ask follow-ups, or compare ideas from this guide.
Secret access in Neuro OS lets agents request approved secrets through an API when a task needs them. The secret does not have to sit in the environment for the full session, and Neuro OS logs each request.
Environment variables work well when an agent needs the same secret on every run. But the value then remains available for the whole session — even when the agent never uses it. Injection also does not record when the agent read the value.
Teams can choose how each secret reaches each agent, and review on-demand requests in the project audit trail.
Least privilege is not only which tools an agent may call. It is also when a credential exists in the session at all.
How secret access works
On-demand secret access has three parts:
- Choose which secrets the agent can request. Open the agent’s settings and add each permitted secret under Secret access. An omitted grant is still deny — same pattern as connectors in
neuro.yaml. - Let the agent request a value when it needs one. During a session, the agent can list permitted secret names and request one value through the API. Temporary review-only or skill-test sessions cannot request values.
- Review each request. Neuro OS records every request in the security audit trail and the operator activity log — agent, secret name, session, human attribution, and outcome.
Choose which secrets an agent can request and how Neuro OS delivers each one: always-on environment injection, or on-demand claim.
Choose when the secret is available
Use an environment variable when the agent needs the secret on every run — a shared warehouse reader, a bot token that is always in play.
Use on-demand access when the agent needs the secret only for a specific task. That keeps the value out of every session that does not need it, and it gives you a record each time the agent requests the value.
That sits beside user-scoped secrets: the who owns the value, and secure tool access: credentials stay out of the sandbox unless the control plane resolves them. On-demand secret access is the when.
Getting started
- Open an agent’s settings → Secret access.
- Choose one secret the agent is allowed to request.
- Prefer on-demand for occasional credentials; keep always-needed secrets in the environment.
- Run a real task and confirm the audit row appears when the agent claims the value.
Find an agent by name when the same secret is granted to more than one agent — grants stay per agent, not “everyone who can see the project.”
Always-needed vs occasional
Teams can now keep always-needed secrets in the environment and request occasional secrets only when the work requires them. A support agent that sometimes needs Stripe write access should not carry that key on every triage session. A release agent that always talks to GitHub may keep that path as environment injection — still scoped, still audited at the connector layer.
The model is boring on purpose. You should be able to answer “could this agent have seen that key on this run?” from the audit trail, not from a hope that the prompt was careful.
Request the secret. Not the whole vault.
Grant one secret, prefer on-demand when the task is rare, and keep the company keys out of every idle session. Explore Neuro OS.