Agentic Daisy AI Agent Firewall

This plugin restricts AI agents; it is not an AI tool. It calls no external service, sends nothing off your site, and neither generates nor executes code. Every decision is made by deterministic PHP running locally against rules you write.

AI assistants can now manage WordPress sites through the Abilities API and the REST API. That’s powerful, and also risky: a confused or hijacked agent can rewrite content, change settings, or delete things faster than anyone notices. Agent Firewall puts an AI agent firewall — a deterministic policy engine — between every agent and your site.

Each agent gets its own identity: a bearer token (ag_live_...) tied to a WordPress user of your choosing. Tokens are stored as SHA-256 hashes and displayed a single time at issuance. An agent can never exceed the capabilities of its linked user, and token scopes can pin it down further, to specific action categories or ability patterns.

Write actions are intercepted at both doors. Ability execution callbacks are wrapped at registration, and direct REST writes are caught at rest_pre_dispatch, so switching transports doesn’t dodge the rules. Policies match on ability name, action category, entity type or id, and source, in priority order. Each rule decides: allow, deny, log only, or require human approval. If nothing matches, destructive actions require approval and reads pass. A sliding-window rate limiter shuts down runaway loops, and the admin gets an email when it trips.

Held actions land in an approval queue along with the target’s modification timestamp. If a person edits that content before you approve, the stored action aborts with a conflict rather than overwriting the newer work.

Every decision is written to an append-only audit ledger. Each entry carries a SHA-256 hash chained to the previous one, so any after-the-fact tampering breaks verification. Secrets in action payloads (passwords, API keys, tokens) are redacted before they reach the ledger.

Executed actions can be undone from the dashboard. Post edits restore through the normal revision history, deletions come back from trash, and settings changes restore from stored snapshots. Where a clean undo isn’t possible (say, user creation), the ledger says so instead of pretending.

The plugin also watches for two quieter risks: it fingerprints every registered ability and emails you when one appears or changes definition (a known tool-poisoning pattern), and it records REST writes made with application passwords – which carry no agent identity – in the audit ledger as “untracked”. A strict setting can block those outright.

All decisions are made by plain PHP on your server. The plugin makes no external service calls and collects no telemetry. The admin dashboard (Agent Firewall menu) runs on permission-checked REST endpoints. The Abilities API interception itself is what sets the WordPress 6.9 floor.

What this does and does not claim

Every agent write that reaches WordPress is evaluated, and every one that succeeds is recorded. That is the promise, and it is deliberately narrower than “blocks all AI attacks”.

What it cannot see, stated plainly so you can judge the fit:

• Writes that bypass WordPress. Anything with direct database access is invisible to any plugin, including this one.
• What an agent decided. Prompt injection happens in the model, before a request exists. This governs what an agent tries to do, not what it was talked into wanting.
• MCP servers that never touch your site. If a tool call is handled entirely elsewhere, there is nothing here to intercept.
• Attempts rejected by WordPress itself before the action runs, which currently leave no ledger entry.

Inside that boundary the guarantee is strict: no policy decision depends on a language model, nothing is sent anywhere, and the audit trail is tamper-evident rather than merely append-only. A security tool that overstates its reach is worse than one that draws the line clearly, so the line is drawn here.