by
agenticdaisy
1 (0 reviews)
Agentic Daisy AI Agent Firewall
An AI agent firewall for WordPress: intercept every agent write, enforce policies, hold risky actions for approval, and undo anything in one click.
Agentic Daisy AI Agent Firewall ranks #51,230 among WordPress.org plugins with 1+ active installations, is #2,394 of 4,566 in the Security category, a 1/5 rating from 0 reviews, and was last updated Aug 7, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Tested up to WP 7 (Current: 7.1.2)
v0.1.1
Current Version v0.1.1
Updated 1 month ago
Last Update on 07 Aug, 2026
Refreshed 7 hours ago
Last Refreshed on
#2,394 of 4,566 in Security
Downloads -41.8% this week
Rank
#51,230
+970 this week
Active Installs
1+
-50%
KW Avg Position
187
1 worse
Downloads
512
+3 today
Support Resolved
0%
—
No change
Rating
20%
Review 1 out of 5
1
(0 reviews)
Next Milestone 10
0+
10+
50,530
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 7 more installs to reach 10+
Rank Changes
Current
#51,230
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
1.0
0 reviews
Overall
20%
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
- 0.1.1
- Last Updated
- Aug 07, 2026
- Requires WP
- 6.9+
- Tested Up To
- 7
- PHP Version
- 8.1 or higher
- Author
- agenticdaisy
Support & Rating
- Rating
- ★ ☆ ☆ ☆ ☆ 1
- 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,758
Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits
30K+ installs
#1,008
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
#17
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
#37
Frequently Asked Questions
Common questions about Agentic Daisy AI Agent Firewall
No. All policy decisions run as plain PHP on your server. Nothing leaves your site.
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.
Each agent is linked to a WordPress user and can never exceed that user's capabilities. Policies and scopes only restrict further, so link agents to least-privilege users.
The Abilities API, the structured way AI agents act on WordPress, shipped in 6.9. Intercepting it is a core feature of this firewall.
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 (policy, out_of_scope, rate_limited, untracked_automation), 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. 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: 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 or themes is held for approval even when it is a create or an update. Anything the firewall cannot categorise is held rather than allowed. The Policies screen lists these defaults so an empty policy list is not mistaken for no protection.
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. 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. The full grammar is available over the API at /wp-json/agenticdaisy-firewall/v1/policies/schema, which returns the JSON Schema, the accepted values for each dimension, and the defaults.
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. 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.
It is rejected when you save it and nothing is stored. Structural problems, such as a decision that is not one of the recognised 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 unrecognisable at evaluation time, the action is held for approval; the engine never fails open.
