Integrations — attenu-guard inside real agent frameworks

Every row below is a shipped, tested integration: a thin adapter installed with the package as attenu_guard.adapters.<framework> (enable its framework with pip install 'attenu-guard[<extra>]'; the core stays zero-dependency — a framework is imported only when you import its adapter), a runnable demo.py under examples/integrations/<framework>/ that tells the poisoned-summariser story end to end (every row except OpenHands and AstrBot, which have tests only), and a pytest under tests/integrations/ that runs offline — every framework's own mock/scripted model, no LLM API key — and is skipped when the framework isn't installed. CI runs each one against the exact version listed (integrations job) and, weekly, against the latest release (integrations-latest).

The library itself was not modified for any of them: Guard / Authority / Decision / AuditLog integrate through each framework's official hooks. Two hook points are always needed — (1) the moment a parent hands off to / spawns a sub-agent, where the child's attenuated Guard is minted with parent.delegate(...), and (2) the moment any agent invokes a tool, where guard.check(...) runs before the tool body.

Versions and file:line references are as of August 2026; they will drift.

The matrix

Fit = how well the framework's official hooks carry an authorization decision (1–5). Twenty entries (LangGraph through A2A: nineteen frameworks and the A2A protocol); tests/integrations/ holds 34 offline test files covering them, the three recipes below, and the Claude Code and Omnigent examples. The Claude Agent SDK integration was additionally verified live against a real session, and the A2A one over a real HTTP hop.

Beyond the matrix, three recipes rather than adapters: a Langflow custom component (examples/integrations/langflow/, 25 offline tests) — Langflow is a visual builder, so the unit there is a component in the editor rather than an adapter module — commerce-agents (examples/integrations/commerce-agents/, 46 offline tests), which is an application rather than a framework and whose packages are on no index, so its test skips unless the repo is installed from a clone and CI does not carry it, and MCP (examples/integrations/mcp/server_verifier/, 11 offline tests), a server that verifies the delegation chain before it runs a tool body. The first two have their own sections below; the MCP recipe keeps its evidence manifest in its own README.

Why these twenty

Selection criteria (August 2026): (1) a Python framework with an explicit delegation / handoff / sub-agent primitive — the moment attenu-guard exists to guard; (2) coverage of every major vendor's agent stack (OpenAI, Google, Microsoft ×2, AWS, Anthropic, Hugging Face, LangChain) plus the leading independents (CrewAI, Pydantic AI, LlamaIndex, Agno); (3) an offline test path (mock/scripted model) so the integration test can run in CI with no API key; (4) at least one real multi-agent application, not just a framework (deepagents). GitHub stars at selection: CrewAI 57k · AutoGen 60k (in maintenance since 2026-04, superseded by Microsoft Agent Framework) · LlamaIndex 52k · Agno 42k · LangGraph 40k · smolagents 29k · OpenAI Agents SDK 29k · Semantic Kernel 28k · deepagents 28k · Haystack 26k · ADK 21k · Pydantic AI 19k · Claude Agent SDK 8k · Strands 7k. Added later (August 2026): Haystack (3.x shipped AgentTool, a delegation primitive), CAMEL-AI (AgentToolkit/Workforce proved hookable), and both AutoGen successors — Microsoft Agent Framework (AutoGen + Semantic Kernel) and AG2 1.0 (the AutoGen fork; a rewrite whose package is ag2, not autogen); AutoGen itself has been in maintenance since 2026-04, so its adapter now has two live successors beside it. Added after those: A2A — a protocol rather than a framework, but its hop IS a delegation, and spec §7.6.4 states outright that the protocol defines no scope or revocation semantics for an in-task authorization decision, so the adapter supplies them through A2A's own extension mechanism (§4.6). MCP remains a recipe rather than an adapter (examples/integrations/mcp/server_verifier/), because there the server is the resource, not a delegate. Deliberately not (yet): MetaGPT/ChatDev/AutoGPT (research/app-shaped, weak offline story), Letta (no delegation primitive), Dify/Flowise/n8n (not Python-embeddable), and every non-Python stack (see "Other languages").

Also added (August 2026): a Langflow custom component (below — Langflow is a visual builder, so the unit is a component in the editor rather than an adapter module).

Status of the framework findings

Nothing above has been reported upstream yet (this repository is private). Each finding is pinned as an executable baseline test in tests/integrations/ (e.g. test_autogen_itself_does_not_attenuate, deepagents' permissions-replace test), so the weekly unpinned integrations-latest job will flag the day a framework changes the behaviour — e.g. Google ADK's disallow_transfer_to_peers: upstream fixed #3850 on the legacy llm_flows path (fa18d26a, in 2.7.1), but the 2.x default workflow path (workflow/utils/_transfer_utils.py) still has no check — the pinned test asserts the transfer goes through on 2.7.1 and carries the message that will fire the day it stops. When the project goes public the intent is to file each as a constructive upstream issue with the repro and a suggested fix (child ⊆ parent "meet" semantics; fail-closed hook dispatch), and to keep this document as the citation.

Langflow — the visual builder

Langflow composes flows in a browser rather than in Python, so the unit of integration is a custom component you drop into the editor, not an adapter module: examples/integrations/langflow/attenu_guard_component.py.

Langflow tools are LangChain BaseTools, so hook (2) is the same funnel as the LangChain adapter's: BaseTool.invoke -> run -> _run, wrapped with a langchain_core.tools.StructuredTool that authorizes and only then calls inner.invoke(...), mirroring name / description / args_schema. Hook (1) is an edge in the flow: the component exposes its Guard as an output and accepts one on a Parent Authority input, and connecting them mints the downstream agent's authority with parent.delegate(...). Two chained components is a delegation whose child can only be narrower, drawn rather than coded.

The component also emits an Evidence output — the delegation graph, the audit log, and the result of re-verifying it — so a flow's authorization history is inspectable from inside the editor. Tested against lfx 1.11.5 / langchain-core 1.5; the parsing and wrapping half of the test suite runs with Langflow absent.

commerce-agents — the delegate contract

anthropics/commerce-agents is an application rather than a framework, so this is a recipe — a paste-in adapter beside the demo, not a shipped attenu_guard.adapters module: examples/integrations/commerce-agents/. Its packages are not on any index (its own CI asserts that), so the test skips unless the repo is installed from a clone, and the integrations CI matrix, which installs every framework from PyPI, does not carry it.

Both hooks land on one method, over a seam the repo already documents. BaseToolExecutor.dispatch (commerce-common/commerce_common/execution.py:225-243) routes presentation, delegates and handlers by name for every path the repo ships — so hook (2) is one override of that method, and hook (1) is the same override recognising a delegate name and calling parent.delegate(...) there. The override arrives as a subclass through executor_class, "the seam for a deployment's own MerchantToolExecutor subclass" (merchant-agent/runtime-messages-api/merchant_agent_runtime/orchestrator.py:86-87), which the Messages API orchestrator, the Agent SDK toolset and the MCP server all accept — upstream's own test_every_path_takes_a_deployments_own_executor_class holds them to it. Nothing is patched.

One consumption path does not carry that seam: AnalysisRunner._read names MerchantToolExecutor inside the method (analysis.py:332-339) rather than the deployment's class, so the delegate's own reads fall outside it. (The repo's demo web host builds one directly too, at examples/demo_common/merchant.py:248, but that is an example site rather than a path the library offers.) The child guard rides a contextvars binding, and a process-wide install() is what reaches that instance today. commerce-agents is a reference implementation that does not accept contributions (its README.md:193), so the "Status of the framework findings" intent above does not apply here and nothing is filed upstream: the example README states the change that would close the gap — threading executor_class one level further — as a diff verified to apply and pass their own analysis tests, for a reader who vendors or forks the packages.

What the repo enforces about a delegate's authority: the contract is stated in prose (commerce-common/commerce_common/delegation.py:4-6 — a delegate "cannot write, present, or invoke other delegates") and held by the shipped delegate's own tool list and a name test in its runner (analysis.py:361). The executor that delegate constructs carries the full handler table and the presentation components regardless, so a second delegate written the same way reaches both; the example's act 3 runs one and shows all three bodies executing unguarded. Ceilings are per-deployment, not per-caller: MerchantAgentConfig.max_campaign_budget is one number the delegate shares through DelegationContext.config. Offline model: the repo's own commerce_common.testing.FakeCreateClient, which drives the real AnalysisRunner.

Other languages

The wire format (attenu_guard.wire: signed JWS Delegation Tokens, offline child ⊆ parent verification) is the language-neutral contract, and tests/vectors/ + scenarios/*.json are its conformance suite. A TypeScript port of the core is the natural next language (Vercel AI SDK, LangGraph.js, OpenAI Agents JS, Claude Agent SDK TS, the MCP TS SDK); Go/Java/.NET follow the same recipe: port the core against the vectors, then thin adapters at the same two hook points. Authority crosses a language boundary as a token, never as a network call on the deny path.

Denial semantics — one decision every adapter makes

Guard.check() returns a Decision; the adapter decides what the framework sees:

• Return the denial to the model as a failed tool result (default in most adapters: ToolMessage(status="error"), ToolFailed, reject_content, ToolResult(is_error=True), ADK's error dict): the run continues, the model is told why and can recover. The tool body still never runs.
• Raise (AuthorityDenied or the framework's own tripwire): the run aborts. Use for hard-stop policies. Every adapter exposes this as a one-word switch (on_deny="raise").

Either way the denial lands on the hash-chained audit log with a reason code, and attenu-guard view renders it in the delegation tree — that is the only place a sub-agent's blocked call surfaces in frameworks (deepagents, AutoGen) that collapse the child's transcript into a single message for the parent.

What we learned that shaped the library (v0.3)

• strict_metering=True only refused an entirely empty context; a partial context that forgot one metered dimension silently skipped that ceiling. Now checked per ceiling (ctx_field_of, is_metered in ceilings.py).
• Adapters need to refuse things upstream of policy (an agent the chain never delegated to, an unmapped tool). ReasonCode.NO_AUTHORITY + Guard.record_denial(...) put those on the same audit trail.
• Guard.agent_id, Guard.is_revoked, Guard.is_expired — read-only state every registry and UI wanted.
• revoke() was node-scoped: a framework that re-hands-off to a revoked agent (swarm ping-pong, a second as_tool() call) minted it a fresh, clean child from the still-valid parent; two adapters had to keep their own "revoked names" set. Guard.revoke_agent(agent_id) revokes the principal chain-wide (every node it holds, plus a grow-only ban that makes any later delegate() to it fail with agent_banned) in one auditable event.
• Guard.would_delegate(agent_id, request) — dry-run of the delegation preconditions (revoked/expired parent, banned agent, depth/fanout) with no node created and no audit write, so a hook can pre-flight a handoff before it cancels a whole swarm.
• The tool→scope map is the integrator's job and the only real work (~10 minutes once you know your tools). Adapters default to fail-closed on an unmapped tool.
• Frameworks run parallel tool calls on thread pools (smolagents, ADK): concurrent check()s could interleave the hash-chain append and make verify() reject the library's own log. The audit log, sequence clock and chain mutations are now serialised per chain (ts and seq advance together).
• Ceiling.describe() / Authority.describe() and ReasonCode.{CHAIN_REVOKED, AGENT_BANNED, TTL_EXPIRED, MAX_DEPTH, MAX_FANOUT, CHAIN_CEILING} — every adapter demo had re-invented the first; every adapter had a lookup table for the second.

Running one

pip install -e '.[openai-agents]'             # extras: langchain, deepagents, openai-agents, google-adk,
                                              # pydantic-ai, crewai, autogen, claude-agent-sdk, smolagents,
                                              # strands, llama-index, semantic-kernel, agno,
                                              # haystack, camel, a2a, openhands
python examples/integrations/openai_agents/demo.py
python -m pytest -q tests/integrations/test_openai_agents.py

from attenu_guard.adapters.openai_agents import GuardRegistry, DelegationGuardHooks, guarded_tool

Each directory's README.md lists the exact hooks, the version tested, and an env-gated live_smoke.py (RUN_LIVE=1 + your provider key) that replays the same story against a real model.