Release 1.2.0 is live

Execution safety that stays close to the runtime.

AgentFirewall stops dangerous shell, file, network, and tool side effects before they happen. It now ships with two official adapters, one shared policy core, and evidence-backed release gates that show exactly what is supported today.

See the release proof View PyPI release
  • LangGraph and OpenAI Agents SDK are official adapters in 1.2.0.
  • Generic wrappers remain the preview path for unsupported runtimes.
  • Coverage, evals, and conformance are exported from the repo, not hand-written marketing copy.

Why this matters

Prompt safety is not enough once the model can act.

The moment an agent can run shell commands, read files, write credentials, or make outbound HTTP requests, safety becomes an execution problem. AgentFirewall is designed to sit in that path before side effects happen.

Inline runtime decisions

`allow`, `block`, `review`, and `log` happen before execution continues, not after damage is done.

One policy model, more than one runtime

The same policy, approval, audit, and runtime-context model now spans LangGraph and OpenAI Agents SDK.

Evidence-backed support boundary

Release gates, eval expectations, and the runtime support manifest keep the promise narrow and inspectable.

Progress

What changed between 1.0 and 1.2

This project is not trying to sound universal too early. The work so far has been to build one reusable runtime firewall core, prove it on LangGraph, then prove that the same contract holds on a second adapter.

1.0

First official adapter

LangGraph shipped as the first official path with guarded shell, file, and HTTP surfaces.

1.1

Adapter contract hardening

Capability matrix, conformance validation, release gates, and runtime support export moved into code.

1.2

Second official adapter

OpenAI Agents SDK is now official on a narrow `function_tool`-first boundary with local eval evidence.

Next

Adoption and MCP expansion

Lower generic-wrapper adoption friction, add more workflow pressure, then widen into MCP-oriented paths.

Live support proof

The support story is driven by a checked-in manifest.

These cards are rendered from the same runtime support manifest exported by the package. They reflect the current official adapter inventory, preview runtime inventory, capability matrix, and packaged local evidence.

Loading support inventory and evidence...

Packaged local evidence

Release-gated proof, path by path

Each card below reflects compact eval and conformance data exported by the core engine.

Plan

Execution order from here

After shipping the second official adapter, the next job is not to spray support claims everywhere. The next job is to make the current contract easier to adopt, harder to misunderstand, and stronger under real workloads.

  1. 01

    Hold the 1.2 support contract steady

    Keep LangGraph and OpenAI Agents aligned on policy semantics, audit shape, and release-gate expectations.

  2. 02

    Lower generic-wrapper adoption friction

    Make the preview path easier to try in `log-only` without overstating it as a full adapter contract.

  3. 03

    Expand false-positive and workflow pressure

    Add more realistic task traces, not just synthetic unit-level evidence, so trust can come from observed behavior.

  4. 04

    Widen into MCP after the contract stays stable

    Reuse the same event model where possible and avoid new surface claims until new evidence actually exists.

Vision

Become the runtime safety layer for tool-using AI systems.

The long game is not a framework-specific guardrail product. The long game is one runtime firewall core that can protect multiple adapters without changing what `review`, `block`, audit correlation, or guarded execution mean.

Standardize execution surfaces

Translate runtimes into shared event kinds such as `prompt`, `tool_call`, `command`, `file_access`, and `http_request`.

Keep policy runtime-agnostic

Adapters should translate runtime hooks, not fork policy semantics. That is what keeps multi-runtime support believable.

Grow only where evidence is strong

The product should widen from two official adapters to broader coverage only when conformance and workflow evidence stay honest.

Install

Official adapters first, preview path when needed

Use the official adapters when you can. Use the generic wrapper path when your runtime is not yet first-class.

pip install agentfirewall[langgraph]
python examples/langgraph_quickstart.py

Official adapter with guarded shell, file, and HTTP surfaces plus packaged eval evidence.

pip install agentfirewall[openai-agents]
python examples/openai_agents_quickstart.py

Official adapter on the documented `function_tool`-first support boundary.

pip install agentfirewall
python examples/generic_tool_dispatcher.py

Preview runtime path for unsupported runtimes. Best used in `log-only` or local evaluation first.

Docs and evidence

Everything needed to inspect the support claim

The site is only the front door. The support boundary, release notes, strategy, and evidence all live in the repository.

README

Quickstart, support scope, and the current release position.

Supported Contract

The narrow import-level promise for 1.2.0.

Release Readiness

The exact commands and outcomes used to validate this release.

Runtime Manifest

The machine-readable inventory used by this page.

Strategy

Roadmap, positioning, product status, and adapter plans.

PyPI

Release metadata and published artifacts.

Ready to evaluate it?

Start with the support contract, then run the evidence locally.

AgentFirewall is most useful when you can see exactly what it will allow, review, block, and log in your own workflows.

Open the repository Discuss a runtime