Secrets
Store the keys and values a goal's agent needs, decide whether its code can read each one, and check that a hidden value stays hidden.
A secret is a value the agent's code needs but that must not live in the goal's repository: an API key, a token, a database connection string. Auto Lab encrypts each value with a key unique to the goal and delivers it only to the agents you allow.
When to use a secret
| You want the agent to | Use |
|---|---|
| Work in an app such as Gmail or a CRM | A connector. Its credentials never reach the agent's machine |
| Sign in to a website | A website login |
| Run code that calls an API or a database with a key | A secret |
To use your own model provider key, see Models.
Goal secrets and personal secrets
- Goal secrets are shared by the goal. Manage them in Settings › Secrets, which is also Brain › Secrets. Changing them needs permission to manage the goal's secrets.
- Personal secrets are your own value for a key, used instead of the shared value in sessions you start. Manage them in Personal settings › Secrets. See Use your own value.
Add a secret
Open the dialog
In Settings › Secrets, select New › Set up manually. New › Create in chat asks an agent to set it up for you instead.
Name it and paste the value
Enter the key the code reads, such as STRIPE_API_KEY, and the value. Leave Identifier blank unless you keep a second value under the same key, such as a backup key. Names starting with KORTIX_ are reserved.
Choose who can read it
Answer Can your code read this value? with one of the options below, then select Save.
Choose who can read the value
| Option | What the agent's machine holds | Use it for |
|---|---|---|
| Environment variable (the default) | The real value | A key the code signs requests with, a protocol that is not HTTPS, an API that only accepts Basic auth |
| Enforce at the network | A stand-in value. Auto Lab swaps in the real value on the way out, only for hosts you approve | An HTTPS API that takes the key in a header, a query parameter or the request body |
| Disabled | Nothing | A value you keep on file without delivering it |
Environment variables are readable
A value on Environment variable is readable by every command the agent runs. The agent can read it, print it or send it anywhere, and Auto Lab cannot hide or track it. Choose Enforce at the network for any key that only needs to reach an HTTPS API.
Enforce at the network is still marked experimental. It is on by default, and turning off Network-Enforced Secrets in Settings › Feature flags hides it. A secret that already uses it keeps working.
Three other labels can appear in the Access column: LLM gateway, Connector and Git. Auto Lab assigns them when you connect a model provider, bind a connector or connect a repository, and you cannot change them here. What each Access value means, at the top of the page, explains every label.
If you paste something that looks like a signing key, such as an AWS access key or a PEM or SSH key, the page keeps it on Environment variable and says why. Code has to hold a signing key to compute with it.
Approved hosts
With Enforce at the network, list every host the key is for under Hosts, one per line. Use exact HTTPS host names. Wildcards, paths and ports are refused, and api.example.com does not cover uploads.api.example.com. A request to any other host carries only the stand-in, which is worthless on its own.
Code written for the real key works unchanged with the stand-in. The one exception is HTTP Basic auth, which encodes the value on the way out, so Auto Lab can no longer recognise it and swap it. For an API that accepts only Basic auth, keep the secret on Environment variable.
Calls to an approved host go through Auto Lab, which changes a few things:
- Streaming does not work, so server-sent events and websockets fail.
- A request body can be up to 1 MiB, a response up to 5 MiB, and a call up to 30 seconds, with at most 3 redirects.
- A program that ignores the machine's proxy settings calls the host directly, and sends only the stand-in.
Check that the value stays hidden
Two checks tell you the swap works. Run them inside the agent's machine, for example by asking the agent in a session to run them. The example uses postman-echo.com, which has one endpoint of each kind. Add it to the secret's Hosts for the test, and remove it afterwards.
# 1. Reachability: an endpoint that does not echo headers back
curl -s -o /dev/null -w '%{http_code}\n' https://postman-echo.com/status/200
# expected: 200
# 2. Substitution: an endpoint that echoes headers back
curl -sS -H "authorization: Bearer $STRIPE_API_KEY" https://postman-echo.com/get
# expected: 200, with "Bearer [REDACTED]" in the echoed headers
Look at check 1 before check 2. If the host cannot be reached, check 2 tells you nothing about the secret.
| Check 2 result | What it means |
|---|---|
200, and the header shows [REDACTED] | It works. The real value went out, and Auto Lab hid it in the echo |
200, and the header shows the stand-in | The swap did not happen. Check the host list and the agent's grant |
401 from a real API | The swap did not happen. Check the same two things |
| An empty reply or a connection error | Something else is wrong: the host, the network or the command |
Then confirm that the machine holds only the stand-in:
env | grep '^STRIPE_API_KEY='
# expected: the stand-in value, not your key
Give an agent a secret
A secret arrives in the machine where the agent runs commands: a session, or the machine a task agent works in. Which agents receive which secrets is set per agent: open Brain › Agents, select the agent, and set Secrets to All, Pick or None.
- A goal with no agent list gives every agent every Environment variable secret.
- An Enforce at the network secret reaches an agent only when that agent names it with Pick. All does not count. Until then the Access column shows No agent grant, and editing the secret offers to grant it to an agent.
The first grant changes every agent
When the goal has no agent list yet, granting a secret to one agent writes the first list. From then on, an agent that is not listed receives no goal secrets at all, including environment secrets that worked before. Auto Lab asks you to confirm first. List every agent that needs secrets.
Change or remove a secret
- Replace the value. In the row's menu, select Edit secret, paste the new value and select Save. Running sessions receive it shortly. This is best effort, so a session that misses it picks the value up when it restarts. An Enforce at the network secret needs nothing more: the next request uses the new value.
- Remove it. Select Delete shared value, then Delete. The value cannot be recovered. A session already running may keep the old value until it restarts.
- Required secrets. The goal manifest can mark a key as required. An unset required key shows a warning. Sessions still start, but the agent is missing that value.
Use your own value
In Personal settings › Secrets, choose the organization and the goal, then select Add personal secret. Enter the Environment key and the Secret value.
- Your value replaces the shared one in sessions you start. Other members never see it.
- Pause my override goes back to the shared value until you select Resume my override. Remove my value deletes it.
- The goal's delivery rules and agent grants still apply. A key that exists only as your personal secret reaches your sessions as an environment variable.
- Model provider keys cannot be personal. They are set up under the goal's models.
Hand over a value without seeing it
Someone else can enter a key through a secret link, so the value never passes through you or through Chat. See Hand over a key without seeing it.