by
agenticdaisy
0 (0 reviews)
Agentic Daisy AI Agent Firewall – Approvals, Audit & Undo for MCP
AI agent firewall for MCP and the Abilities API: hold risky agent writes for your approval, audit every action, and undo mistakes in one click.
Agentic Daisy AI Agent Firewall ranks #48,377 among WordPress.org plugins with 0+ active installations, is #3,855 of 5,058 in the Security category, and was last updated Oct 22, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Compatible with WP 7.1.4
v2.1.0
Current Version v2.1.0
Updated 2 weeks ago
Last Update on 22 Oct, 2026
Refreshed 1 week ago
Last Refreshed on
#3,855 of 5,058 in Security
Actively maintained
Rank
#48,377
—
No change
Active Installs
0+
-100%
KW Avg Position
N/A
—
No change
Downloads
928
+1 today
Support Resolved
0%
—
No change
Rating
0%
Review 0 out of 5
0
(0 reviews)
Next Milestone 10
0+
10+
20,809
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 5 more installs to reach 10+
Rank Changes
Current
#48,377
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
0.0
0 reviews
Overall
0%
5
0
(0%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
0
(0%)
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 2.1.0
- Last Updated
- Oct 22, 2026
- Requires WP
- 6.9+
- Tested Up To
- 7.1.4
- PHP Version
- 8.1 or higher
- Author
- agenticdaisy
Support & Rating
- Rating
- ☆ ☆ ☆ ☆ ☆ 0
- Reviews
- 0
- Support Threads
- 0
- Resolved
- 0%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade NowSimilar Plugins
Adminify – White Label, Admin Menu Editor, Login Customizer
6K+ installs
#2,757
Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits
30K+ installs
#1,015
LiteSpeed Cache
7M+ installs
#5
Akismet Anti-spam: Spam Protection
5M+ installs
#8
Wordfence Security – Firewall, Malware Scan, and Login Security
5M+ installs
#11
Really Simple Security – Simple and Performant Security (formerly Really Simple SSL)
3M+ installs
#18
Hostinger Tools
3M+ installs
#20
WPS Hide Login
2M+ installs
#27
Limit Login Attempts Security - Login Security, 2FA, Firewall, Brute Force Prevention
1M+ installs
#33
WP Super Cache
1M+ installs
#36
Frequently Asked Questions
Common questions about Agentic Daisy AI Agent Firewall – Approvals, Audit & Undo for MCP
Yes. Open the live demo - or use the Live Preview button on this page, where it is shown - for a throwaway WordPress site in your browser, running in WordPress Playground, with the plugin installed and a small shop already set up. An AI agent has been at work on it: one of its edits was allowed and can be undone from the Activity Ledger, a page deletion is waiting for your approval, a second deletion was stopped because a person had changed the post first, and a read-only agent was refused for reaching beyond its scope. You land on the approval queue - approve or reject the waiting deletion and see what happens. Nothing is installed on your own site, and reloading the preview starts over.
Not unless you ask it to. All policy decisions run as plain PHP on your server, and by default nothing leaves your site. The one exception is the optional webhook: if you save an endpoint under "Webhook URL" on the Settings page (Agent Firewall > Settings), four events are posted there as JSON - an action held for your approval, an agent tripping its rate limit, an agent denied for reaching outside its scopes or while the kill switch is engaged, and an AI tool changing definition. Each delivery carries what the decision was about and nothing more: the agent's name and identifier, the action category, the kind of entity and its id, the ability names involved, your site's address, the time, the plugin version, and a link back to your own dashboard. The content of a post, an option or an agent's payload is never included, and neither is any credential. You choose that address, clearing the field stops it, and there is no phone-home, no analytics and no third-party service behind any of it.
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: wp option update adaf_delete_data_on_uninstall 1. On a multisite network each site decides for itself: deleting the plugin from the network removes the data of every site that opted in (wp option update adaf_delete_data_on_uninstall 1 --url=<site>) and keeps the rest.
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 not offered: 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 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. The one exception is an MCP plugin whose keys can only run as an administrator. An administrator can confirm that an agent runs as one, and then only the add-on that knows that plugin's keys can sign the agent in; it never gets a token or an application password. Even then, the agent cannot deactivate Agent Firewall or change its settings, and its changes to plugins, themes, users, roles, settings and site templates, anything carrying scripts, and anything the firewall cannot identify wait for a person. No plugin can guard against a tool that runs SQL, PHP or shell commands for an agent, so keep such tools switched off.
The Abilities API, the structured way AI agents act on WordPress, shipped in 6.9. Intercepting it is a core feature of this firewall.
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.
The request the agent sent is sent again, exactly as it was - the same route, the same fields - and it runs as the agent's linked user, not as you. WordPress checks it afresh: if that user is not allowed to make the change, it is refused, the action is marked "refused", and it leaves the queue, because approving it again would be refused again. If WordPress rejects it for another reason, such as an invalid value, it stays in the queue for you to reject. An approved change can be undone from the Activity Ledger wherever an allowed one can - edits and deletions of posts, pages and media. A few held actions cannot be sent again, and the queue says so instead of offering Approve: a file upload, whose file is not kept while it waits; a write caught inside another plugin's code rather than arriving as a request; and an MCP tool that is not backed by a WordPress ability. Reject those, and make the change yourself if you want it.
No. Approval endpoints require the manage_options 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.
A structured error, not a bare refusal. Denials carry a reason (such as policy, out_of_scope, rate_limited, budget_exceeded, untracked_automation or lockdown), a retryable 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; over the Abilities API that arrives as the error code adaf_pending_approval, carrying the id to poll, because WordPress checks an ability's return against the output the ability says it produces and "held for review" matches no ability's declared output. Rate-limit denials also carry a retry_after value and a standard Retry-After header saying when a slot frees, and held actions can be polled at /pending/{id}/status with the agent's own token. Well-behaved agents act on this instead of hammering the endpoint.
The policy list starts empty, but the site is not unprotected. When no rule matches, the firewall falls back to built-in defaults: anything the ability itself declares destructive is held for approval; 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.
