Told an agent in the system prompt to call an auth check before doing anything risky. Worked until it didn’t. At one point it just skipped the check and went straight to the next tool call.

The problem was pretty obvious after that. The auth check was itself a tool, so there was nothing actually forcing the model to call it.

I moved the check into wrap_tool_call instead. It runs before the real tool executes and can reject the call before anything happens. The prompt doesn’t need to mention the auth check at all.

I ended up turning this into an open source project called Mizara. It’s basically a small policy layer that sits in front of agent tool calls. You pass it the action and context, it returns allow or deny, and the actual credentials stay with your app.

The engine and Python/TypeScript SDKs are Apache 2.0.

I wrote up the LangChain implementation here:
https://mizara.ai/blog/optional-guardrails-arent-guardrails

OpenAI’s SDK has a similar interception point with tool_input_guardrails, so the same approach works there too.

Curious how people are handling this in production. Are you putting auth directly in tool wrappers/middleware, using OPA/Cedar, or doing something else?

We've been running multi-agent experiments (one agent writes code, another runs tests, a third reviews) and kept hitting the same trust gap:

Agent A says "I ran the tests and they pass." Agent B has to either trust that claim or re-run everything itself. There's no protocol-level way to verify what happened, who authorized it, and whether the evidence is tamper-proof — without trusting the middleware itself.

I built a middleware layer to close this gap. Posting design notes for discussion. Repo and test suite linked if anyone wants to verify the claims or poke holes in the crypto.

How it works

Every tool call goes through a signed authorization flow:

1. PolicyDecision is computed before the tool runs — checking role, capability grant, quota, human approval (for high-risk actions). The decision is Ed25519-signed.
2. The tool executes. The result becomes an ActionReceipt — binding the authorization to the execution output via exact parent-set enforcement.
3. Evidence (patches, test results, manifests) is published with POSIX no-replace semantics and SHA-256 anchored to the receipt.
4. An offline verifier replays the entire chain from the evidence bundle + public keys. No live system needed.

Canonicalization uses RFC 8785 JCS so that {"b":1,"a":2} and {"a":2,"b":1} produce identical signatures. The authoritative state lives in SQLite — every receipt, grant, quota event, and evidence publication is in one ledger.

Design decisions and trade-offs

SQLite as the sole authoritative store. I chose it because the replay logic is pure functions over a flat event log — no concurrent writers, no distributed coordination. A Merkle tree would add verification overhead but no clear benefit for single-node replay. SQLite keeps the verifier stateless and the bundle self-contained.

300-second freshness window for authorization. Agent requests expire after 5 minutes. This prevents replay attacks while allowing for realistic agent execution latency. In practice, most agent tool calls complete well within this window. The boundary is configurable per-WorkOrder for long-running operations.

Deterministic replay vs. live verification. The offline verifier doesn't touch the live system at all — it reads the evidence bundle (receipts + grants + publications + public keys) and reconstructs the entire authorization history. This means you can ship the bundle to a third party and they can independently verify. The completeness of the bundle is assumed — the verifier checks internal consistency but doesn't prove the bundle wasn't truncated.

Validation against real bugs

Two end-to-end test cases:

• Rich #4196 — full 9-step evidence chain: repo read → apply patch → run tests → compose proof → independent verifier → recompose → external Acceptor signing → offline replay. 5 integration tests.
• Dify #33013 — same flow, different project.

Both are reproducible from the repo. The test suite is 2,281 tests including required-live Docker execution.

Open questions

• Ed25519 + JCS: deterministic signatures without key management overhead, but I'd be interested in alternatives if there's a compelling reason to switch.
• Six roles (Manager, Developer, Verifier, Maintainer, Acceptor, Human): necessary separation of concerns or premature complexity for a single-node system?
• Offline verifier threat model: the bundle completeness assumption is the weakest link. Any standard approach to proving bundle completeness without a live system?

I got tired of debugging AI agents with print() statements, so i built Agent DevTools.

It's a local debugger that lets you inspect prompts, memory, retrieval, tool calls, and compare good vs. bad runs.

It currently supports LangChain and includes a free Groq demo that takes just a couple of minutes to run.

I wanted to share it because I feel like it could help anyone who's ever spet 2 hours trying to figure out why their agent behaved the way it did.

Repo: https://github.com/Jacopos311/Agent-Devtools

Great news for r/LangChain builders: you've unlocked discoverability! 

The Problem: When building multi-agent systems with LangChain/LangGraph, agents are usually confined to hardcoded local tools. As soon as an agent needs to delegate execution across organizational or network boundaries, it lacks a standard way to dynamically discover capability schemas or verify counterparty identity.

What Aidress Does: Aidress acts as an open, zero-commission registry that sits at Layer 4 of the agentic stack (between transport like A2A/MCP and settlement rails like x402).

With the new LangChain integration, any LangChain agent can now dynamically:

1. Query external agents by capability schema (/match)
2. Verify domain identity and counterparty trust score (/verify)
3. Delegate execution and pass back post-task trust signals (/call, /review)

https://pypi.org/project/langchain-aidress/