Features Pricing Docs Download
Support
Log in Sign up

Product Overview

Guard Forge is a WordPress security plugin. The free core hardens the install, locks out password guessers, gives every logged-in account two-factor authentication, and keeps an audit trail of who changed what — and it does two things a free security plugin usually does not, and the Avakode build a third.

It checks files against the build wordpress.org actually published, not against yesterday’s snapshot of the same disk: every core file, and every plugin hosted on wordpress.org, is compared with the checksums published for that exact release, so the screen can name a file that is in no official build at all — which is the shape a backdoor has and the one thing a scan-to-scan diff can never see. It chains the audit log: every row carries the hash of the row before it, so an edited or a deleted line is detectable rather than deniable. The Avakode build adds a third: it downloads the published vulnerability advisories (once you switch the feed on, then once a day) and matches them against the plugins and themes actually installed, at their actual versions — free, served seven days behind the licensed feed, with the screen saying which of the two you are reading. The wordpress.org package carries no advisory source of its own: there the advisories come from the Pro add-on, in real time.

The Pro add-on adds a policy that requires two-factor of administrators, a managed web application firewall, a malware scanner, the same advisories in real time, the update that closes them, country blocking, Cloudflare firewall sync, alerts to Telegram/Slack/a signed webhook with quiet hours and a digest, a lockdown that can throw itself, an audit-log export, and an hourly AI verdict on the site’s own event log.

Everything runs inside the site’s own WordPress installation, and what reaches the network depends on the build of the free plugin. The wordpress.org package makes one kind of request: the checksum lookup at wordpress.org, which carries the version, the locale and a slug and never the site’s address. It runs once a day while the file-integrity monitor is switched on in Settings (the monitor is off on a fresh install), and once for each press of “Run scan now” (“Run first scan” in Settings), which asks wordpress.org even while the monitor is off. The Avakode build adds six more, and each of them waits for a switch or a press: the advisory download from api.avakode.com (off until you switch it on in Settings, then once a day, and on “Fetch now”); the “Explain this event” button, when somebody presses it; the answer to the feedback card, which “Send feedback” posts to api.avakode.com/feedback (the card is shown on the GuardForge and Forge Suite screens, 30 days after install at the earliest, and “Not now” sends nothing; the request has no User-Agent of its own, so WordPress puts its default one on it, which names the WordPress version and the site’s address); “Run diagnostics” on the Forge Suite screen, or a repair button beside it, which asks api.avakode.com/health whether the service is up; “Connect Avakode account” on the AI credits card in Settings, which asks api.avakode.com/auth/connect/init for the sign-in address and /auth/exchange when the sign-in sends the browser back, after which the card reads the credits left from /ai/usage when it is shown, and its “Disconnect” button calls /auth/credits-connection/revoke; and “Restore from wordpress.org”, which downloads one core file from core.svn.wordpress.org. In the Avakode build, Explain, the feedback answer and the account connection say something about the site (section 12 lists what Explain sends; the feedback answer carries the score, the comment, the product and the version numbers; the account connection carries the product name and the site’s address, and later its token); the advisory download, the diagnostics check and the restore carry nothing about the site. Pro, a separate plugin, makes requests of its own whichever build of the free plugin sits beside it. Three of them run by themselves, and only once the add-on holds a licence key: the licence check (/licenses/validate, from an admin page or wp-cron and never from a visitor’s page view, the answer kept for a day); the licensed vulnerability feed (/security/vulndb, once a day while the licence is active and the “Keep the vulnerability database up to date” switch on the Vulnerabilities screen is on, which it is until somebody turns it off, and on that screen’s refresh button); and the update check (/updates/guardforge, when WordPress checks for plugin updates, from cron too, or when somebody opens the add-on’s “View details” card; the answer is kept for twelve hours, and installing the update asks once more for a fresh download address). Without a licence key none of the three sends anything. Four more run on a trigger of their own, all to api.avakode.com: Connect (/auth/connect/init when somebody presses Connect to Avakode on GuardForge → License, /auth/exchange when the sign-in on avakode.com sends the browser back, then /licenses/activate; Disconnect calls /licenses/deactivate); the credits (/credits/balance when an administrator opens a screen that shows the balance, kept five minutes, and /credits/pricing on a screen that shows a credit price, at most once in twelve hours, both only with a licence key, and /credits/purchase/checkout when somebody picks a pack in Buy credits); the free trial (/public/trial/activate, once, on a site with no licence key and no trial, from the Start free trial button in the credits chip or, in the Avakode build, from the first press of Explain); and the Geo-IP lookup (/security/geoip, only with Geo-IP blocking on, when a request to the login page, XML-RPC or the REST API needs a country that neither Cloudflare’s country header nor a MaxMind database you provided has given and no answer for that address is kept; it waits three seconds at most and keeps the answer for a week). Usage statistics (/telemetry/batch) are off until somebody answers yes to the prompt that GuardForge’s own screens show once (“Save choices”; “No thanks” and “Ask me later” send nothing): after a yes the add-on queues up to fifty events (screens opened, buttons pressed, the names of settings saved, and, as hashes, errors in the add-on’s own files) and sends them in a batch: an hourly wp-cron event is set up for it, and a page load in the admin area sends early when the queue is nearly full; the batch carries a random install ID, the plugin and its version, the WordPress and PHP versions rounded to major.minor and the locale, and no licence key or site address. The hourly AI verdict (/ai/process) is off until it is enabled and spends credits. The Cloudflare calls the owner’s own token makes and the alert channels the owner sets up (Telegram, Slack, a signed webhook) go straight from the site to those services, not through Avakode.

Guard Forge is built by Avakode (avakode.com) and is one of the Forge Suite tools, alongside Cascade Forge, Velocity Forge, Draft Forge, Lang Forge, Rank Forge, Form Forge, Field Forge, Clearway Forge, Profit Forge and Inclusive Forge. Its landing is guardforge.app.

Forge AI Assistant Online

Hi! I'm the Guard Forge AI assistant. Ask me anything about the plugin — setup, features, troubleshooting, or development.

Just now
Powered by Forge AI · Browse docs