內容簡介
Agentic Daisy AI Agent Firewall 外掛專為限制 AI 代理而設計，透過本地執行的 PHP 規則，保護您的 WordPress 網站不受潛在的 AI 風險影響，確保網站安全。
【主要功能】
• 為每個 AI 代理提供獨立身份認證
• 實施可自定義的安全政策
• 監控和記錄所有操作決策
• 審核排隊機制防止內容衝突
• 速率限制防止無限循環操作
外掛標籤
開發者團隊
② 後台搜尋「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.
Two rejections WordPress reports to nobody. An agent attempt refused before the action runs is now recorded with the “refused” status – a permission failure on every supported version, and malformed input from WordPress 7.1, the first version to expose that. Two cases stay invisible because core returns before any hook fires: an ability registered without a valid permission callback, and one whose input schema is missing entirely.
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.
