jensbontinck

This is why governance has to be external to the model. If you ask the model "are you sandboxed?" it will confabulate an answer. If you rely on the model to self-enforce safety rules, it will sometimes comply and sometimes not, depending on the prompt.

The fix is architectural: the governance layer sits between the agent and the model, not inside the model. It doesn't ask the model to behave, it scans what goes in, scans what comes out, and blocks anything that violates policy. The model never sees the blocked content. Fail-closed: if the governance layer goes down, nothing gets through.

Same principle as network security. You don't ask the packet to self-inspect — you route it through a firewall.

Yes, but most are doing it wrong.

The common approaches I've seen: 1. Policy-only ("don't paste sensitive data into ChatGPT") — doesn't work, people do it anyway 2. Network-level blocking (block api.openai.com) — kills legitimate use cases 3. DLP on the network layer — can't inspect the semantic content, just sees HTTPS traffic

What actually works is a proxy-based approach: all LLM API traffic routes through a governance layer that scans the content of every request. PII gets tokenized before reaching the model (SSN becomes [SSN_TOKEN_1], model processes it fine, token gets restored on the way back). Secrets get blocked. Data classification determines which model can be used — RESTRICTED data stays on-prem or goes to a private deployment, PUBLIC data can go to any provider.

The technical challenge is doing this without killing latency or breaking streaming. We got it down to ~250ms overhead with deterministic scanning (regex + normalization, not a second LLM). For streaming responses, you buffer the full response, scan it, then re-chunk — PII never leaks through stream chunks.

The org challenge is that engineering teams will route around any governance that adds friction. The proxy approach works because it's transparent — agents point at "proxy.server.com" instead of api.openai.com and everything else stays the same. Changing env vars, no code changes.

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.

A few patterns we've found effective deploying agents to production:

1. Proxy-based governance. Route all LLM traffic through a governance layer. The agent never holds API keys directly — the proxy holds them and issues scoped, short-lived capability tokens (ES256, 60s TTL). Single enforcement point for scanning, classification, and audit.

2. Scan all message roles. Most people scan user input. In practice, PII and secrets show up in system messages (from frameworks like LangChain), tool responses, and assistant messages from previous turns. OpenAI's "developer" role is another unscanned vector.

3. Deterministic detection over LLM judges. Using a second model to evaluate the first sounds elegant but creates a recursive trust problem. Regex + text normalization (reversing ~24 obfuscation techniques) is boring but reliable and adds ~250ms, not seconds.

4. Fail-closed by default. If your policy engine goes down, block everything. Don't fail open.

5. Presets, not configuration. Nobody writes custom Rego policies from scratch. Ship starter/standard/regulated presets and let teams tune.These came from 12 rounds of red-teaming our own pipeline — about 300 test cases across encoding bypasses, multilingual injection, Unicode evasion, and tool-result poisoning.

This is exactly right. We went down this path and the practical implementation ends up looking like capability tokens. short-lived, cryptographically signed credentials that encode what the agent is authorized to do for this specific task.

The key insight: the token isn't just authorization, it's evidence. When you issue an ES256-signed token that says "this agent was scanned for PII, classified as INTERNAL, and is authorized to call [search,read_file] for the next 60 seconds" , that token becomes the audit artifact. The auditor doesn't need to the agent or the operator; they verify the token chain.

On "contain the blast radius instead of preventing the confusion" agreed, but you need both. Containment (scoped permissions, delegation chains) handles authorization. But you still need a detection layer for data protection: PII flowing to an external model is a GDPR or EU AI Act (def. in europe) violation regardless of whether the agent was "authorized" to make that call. We found deterministic scanning (regex + normalization, not LLM judges) at the proxy layer catches this at ~250ms without the reliability problems of using another model to judge the first one.

The ergonomics point tucnak raised is real too. We use OPA/Rego for the policy layer with presets so operators don't have to write Rego from scratch, pick a security posture and tune from there. The governance tax has to be near-zero or teams just bypass it.