At Black Hat this week, the Open Secure AI Alliance, a coalition NVIDIA launched in July with 37 founding members including Microsoft, IBM, Cisco, Cloudflare, and Red Hat, published a Request for Comments on something called SAFE: Shared AI Findings Exchange. The pitch is blunt. Agentic AI incidents keep happening in isolation, one company at a time, with no shared channel to disclose what broke and how. SAFE proposes a CVE-style pipeline for agent failures: collect incidents confidentially, identify recurring control failures, publish evidence-based fixes.
That is worth a post on its own, but the detail that stopped me was upstream of SAFE: the alliance’s identity work. HPE is contributing SPIFFE and SPIRE, the zero-trust workload identity standards already used to authenticate microservices in Kubernetes and service meshes, and repurposing them to answer a question nobody in production agent systems has cleanly answered yet: when an AI agent calls a tool, hits your API, or touches a database, how do you know which agent it actually is, and on whose authority it is acting?
Why this is the boring problem that matters
I write backend systems for a living, and this is the same problem I solve every day with JWTs and Postgres row-level security, just wearing a new costume. A service account calling your API presents a credential; you verify it cryptographically; you scope what it can touch. An LLM agent calling a tool today mostly does not do that. It runs inside a harness with whatever ambient credentials the harness process holds, and downstream systems have no reliable way to distinguish “the support bot reading a ticket” from “the support bot that got prompt-injected into reading every ticket in the tenant.” That is not a model problem. It is an identity and authorization problem, and it is exactly the kind of problem SPIFFE was built to solve for non-human workloads before agents existed.
Two concrete pieces from the alliance’s stack are the ones I’d actually reach for:
Cryptographic workload identity (SPIFFE/SPIRE). Each agent process gets a short-lived SVID (SPIFFE Verifiable Identity Document), either an X.509 certificate or a signed JWT, tied to a spiffe://trust-domain/agent-name URI. Downstream services verify the SVID instead of trusting a static API key or an ambient IAM role. It composes cleanly with the row-level security pattern I’ve written about here before: the SVID becomes the thing you put in current_setting('app.agent_id'), verified rather than asserted.
Deterministic policy authorization (Cedar). Amazon contributed Cedar, an open source authorization language, alongside its Strands Agents toolkit. Cedar policies are permit/forbid statements over principal, action, and resource that can be statically analyzed, not just tested at runtime. For an agent harness, that means you can ask “can this policy set ever let the billing bot issue a refund,” and get a real answer instead of hoping your test suite covered it.
Try a simplified version of that Cedar shape below. It is a toy evaluator I wrote for this post, not the real Cedar engine, but the semantics match: forbid always wins over permit, and the default is deny.
About the demo
This is a minimal illustrative parser forpermit/forbid statements, not Amazon’s actual Cedar engine. It runs entirely in your browser; nothing is sent anywhere. Edit the policy text, pick a request, and evaluate.Swap the resource dropdown to Payment::"778" with billing-bot and refundPayment selected and it allows, because a permit rule names that exact payment. Switch the principal to support-bot with the same action and it denies by default: no rule grants it. That default-deny behavior, and the fact that a forbid statement is unconditionally checkable, is the actual point of a language like Cedar over a pile of if-statements in your agent harness.
Where this goes next
None of this is finished. The alliance itself says as much: no single reference architecture, no release schedule, just members shipping pieces in parallel and hoping they compose. But the direction is the right one, and it is the same direction I built into chi, my own multi-agent research harness: an agent’s identity should be something you verify, not something it claims. My next step there is straightforward: give each agent run in chi a SPIFFE ID instead of a bare API key, so a tool call carries a provable “which agent, which run, since when” instead of just a bearer token. If you are building agent infrastructure right now, that is the one-line takeaway worth acting on today: stop trusting the string an agent sends you and start verifying who signed it.