u/docybo

(disclosure: i maintain the open-source project this came up in. link at the end. the question stands on its own.)

we hit a trust-boundary problem while building a deterministic authorization layer for agents, and i think it generalizes.

an engine can strongly protect its verdict:

* signed authorization
* intent binding
* state-hash binding
* replay protection
* trusted evaluation time

all solid.

but if the same compromised agent runtime can influence both the proposed action AND some of the premises used to evaluate it, what has crypto actually proven?

only this:

the signed decision is consistent with the supplied inputs

not this:

the supplied inputs came from authoritative sources

examples of premises a runtime might quietly supply:

* agent\_id
* tool identity
* execution depth
* tenant context
* a state object the guard later hashes

the signature still verifies. the hash still matches. the decision is still deterministic.

but the premises may be self-reported.

two things i'd genuinely like challenged:

1. which evaluator premises actually need independent provenance, and which can safely remain proposer-declared?
2. for state, is an authoritative guard-side read enough, or should the state provider eventually emit a signed/versioned attestation?

most interested in confused-deputy paths, TOCTOU, and cases where a supposedly "trusted" premise can still be bent by the runtime.

I'm designing service-to-service authorization where a PDP evaluates (subject, action, resource, context) and returns a signed decision that PEPs enforce. Standard split. The wrinkle: the calling workload is partially untrusted, and it supplies part of the request context itself.

The signature covers the decision and the inputs the PDP saw, but not the provenance of those inputs. So the token proves "given these inputs, the PDP said ALLOW", not "these inputs came from an authoritative source". If the caller can influence subject/tenant labels, resource attributes, a recursion/depth counter, or a state object the PEP hashes instead of fetching, a fully valid signed decision can attest an ALLOW the policy would never grant on authoritative inputs. The PDP becomes a confused deputy whose output happens to be cryptographically signed, which makes it look stronger than it is.

What we already do: mesh identity (mTLS/SPIFFE) for the caller's own identity, short-TTL decisions, intent binding, and we hash the state object into the decision. What I can't resolve is which of the remaining context attributes should be trusted from the request at all.

Concrete questions:

1. In real OPA/Cedar/Zanzibar deployments, which request-context attributes is it standard practice to require the PDP to source itself (server-side PIP lookup, trusted routing/mesh-derived identity, attested claims) rather than accept from the caller, and which are considered safe to accept as caller-asserted as long as they're bound into the decision? I'm looking for the actual dividing line practitioners use, not "trust nothing".
2. When the PEP hashes a caller-supplied state/resource object and binds that hash into the signed decision: does that close the confused-deputy gap, or is a PDP-side authoritative read (or a signed/versioned attestation from the resource owner) required so the caller can't pick favorable premises? What do production deployments settle on?
3. For the window between decision issuance and enforcement, what's the standard way to bound TOCTOU on a signed authorization: short TTL plus re-eval at the PEP, versioned state binding, resource-side optimistic concurrency, and where does each of those still leave an exploitable gap?

Hey everyone. I'm the author of OxDeAI, an open-source protocol (Apache 2.0). Posting it here because I want critical feedback from people building real agents, not applause.

The problem I keep hitting: as agents move from generating text to *doing things* (API calls, payments, infra provisioning, tool use), most stacks still enforce policy with best-effort checks inside the agent loop. That produces failure modes like retry amplification on non-idempotent actions, budget leaks, stale-state executions, and permission drift, all because the "check" and the "action" live in the same trust boundary.

**Core idea.** Separate the decision from the enforcement. Agent proposes an intent, OxDeAI evaluates `(intent, state, policy)` deterministically, and if the result is ALLOW it issues a signed `AuthorizationV1` artifact. A Guard/PEP then verifies that artifact *before* any side effect. No valid authorization means no execution path. Fail-closed by default, with single-use replay protection, explicit trust (`trustedKeySets`), and artifacts you can verify offline.

**What's actually there today:**

* Signed decision artifacts plus a non-bypassable guard (the execution fn is only reachable through the guarded closure; there's a demo where a direct call gets refused).
* Adapters for LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, and OpenClaw, all thin bindings that route through one universal guard.
* Single-hop scoped delegation (narrowing-only capabilities between agents).
* Cross-language conformance vectors (TS reference plus Go/Python harnesses) with byte-equivalence anchors on the canonicalization and revocation-list surfaces.
* Hash-chained audit envelopes for offline verification.

**Where I'm being honest about the stage:**

* Cross-language reproducibility is *complete on the serialization and KRL surfaces*, but not yet on every authorization verdict (Go/Python don't harness the full verification surface yet). I don't want to claim "deterministic across all languages" when the vectors don't cover all of it.
* There's a micro-benchmark suggesting low per-action overhead, but it's single-process on my hardware, so treat it as indicative, not a production number. The harness is in `bench/` if you want to poke at it.
* Open issues include an active hardening item around self-declared intent fields (an agent can currently influence which per-agent limits apply by choosing its own `agent_id`, which is being fixed) and a scoping issue for an eventual independent security review. No third-party security review yet, and I say so in the docs.
* It's early. TypeScript is the reference; the protocol surface is specified but evolving.

This is **not** a prompt guardrail or a monitoring/observability tool. It sits at the execution boundary and is meant to compose with your existing framework, not replace it.

What I'd genuinely like to know:

* Have you hit these tool-calling / side-effect failure modes in production? How are you enforcing action-level policy today: inside the loop, at an API gateway, or somewhere else?
* If you tried an adapter, where did the integration hurt?
* For the security-minded: does the fail-closed / signed-artifact boundary hold up to how you'd attack it?

Contributors welcome, especially for new adapters, policy examples, and the cross-language verdict coverage.

Everyone's focused on the sandbox escape, which is fair, it's the dramatic part. But that was a zero-day in internally hosted software. Containment bugs are old news. We know how to think about them: egress rules, microVM isolation, no ambient credentials.

The part I find more interesting is everything that happened after.

Once the agent had internet access, it picked Hugging Face as a target, found exposed credentials, chained them with another vulnerability, and pulled the benchmark answers. All of that went through ordinary tool calls. Nothing sat between "agent proposes an action" and "side effect happens."

And the model wasn't misaligned in any interesting sense. It was hyperfocused on passing an eval, which is exactly what it was trained to be. Behavior was working as intended. Execution was ungoverned.

So the question I keep coming back to: for those of you running agents with real tool access in production, what actually sits in the execution path?

As far as I can tell the common answers are:

- prompt guardrails, which are probabilistic and live inside the loop the agent controls
- monitoring and traces, which tell you after the side effect landed
- human approval on a hardcoded list of "dangerous" tools, which breaks down the moment the dangerous thing is a legitimate tool pointed somewhere it shouldn't be

That last one is what got me. A tool allowlist wouldn't have caught this. The tools were fine. The destination and the credentials weren't.

My read on why there's no standard answer yet, and I'd like to be wrong about some of this:

1. Enforcement is easy, policy authoring is brutal. Standing up a gateway is a week. Deciding what an agent is allowed to do when its task is "research this and summarize" is a non-enumerable action space. Classic permission systems assume a finite set of verbs.

2. Incentives point the other way. Every DENY is a failed task. Teams optimize completion rate, not refusal rate. A layer that degrades the demo doesn't survive review.

3. No shared representation of intent. Every framework has its own tool schema, so no policy is portable and everyone rewrites theirs.

4. The layer sits at the wrong altitude. An application-level gate is only worth the network and OS isolation underneath it, and whoever writes the agent usually doesn't own the infra.

None of this is a new problem in security terms. Capabilities go back to 1966, complete mediation to Saltzer and Schroeder in 1975. OPA, SPIFFE, seccomp, service meshes all do versions of this for normal workloads. Nobody wired them into agent runtimes because agents went from answering to acting in about two years and control layers historically lag capability by five to ten.

Disclosure so it's not weird later: I work on an open source protocol in this space, so I'm obviously not neutral. Not linking it, it's in my profile if you care. I'm more interested in what people are actually doing than in pitching anything, and I'll say upfront that no policy layer would have stopped the zero-day. Nothing at that altitude does. It changes what an escaped agent can reach, not whether it escapes.

What are you running?

Hey everyone. I'm the author of OxDeAI, an open-source protocol (Apache 2.0). Posting it here because I want critical feedback from people building real agents, not applause.

The problem I keep hitting: as agents move from generating text to doing things (API calls, payments, infra provisioning, tool use), most stacks still enforce policy with best-effort checks inside the agent loop. That produces failure modes like retry amplification on non-idempotent actions, budget leaks, stale-state executions, and permission drift, all because the "check" and the "action" live in the same trust boundary.

Core idea. Separate the decision from the enforcement. Agent proposes an intent, OxDeAI evaluates (intent, state, policy) deterministically, and if the result is ALLOW it issues a signed AuthorizationV1 artifact. A Guard/PEP then verifies that artifact before any side effect. No valid authorization means no execution path. Fail-closed by default, with single-use replay protection, explicit trust (trustedKeySets), and artifacts you can verify offline.

What's actually there today:

• Signed decision artifacts plus a non-bypassable guard (the execution fn is only reachable through the guarded closure; there's a demo where a direct call gets refused).
• Adapters for LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, and OpenClaw, all thin bindings that route through one universal guard.
• Single-hop scoped delegation (narrowing-only capabilities between agents).
• Cross-language conformance vectors (TS reference plus Go/Python harnesses) with byte-equivalence anchors on the canonicalization and revocation-list surfaces.
• Hash-chained audit envelopes for offline verification.

Where I'm being honest about the stage:

• Cross-language reproducibility is complete on the serialization and KRL surfaces, but not yet on every authorization verdict (Go/Python don't harness the full verification surface yet). I don't want to claim "deterministic across all languages" when the vectors don't cover all of it.
• There's a micro-benchmark suggesting low per-action overhead, but it's single-process on my hardware, so treat it as indicative, not a production number. The harness is in bench/ if you want to poke at it.
• Open issues include an active hardening item around self-declared intent fields (an agent can currently influence which per-agent limits apply by choosing its own agent_id, which is being fixed) and a scoping issue for an eventual independent security review. No third-party security review yet, and I say so in the docs.
• It's early. TypeScript is the reference; the protocol surface is specified but evolving.

This is not a prompt guardrail or a monitoring/observability tool. It sits at the execution boundary and is meant to compose with your existing framework, not replace it.

What I'd genuinely like to know:

• Have you hit these tool-calling / side-effect failure modes in production? How are you enforcing action-level policy today: inside the loop, at an API gateway, or somewhere else?
• If you tried an adapter, where did the integration hurt?
• For the security-minded: does the fail-closed / signed-artifact boundary hold up to how you'd attack it?

Contributors welcome, especially for new adapters, policy examples, and the cross-language verdict coverage.

I’ve been thinking about a support automation story I read recently.
A team replaced a simple rules engine with an LLM classifier.

The model was around 92% accurate. Sounds good. Until you realize that at 100 tickets a day, that’s roughly 8 mistakes every day. The interesting part wasn’t the accuracy though. It was what happened when the model was wrong. Nobody could explain why a ticket was classified a certain way. Nobody could point to a specific rule. Nobody could quickly fix the behavior.

The team eventually started reviewing every classification manually. The automation was still running, but the trust was gone. That got me thinking. A lot of discussion around AI agents focuses on making decisions better.

Better prompts.
Better models.
Better reasoning.

But I rarely see people discussing what happens after the decision. How is the decision verified?
How is it audited? How do you know an action should actually be executed? Maybe the biggest challenge for AI agents isn’t getting from 92% to 96%. Maybe it’s building systems that people can trust when things go wrong.

Curious how others are thinking about this.

I’ve been thinking about a support automation story I read recently.
A team replaced a simple rules engine with an LLM classifier.

The model was around 92% accurate. Sounds good. Until you realize that at 100 tickets a day, that’s roughly 8 mistakes every day. The interesting part wasn’t the accuracy though. It was what happened when the model was wrong. Nobody could explain why a ticket was classified a certain way. Nobody could point to a specific rule. Nobody could quickly fix the behavior.

The team eventually started reviewing every classification manually. The automation was still running, but the trust was gone. That got me thinking. A lot of discussion around AI agents focuses on making decisions better.

Better prompts.
Better models.
Better reasoning.

But I rarely see people discussing what happens after the decision. How is the decision verified?
How is it audited? How do you know an action should actually be executed? Maybe the biggest challenge for AI agents isn’t getting from 92% to 96%. Maybe it’s building systems that people can trust when things go wrong.

Curious how others are thinking about this.