Secrets
Keep the API keys and tokens agents' tools need, by name, and release them only to signed-in machines.
Agents' tools often need a credential: a tracker's service token, a model provider's API key. Instead of each person pasting it into their machine, you keep it once in the console, by the name the tool expects. A machine asks for the secrets a project may use when a session starts. For tools, the workbench's gate holds the value and the agent is given a stand-in, never the value itself. Once a value is in, nobody can read it back from the console.
Where secrets are kept
| Kept by | Who manages it | Where |
|---|---|---|
| Your organisation | Administrators | Secrets |
| One of your teams | Administrators | Secrets |
| A project | The project's owners | The project's Policy tab |
| One repository of a project | The project's owners | The project's Policy tab |
| You alone ("Yours") | You, and nobody else | Secrets |
Anyone on a project sees the names and facts of the secrets it may use, never the values. Your own secrets are seen by nobody else, administrators included.
When two secrets share a name:
- one your organisation or a team locked wins over everything of its name;
- otherwise the most specific wins: a repository's over the project's, the project's over a team's or the organisation's;
- your own fills a name nothing shared carries, and replaces a shared one only where that one says People may use their own value of this name instead.
In Mojo Up AI Cloud, a team's owners and admins act as its administrators.
Add a secret
Open the page
For the organisation or a team, open Secrets. For a project or one of its repositories, open the project and its Policy tab. Choose Add a secret.
Describe it
- Name, as the tool expects it, for example
TRACKER_TOKEN. - Value: sealed on the way in, never shown again.
- Kept by: your organisation, your team, this project or this repository.
- What it is for: a sentence people will see.
- Remind us to rotate it after (days): optional. Past that age, the secret is marked Due for rotation and counted at the top of the list. Once per version, a project's owners get a reminder in the project's inbox; for your organisation's, a team's or your own, the people who keep it get a notification on their phone.
- Locked (your organisation's or a team's): nothing else of this name is used, not a project's and not a person's own.
- People may use their own value of this name instead (any shared secret): a person's own secret of the name replaces it for them, for example a personal API key where the team offers a fallback.
- Follow me to the nodes I let run my work (your own): see Your secrets on nodes.
- Only send it to (for tools): host names, or
*.example.com. A tool server for any other address is refused the value, whatever a repository's configuration says.
Say what may use it
Under Used by, tick one or more:
| Use | Who holds the value |
|---|---|
| Tools | The workbench's gate holds it; the agent never sees it. |
| A model provider | The inference proxy holds it. Name the provider, for example anthropic. |
| The agent's environment | The agent can read it. The only use that exposes the value to the agent. |
Keep it
Choose Keep it. Machines get it at their next ask.
Rotate, disable or remove
Beside each secret you manage:
- Rotate asks for a new value, seals it, and raises the secret's version. Machines get the new value at their next ask.
- Disable keeps the secret but releases it to nobody; Enable brings it back.
- Remove deletes it. Machines lose it at their next ask.
Your secrets on nodes
A secret of yours stays on your own computers unless it says Follow me. Then it is given to a node only when:
- your organisation allows it: Rules for secrets, Following people to nodes;
- you let that node run your work: on Secrets, Nodes that run your work, choose Let it run my work (an administrator may also assign you);
- the node is running a session for you at that moment.
A node's operator can read what a node is given. A node that is refused or removed loses the right at once.
Rules for secrets
Administrators set these on Secrets, Rules for secrets. They are served to every workbench and node whether or not a policy is published; a published policy with its own secrets section wins.
| Rule | What it decides |
|---|---|
| People's own secrets | Whether a person's own value may be used in your projects. |
| Following people to nodes | Whether a secret that says Follow me may be given to a node. Off by default. |
| Secrets in an agent's environment | Whether any secret may be placed where an agent can read it. |
| A machine's own environment in tool settings | Whether a repository's tool servers may read the machine's environment variables. |
| Machines without a key store | Whether a machine with no operating-system key store may keep shared secrets. |
| Nodes act only for people who agreed | Just their own (the default): only a person's secrets that follow them need their say. Every secret: a node is given no secret at all for a person who has not let it run their work or been assigned by an administrator. |
Who gets a secret
A machine asks for the secrets one project (and one of its repositories) may use. It gets them only when:
- it is signed in to your organisation;
- the person it works for is a member of the project (a node names that person, and must name the secrets it needs);
- the secret is not disabled.
Every release is one entry in the audit trail, naming the secrets, their versions and scopes, never a value. Machines report what they used, so each secret shows when it was last used and how often. When a secret changes, machines working on the projects it reaches are told at once and ask again; they do not wait for their lease to end.
In the workbench
People can keep secrets on their own machine too, under Settings, Secrets in AI Workbench, which also shows what each repository asks for and what the organisation provides.
Microsoft setup commands
Every command to run in your Microsoft tenant for Agent 365, Microsoft 365 grounding, Purview and Sentinel, in order, with the role ids filled in.
Cloud agents
Let team members hand tasks to a provider's cloud agent (GitHub Copilot, Cursor, Claude Code, Codex and others), and see every run.