Run agents on your own keys with user-scoped secrets

You don’t hand a colleague your GitHub token. Neuro OS applies the same rule to agents: secrets can be scoped to the individual human, not only to the company. Each user stores their own value for a secret, and Neuro OS checks that the human behind a session has supplied what it needs before the session starts.

Company-wide keys work for one person. The moment a second human joins, they either borrow someone else’s credentials — or they can’t run agents at all.

One value per secret was never enough

Until user-scoped secrets, a secret held one company-wide value. That model still exists for shared infrastructure — a Slack bot, a warehouse read key, a shared vault entry. One value works when the credential truly belongs to the company.

It fails the moment the credential belongs to a person: a GitHub PAT, a personal API key, a bring-your-own model subscription. Then “one secret for the project” becomes either a shared god key or a blocker for every new teammate.

How it works

The pieces land in order:

1. A secret definition can be user-scoped. Each user stores their own value for it. Definitions still live with the project — as files and policy, not as a silent dashboard setting.
2. Definitions bind to environments. The sessions and agents that need a credential declare it. No undeclared keys in the sandbox.
3. Responsible-user attribution. Every session ties to the human it acts for — who started it, whose grants apply, whose secrets resolve.
4. A deterministic check before dispatch. Before a session boots, Neuro OS verifies that this user has supplied the values the run needs. A missing credential surfaces before the agent starts — not halfway through a tool call.

You see the check in the product. If a secret you’re responsible for has no value yet, Neuro OS warns you as you create the task, names the missing secret, and lets you set your value on the spot.

Secret references wherever env lives

Plain environment variables and secret references should not be two different UIs. Neuro OS uses one reusable editor everywhere environment is configured: agents, projects, triggers, and company environments. It handles text values, secret references, draft rows, and sensitive-value warnings consistently — with a clear path to convert a plain value into a secret reference.

That matches the broader connector model: credentials stay out of the sandbox; the control plane resolves what the agent is allowed to use.

Getting started

1. Define a user-scoped secret for the credential that belongs to people, not to the company.
2. Have each teammate store their own value.
3. Bind the definition to the environments and agents that need it.
4. Dispatch — Neuro OS does the check from there.

Company-scoped secrets stay available for true shared infrastructure. Use the narrowest scope that matches ownership.

Groundwork for multi-user and cloud execution

User-scoped secrets are a real prerequisite for safe multi-user and cloud execution. The immediate payoff is concrete:

• The next person who joins supplies their own keys and runs agents the same day.
• Every session is attributable to the human behind it.
• A missing personal key fails closed at dispatch — not as a leaked shared token in a log.

That is the same sovereignty test we apply to models and memory: can you swap what you rent without losing what you own? Your teammates’ keys stay theirs. The project’s operating layer stays yours.

Bring your keys. Keep them yours.

Define a user-scoped secret, let each teammate fill their value, and run agents without sharing personal tokens. Explore Neuro OS.

Explore Neuro OS →