OxDeAI: I built a deterministic pre-execution authorization boundary for AI agents (fail-closed, signed artifacts, adapters for LangGraph/CrewAI/AutoGen, etc...), looking for feedback.

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. Repo: https://github.com/oxdeai/oxdeai 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. See CONTRIBUTING.md and the open issues.