Somewhere in your agent deployment there is a long-lived credential. An API key in an environment variable, a token in a keychain, a secret in a config file. It was issued months ago, it rotates never, and it is in the possession of the single most manipulable piece of software you run: an agent that ingests untrusted text all day and sometimes does what the text says.
We have spent this year attacking that problem from one side: possession. nono brokers credentials per invocation. The agent makes plain requests; a broker it cannot reach injects the secret, uses it once, and zeroes it from memory. The agent's environment holds placeholders. Full compromise of the agent yields the ability to make requests through policy, and nothing else. That architecture is shipped, audited to the syscall, and running in production today.
But brokering has an honest limit: the thing being brokered is still a static secret. It still exists. It still lives somewhere on the host, still rotates on human schedules, and if it leaks by any path outside the broker, it works for whoever holds it, from wherever they are.
The next move is to attack the credential itself.
Identity instead of secret
SPIFFE inverts the model. Instead of proving "I hold the key," a workload proves "I am this workload": the platform attests the process (its binary, its unix identity, its pod, its node), and an agent called SPIRE issues it a short-lived, automatically rotating identity document, an SVID. Two forms matter here: a JWT-SVID, a signed token asserting the workload's identity for a bounded audience and lifetime, and an X.509-SVID, a certificate for mutual TLS.
The properties are exactly the ones a long-lived API key lacks. The credential is issued to the workload, not to whoever possesses a string. It expires in minutes, not quarters. Rotation is continuous and automatic, not a ticket in someone's backlog. And it is attested: the workload presents no secret to the Workload API, because the SPIRE agent verifies the caller out of band against what the operating system knows about the process, then issues only if those observable properties match the workload's registered selectors.
That last property is worth stating precisely, because it is where the strength actually lives. Attestation binds an identity to a selector match, not to a name. Register a workload by unix uid alone and every process running as that uid satisfies the entry. Register it by binary path and SHA-256 and the bar is considerably higher. SPIFFE gives you the mechanism; the selectors you choose decide what the mechanism is worth.
What we built
The work in flight (PR #1272, in review in the open) makes workload identity a first-class credential source for nono's broker routes:
At startup, nono connects to the SPIRE Workload API socket and obtains SVIDs for the supervisor. Fail-closed: no identity, no session. There is no degraded mode where the workload runs unidentified.
The broker requests a JWT-SVID scoped to the upstream audience and injects it per invocation, exactly as it injects any phantom credential: the sandboxed agent makes a plain request and never sees the token that authenticated it. Tokens refresh before expiry through the agent cache, and SVID private key material is never written to disk or logged. The division of labor is clean: the SPIRE operator registers the workload entry and configures the agent, and nono's config is just the socket path and what to request.
X.509-SVID mTLS, with a client certificate presented during the handshake and rotated atomically, is the planned next variant. It waits on the TLS-intercept CONNECT path being wired to support it for HTTPS upstreams. Saying so is the point of working in the open: the JWT path is what exists today.
The injection path this rides on is protocol-consistent: HTTP/2 forwarding enforces the same credential rules as HTTP/1.1, with regression tests pinning the parity. And every brokered invocation lands where everything in nono lands: the audit trail, sequence-numbered, hash-chained, Merkle-committed, written by a process the agent cannot touch.
Stack the two layers and count what an attacker has to work with. The agent never possesses the credential: that is the broker. The credential barely exists: that is SPIFFE. What is left to steal is a token that expires in minutes, is scoped to one audience, was issued to an attested workload, and never entered the attacker's reachable memory in the first place.
Where this goes
This is also the enterprise on-ramp the MCP ecosystem has been circling. SEP-1933, the proposed standard for Workload Identity Federation in MCP, specifies exactly this credential shape: a workload identity token exchanged for an OAuth access token, so an MCP client authenticates as an attested workload instead of carrying a provisioned secret. The proposal's client conformance suite merged upstream this month. A broker that already produces per-invocation JWT-SVIDs is most of the way to that exchange.
Come watch us attack it
On Tuesday, July 28 at 4pm UK / 11am ET, Aleksy Siek, founding maintainer, runs the whole thing live: a real agent workflow, credentials brokered per invocation from a SPIRE identity, zeroed after use, audit trail from policy decision to syscall. Then a live attack attempt against the running system, while you watch. If something breaks, you see that too: a demo that cannot fail is just a video.
Register at luma.com/73tz35ak: the stream link goes to registrants.
If you want to walk the setup yourself before or after, you do not need to stand up full SPIRE infrastructure to try the pattern: spiffecli gives you a Workload API with one command, and the PR is open for review at nolabs-ai/nono#1272. The hard question you bring is the feature someone else needs. Last time that happened, it shipped in eight weeks.
Go deeper
- Credential Injection — the per-invocation broker and phantom-token pattern this identity work rides on
- Runtime Supervisor — the trusted parent that obtains the SVID at startup and brokers every request
- OS Sandbox — the kernel-level isolation that keeps the credential out of the agent's reach
- Audit Trail — how every brokered invocation lands in a hash-chained, tamper-evident record
This post is part of a series on agent infrastructure that assumes compromise. The thesis, and where it leads: Assume the agent is compromised. Now what?