On September 3, 2026, Representatives Josh Gottheimer (D-NJ) and Mike Lawler (R-NY) introduced the Stop Rogue AI Act — the first federal bill directing the Department of Commerce and NIST, working with CISA, to set binding security standards specifically for AI agents. NIST has one year to publish guidelines built around four requirements: a continuous, machine-readable inventory of every agent; continuous verification of agent actions before they happen; tamper-proof logs of what agents actually did; and records that tie every agent to the developer or vendor responsible for it.
Today the bill only applies to new federal contractors, and NIST hasn’t published anything yet. We’re publishing this page anyway, because the reasoning behind the bill is one we already agree with: you can’t govern what you can’t see, and an AI agent that can act on your site needs the same kind of accountability trail you’d expect from a human administrator. Agent Builder’s risk-tier and approval system was built for that reason well before this bill existed — this page is an honest accounting of how much of it already lines up, and exactly where the rest stands.
This is not a compliance certification. NIST hasn’t published a standard to certify against yet, and nothing on this page should be read as a legal claim of compliance with the Stop Rogue AI Act or any other regulation.
The four requirements
| Requirement | What it means |
|---|---|
| Machine-readable inventory | A current, queryable list of every agent, what it can do, and how risky each action is — not a document someone updates by hand. |
| Continuous verification | Every action an agent takes gets checked against policy at the moment it happens, not just once when the agent is first installed. |
| Tamper-proof logs | A record of what agents did that can’t be quietly edited or deleted after the fact — or if it is, that’s detectable. |
| Developer/vendor attribution | Every agent and every logged action can be traced back to who built and is responsible for it. |
Where Agent Builder already lines up
Continuous verification — built in from the start
Every tool call an agent makes is checked against your risk policy at the moment it’s about to run — not once at setup. Read-only actions proceed; write actions pause for in-chat confirmation; significant or bulk changes queue in the Approval queue for a human to sign off; and a small set of destructive actions are blocked outright with no approval path at all, ever. This applies to every call, every time — there’s no “trusted after the first approval” shortcut that would let an agent’s actions go unchecked later.
Agent inventory — declared, not discovered after the fact
Every agent ships with a declarative manifest listing exactly which tools it can use and at what risk tier — this is what the approval system above actually reads to decide whether an action needs sign-off. Agents that support MCP also expose a live, machine-readable list of their current tools to any connected client, scoped to only what that specific agent is allowed to touch.
Developer attribution — tracked per agent and per imported skill
Every agent records who built it. Skills imported from the WordPress.org skill repository or Agent Builder’s own community feed record their source and author separately, with a content hash so you can tell if an imported skill’s instructions have drifted from what was originally published.
What’s built, verified, and on its way to you
This is the honest part. The two gaps below are no longer just planned — the code is written, merged, and has been verified end-to-end in our QA environment, including deliberately tampering with a log entry to confirm the integrity check actually catches it. What hasn’t happened yet is cutting the next public release build, so the version you’d download today doesn’t have this yet:
- Tamper-evident audit log. Unlike agent manifests, which are cryptographically signed and fail closed if edited without re-signing, Activity log entries themselves had no integrity chain. v3.3.96 adds one: each log entry’s hash is chained to the one before it, using the same key-signing approach as manifest verification, so deleting or editing any historical entry breaks the chain from that point forward. We tested this directly — edited a logged entry straight in the database and confirmed the check flags exactly which entry broke the chain. Nothing can stop someone with direct database access from deleting a row outright; what this buys is that it stops being invisible when they do. Each entry also now records which developer built the acting agent, and at what version, at the moment the action happened — not just today’s answer to that question.
- A single machine-readable inventory endpoint. Today an agent’s tool list is queryable via MCP per-agent. v3.3.96 adds one authenticated endpoint that lists every active agent, its declared tools, and each tool’s current risk tier in one document — so a site owner or an auditor doesn’t have to query each agent separately to get the full picture. It requires the same admin credentials as the rest of Settings, deliberately not a public file — a full risk-tiered map of what a site’s agents can do is real reconnaissance value, and publishing it to anyone unauthenticated would work against the “safety and trust” the bill cares about, not for it.
We’ll update this page the moment v3.3.96 is in the downloadable build. If you’re evaluating Agent Builder for a context where this matters — a government site, a regulated industry, or just because you take AI governance seriously — this is where we stand today, plainly stated, not where we’d like you to believe we stand.
Related
Ready to put this to work?
Agent Builder is free forever — 8 AI agents, 261 tools, no API key needed. Approval-gated by default.
Download Free Compare Free vs Pro