AI clients that authenticate with an application password - most MCP clients - can now be bound to an agent and governed by policy instead of bypassing it. Refusing unclaimed application-password writes is now a checkbox on the Agents screen. Nothing changes until you bind a password.<\/p>","1.5.0":"
Security hardening: agent tokens can no longer reach the firewall's own screens and routes, and agents can no longer be linked to an administrator. Existing admin-linked agents are flagged for relinking. Agents are now linked, and shown, by user name rather than by numeric ID.<\/p>","1.4.0":"
Fixes an activation failure on fresh installs alongside plugins that add their own cron schedules. Also names what agents touched in the activity ledger instead of bare database ids, links post edits to the revision that records them, and shows what changed in AI tool-change alerts.<\/p>","1.3.0":"
Shows how many actions await approval in the admin menu, pages the activity ledger and approval queue instead of truncating them silently, and fixes database changes never reaching sites installed before an update.<\/p>","1.2.0":"
Supports WordPress 7.1, records agent attempts WordPress refuses before they run, governs abilities registered before the firewall loads, and closes a way a plugin could have hidden its own AI tool from the registry monitor.<\/p>","1.1.0":"
Governs AI agent tool calls that arrive over MCP, adds a mutation-level backstop for unrecognized transports, and names the site in alert emails.<\/p>","1.0.1":"
Stops repeat "new ability" alert emails caused by abilities briefly vanishing during plugin auto-updates.<\/p>","1.0.0":"
Adds an emergency kill switch, policy import\/export, a first-run setup guide, and single-digest ability-change alerts.<\/p>","0.1.1":"
Hardens option rollback: snapshot capture and restore now enforce a strict settings whitelist.<\/p>","0.1.0":"
Initial release.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3637844,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3637844,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3637844,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3637844,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["0.1.1","1.0.0","1.0.1","1.1.0","1.2.0","1.3.0","1.4.0","1.5.0","1.6.0"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3667216,"resolution":"1","location":"assets","locale":"","width":1400,"height":1015},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3667216,"resolution":"2","location":"assets","locale":"","width":1400,"height":900},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3667216,"resolution":"3","location":"assets","locale":"","width":1400,"height":900},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3667216,"resolution":"4","location":"assets","locale":"","width":1400,"height":2516}},"screenshots":{"1":"Activity ledger showing which rule decided each action, with per-action undo, email-alert and retention settings.","2":"Pending approvals queue with payload review.","3":"Agent management with one-time token issuance.","4":"Policy editor."}},"plugin_section":[],"plugin_tags":[15643,2353,232494,1174,600],"plugin_category":[54],"plugin_contributors":[262708],"plugin_business_model":[],"class_list":["post-349096","plugin","type-plugin","status-publish","hentry","plugin_tags-agents","plugin_tags-ai","plugin_tags-ai-agent","plugin_tags-firewall","plugin_tags-security","plugin_category-security-and-spam-protection","plugin_contributors-agenticdaisy","plugin_committers-agenticdaisy"],"banners":{"banner":"https:\/\/ps.w.org\/agentic-daisy-ai-agent-firewall\/assets\/banner-772x250.png?rev=3637844","banner_2x":"https:\/\/ps.w.org\/agentic-daisy-ai-agent-firewall\/assets\/banner-1544x500.png?rev=3637844","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/agentic-daisy-ai-agent-firewall\/assets\/icon-128x128.png?rev=3637844","icon_2x":"https:\/\/ps.w.org\/agentic-daisy-ai-agent-firewall\/assets\/icon-256x256.png?rev=3637844","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/agentic-daisy-ai-agent-firewall\/assets\/screenshot-1.png?rev=3667216","caption":"Activity ledger showing which rule decided each action, with per-action undo, email-alert and retention settings."},{"src":"https:\/\/ps.w.org\/agentic-daisy-ai-agent-firewall\/assets\/screenshot-2.png?rev=3667216","caption":"Pending approvals queue with payload review."},{"src":"https:\/\/ps.w.org\/agentic-daisy-ai-agent-firewall\/assets\/screenshot-3.png?rev=3667216","caption":"Agent management with one-time token issuance."},{"src":"https:\/\/ps.w.org\/agentic-daisy-ai-agent-firewall\/assets\/screenshot-4.png?rev=3667216","caption":"Policy editor."}],"raw_content":"\n
This plugin restricts AI agents; it is not an AI tool.<\/strong> 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.<\/p>\n\n 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 \u2014 a deterministic policy engine \u2014 between every agent and your site.<\/p>\n\n Each agent gets its own identity, tied to a WordPress user of your choosing. Usually that is a bearer token ( Write actions are intercepted at both doors. Ability execution callbacks are wrapped at registration, and direct REST writes are caught at 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.<\/p>\n\n 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.<\/p>\n\n 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.<\/p>\n\n 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 an application password that no agent has claimed - automation carrying no identity for a policy to apply to - in the audit ledger as \"untracked\". A setting on the Agents screen refuses those outright instead.<\/p>\n\n 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.<\/p>\n\n Every agent write that reaches WordPress is evaluated, and every one that succeeds is recorded.<\/strong> That is the promise, and it is deliberately narrower than \"blocks all AI attacks\".<\/p>\n\n What it cannot see, stated plainly so you can judge the fit:<\/p>\n\n 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.<\/p>\n\n\n No. All policy decisions run as plain PHP on your server. Nothing leaves your site.<\/p><\/dd>\n Nothing, by default. The audit ledger is evidence, so it stays. If you want uninstall to remove all Agent Firewall tables and options, opt in first: Yes. Each agent is linked to a WordPress user and can never exceed that user's capabilities; policies and scopes only restrict further. Give it a user with just the capabilities it needs. Administrators are refused outright: an agent inherits its user's capabilities, and an administrator-linked agent would hold the capability that governs the firewall itself. For the same reason no agent token can reach the firewall's own screens or REST routes, whatever its user may do - the only exception is polling the status of its own held action.<\/p><\/dd>\n The Abilities API, the structured way AI agents act on WordPress, shipped in 6.9. Intercepting it is a core feature of this firewall.<\/p><\/dd>\n Use the kill switch: the \"Emergency stop: pause all agents\" button at the top of every Agent Firewall screen. While engaged, every agent action - reads included - is denied with a clear machine-readable reason, and every denial still lands in the audit ledger. Held approvals stay put; nothing is lost. Release it from the same place when the incident is over. It is a hard deny rather than hold-for-approval so a runaway agent cannot flood your approval queue while you investigate.<\/p><\/dd>\n No. Approval endpoints require the A structured error, not a bare refusal. Denials carry a The policy list starts empty, but the site is not unprotected. When no rule matches, the firewall falls back to built-in defaults: reads are allowed; creating or updating posts, pages and media is allowed; every deletion is held for approval; and any write to settings, user accounts, roles, plugins, themes, templates, global styles or widgets is held for approval even when it is a create or an update. Anything the firewall cannot categorize is held rather than allowed. The Policies screen lists these defaults so an empty policy list is not mistaken for no protection.<\/p><\/dd>\n Use the rule builder on the Policies screen, which offers only values that can actually occur, or switch it to JSON if you prefer. A rule matches on any combination of action category (create, update, delete, read), entity type, entity id, ability name, and source, and carries a decision: ALLOW, DENY, REQUIRE_APPROVAL, or LOG_ONLY. Rules are tried in order and the first match wins, so a rule with no match conditions must be last. A rule may also carry a sliding-window write limit instead of a decision.<\/p>\n\n Each policy is either global or scoped to a single agent, chosen with the \"Applies to\" control and changeable later. At equal priority an agent's own policy is consulted before a global one.<\/p>\n\n The full grammar is available over the API at Yes. The Policies screen has \"Export policies (JSON)\" and \"Import policies\" buttons. Importing only ever adds: existing policies are never edited or deleted, and an entry identical to one you already have is skipped. Policies scoped to a single agent attach to an agent with the same name on the destination site; if none exists, the entry is skipped and the import report says so, because silently applying an agent-specific rule to every agent would change what it protects.<\/p><\/dd>\n Use \"Test an action\" on the Policies screen. Pick an action, an entity type and optionally an agent, and it reports what would happen and which rule decided it - or that no rule matched and a built-in default applied. It is a dry-run: nothing is written, no rate limit is consumed, and no agent is affected. This matters because rules are tried in order and the first match wins, so reading a list of policies does not always tell you which rule governs a given action.<\/p>\n\n After the fact, the Activity Ledger's \"Decided by\" column reports the same thing for every action the firewall has already seen, so you can trace any verdict back to the rule that produced it. You can also filter the ledger by deciding policy, to see what one rule has actually been doing, or by \"Built-in defaults\" to see the actions no rule covered yet. The Policies screen lists any rule that has decided nothing at all, which catches a rule quietly shadowed by an earlier one - though a rule can also be unfired simply because nothing has attempted what it guards against, so it reports the fact rather than telling you to remove anything. If you have set a retention window, that list says so and names how far back the ledger still reaches, since a rule whose matches were pruned looks the same as one that never matched. That provenance is covered by the ledger's hash chain, so it cannot be rewritten without detection.<\/p><\/dd>\n It is rejected when you save it and nothing is stored. Structural problems, such as a decision that is not one of the recognized values, name the exact position of the error. Beyond that, the plugin rejects rules that would silently do nothing: a rule carrying neither a decision nor a limit, and any rule made unreachable by an earlier rule that already matches everything. If a stored rule is somehow unrecognizable at evaluation time, the action is held for approval; the engine never fails open.<\/p><\/dd>\n Yes, but it is off by default because deleting audit records is not something a plugin should do to you unasked. Set a retention window under \"Ledger retention\" on the Activity Ledger screen and a daily job trims entries older than that. Because the ledger is hash-chained, pruning re-anchors the chain rather than breaking it, and every prune writes its own entry recording how many entries were removed and when - retention that left no trace of itself would be a way to erase an audit trail. Actions still waiting for approval always keep their records. Snapshots are removed with their entries, so actions older than the window can no longer be undone.<\/p>\n\n Both jobs are also available to WP-CLI, along with a summary: Yes. The Activity Ledger screen has a checkbox: \"Email me when an agent trips a rate limit or an ability changes definition\". It is on by default, sends only to the site administrator, and is throttled so a runaway loop produces one message rather than hundreds. Turning it off stops the mail; the anomalies are still recorded in the ledger either way. These are event alerts about your own site - the plugin sends no newsletters, digests or marketing of any kind.<\/p><\/dd>\n Yes. Bind one of the linked user's application passwords to the agent, on the Agents screen. Many MCP clients authenticate with an application password over Basic auth and cannot send a custom Create the password on that user's own profile in WordPress, then choose it from the picker. One password identifies one agent: a password another agent already holds is offered but not selectable. Deleting the password on the profile screen ends the binding, and the Agents screen says so.<\/p><\/dd>\n A write authenticated with an application password that no agent has claimed carries no identity, so there is nothing for a policy to apply to. By default it proceeds and is recorded in the Activity Ledger with the \"untracked\" status - it names the route, the action, and the acting WordPress user, and it joins the tamper-evident hash chain like every other entry.<\/p>\n\n The Agents screen has a checkbox, \"Refuse writes from application passwords no agent claims\", which rejects them instead. Turning it on will also stop any existing integration that uses one, so bind the passwords you want to keep working first.<\/p><\/dd>\n No, and deliberately. A ag_live_...<\/code>), stored as a SHA-256 hash and displayed a single time at issuance. For clients that can only send a username and password - most MCP clients - you can instead bind one of that user's application passwords to the agent, which identifies it just as the token does. An agent can never exceed the capabilities of its linked user, and scopes can pin it down further, to specific action categories or ability patterns.<\/p>\n\nrest_pre_dispatch<\/code>, 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.<\/p>\n\nWhat this does and does not claim<\/h4>\n\n
\n
\n
wp-content\/plugins\/<\/code>.<\/li>\nAuthorization: Bearer<\/code> header.<\/li>\n<\/ol>\n\n\n\n
Does this plugin call any external services?<\/h3><\/dt>\n
What happens to my data when I uninstall?<\/h3><\/dt>\n
wp option update adaf_delete_data_on_uninstall 1<\/code>.<\/p><\/dd>\nDo agents need a special user account?<\/h3><\/dt>\n
Why does it require WordPress 6.9?<\/h3><\/dt>\n
How do I stop all agents immediately?<\/h3><\/dt>\n
Can an agent approve its own held actions?<\/h3><\/dt>\n
manage_options<\/code> capability. The firewall's own admin routes are exempt from agent gating precisely so a human can still step in when an agent is misbehaving.<\/p><\/dd>\nWhat do agents see when an action is blocked?<\/h3><\/dt>\n
reason<\/code> (policy<\/code>, out_of_scope<\/code>, rate_limited<\/code>, untracked_automation<\/code>, lockdown<\/code>), a retryable<\/code> flag, and a plain-language explanation of what would change the answer. Rate limits say that waiting clears them; scope and policy denials say that retrying will not help and a site administrator has to act. Held actions report that they have not executed and should not be resubmitted. Rate-limit denials also carry a retry_after<\/code> value and a standard Retry-After<\/code> header saying when a slot frees, and held actions can be polled at \/pending\/{id}\/status<\/code> with the agent's own token. Well-behaved agents act on this instead of hammering the endpoint.<\/p><\/dd>\nAre there any policies out of the box?<\/h3><\/dt>\n
How do I write a policy rule?<\/h3><\/dt>\n
\/wp-json\/agenticdaisy-firewall\/v1\/policies\/schema<\/code>, which returns the JSON Schema, the accepted values for each dimension, and the defaults.<\/p><\/dd>\nCan I copy my policies to another site?<\/h3><\/dt>\n
How do I check what a rule will actually do?<\/h3><\/dt>\n
What happens if I write an invalid rule?<\/h3><\/dt>\n
Can I stop the audit ledger growing forever?<\/h3><\/dt>\n
wp agent-firewall status<\/code> reports the ledger size, its oldest entry, whether the chain verifies and whether history has been trimmed; wp agent-firewall verify<\/code> checks the chain and exits non-zero if it has been tampered with, so you can run it from cron and be told rather than having to look; wp agent-firewall prune<\/code> applies the window, with --dry-run<\/code> to see what would go first.<\/p><\/dd>\nCan I turn the alert emails off?<\/h3><\/dt>\n
My MCP client can only send a username and password. Can it still be governed?<\/h3><\/dt>\n
Authorization: Bearer<\/code> header; without a binding they arrive with no agent identity, so no policy can apply to them. A bound password identifies the agent exactly as its token would, and the same policies, scopes, rate limits and ledger entries apply.<\/p>\n\nWhat happens to automation that claims no agent?<\/h3><\/dt>\n
Does this govern WP-CLI?<\/h3><\/dt>\n
wp<\/code> command runs with no HTTP request and no credential to identify, so no agent identity exists for it. It is also not a boundary worth defending: anyone who can run wp<\/code> on the server can equally run wp plugin deactivate agentic-daisy-ai-agent-firewall<\/code>. The firewall governs what arrives over HTTP - agent tokens, bound application passwords, the REST API, the Abilities API and MCP endpoints.<\/p><\/dd>\n\n<\/dl>\n\n\n1.6.0<\/h4>\n\n
\n
Authorization: Bearer<\/code> header, so until now they arrived with no identity at all - every policy, scope and rate limit was skipped, and their writes were only recorded as \"untracked\". A bound password identifies the agent exactly as its token does, and the whole pipeline applies: per-call classification of MCP requests, scopes, policy, rate limiting, the audit ledger and undo. Bind one on the Agents screen, choosing from the linked user's own passwords by name. One password identifies one agent, so a password another agent already holds is shown but not selectable, and deleting it on the user's profile ends the binding, which the Agents screen reports rather than hiding.<\/li>\nwp<\/code> command carries no request and no credential to identify, and it is not a boundary worth defending in any case: anyone who can run wp<\/code> on the server can equally deactivate this plugin. This was previously an open question rather than a stated answer.<\/li>\n<\/ul>\n\n1.5.0<\/h4>\n\n
\n
agent_slug<\/code> now and still accepts agent_key<\/code>, returning both, so anything already scripted against it keeps working.<\/li>\n1.4.0<\/h4>\n\n
\n
1.3.0<\/h4>\n\n
\n
1.2.0<\/h4>\n\n
\n
1.1.0<\/h4>\n\n
\n
tools\/list<\/code> and a tools\/call<\/code> that deletes an event are no longer indistinguishable. Protocol handshakes are treated as reads, tool names map to a policy action and entity, batches are judged call by call, and anything unparseable is held for approval rather than passing through. Blocked calls return a JSON-RPC error the agent can act on. Policy rules can target this door with source: mcp<\/code>.<\/li>\nsource: unclassified<\/code>.<\/li>\n1.0.1<\/h4>\n\n
\n
1.0.0<\/h4>\n\n
\n
lockdown<\/code> reason.<\/li>\n0.1.1<\/h4>\n\n
\n
0.1.0<\/h4>\n\n
\n