This is a solid draft. glad to see it building on SPIFFE/WIMSE and OAuth rather than inventing new identity primitives. The "agents are workloads" framing in Section 3 is exactly right and should settle the debate about whether agents need their own identity model.
The Transaction Token pattern (Section 10.4) is particularly important. We arrived at something similar — short-lived ES256-signed tokens scoped to a single task with a 60s TTL, encoding the specific tools and operations authorized. The key addition we found necessary: embedding data classification and governance evidence in the token itself, so the token isn't just authorization ("you may call this tool") but also proof that scanning and policy evaluation happened. Makes the audit trail self-verifying.
One gap I'd flag: the draft covers the auth layer thoroughly but doesn't address the data protection layer: what happens to the content flowing through these authenticated channels. An agent can be
perfectly authenticated and authorized to call an LLM, and still send PII or credentials in the prompt. That's a different control plane (content scanning, classification, taint tracking) that sits
alongside auth, not inside it. Might be worth a forward reference to indicate this is complementary scope.
The static API keys antipattern callout in Section 6 is important. In practice, most agent deployments today still use long-lived API keys passed as environment variables. The gap between what this draft recommends and what people actually do is enormous.
jensbontinck•36m ago
The Transaction Token pattern (Section 10.4) is particularly important. We arrived at something similar — short-lived ES256-signed tokens scoped to a single task with a 60s TTL, encoding the specific tools and operations authorized. The key addition we found necessary: embedding data classification and governance evidence in the token itself, so the token isn't just authorization ("you may call this tool") but also proof that scanning and policy evaluation happened. Makes the audit trail self-verifying.
One gap I'd flag: the draft covers the auth layer thoroughly but doesn't address the data protection layer: what happens to the content flowing through these authenticated channels. An agent can be perfectly authenticated and authorized to call an LLM, and still send PII or credentials in the prompt. That's a different control plane (content scanning, classification, taint tracking) that sits alongside auth, not inside it. Might be worth a forward reference to indicate this is complementary scope.
The static API keys antipattern callout in Section 6 is important. In practice, most agent deployments today still use long-lived API keys passed as environment variables. The gap between what this draft recommends and what people actually do is enormous.