About

We build the boundary, not the agent.

RuleFence exists for one reason: AI agents can already act inside WordPress, and most sites have no way to say how far. We do not sell the agent. We sell the line it stops at.

  • WordPress-native
  • Local-first
  • GPL-2.0-or-later

Why this exists

WordPress gained a way for external systems to request named actions, and the ecosystem moved quickly to use it. What arrived more slowly was the operational answer to a simple question: when an agent changes something on your site, who decided that was allowed, and where is that written down?

The usual answers are unsatisfying. An API key is not an identity. A role is not a policy. A log line is not evidence. And “we trust the integration” stops being a position the first time an agent does exactly what it was asked to do, at a scale nobody pictured.

So the product is deliberately narrow. It governs the request path between an agent and WordPress, and it does that one thing thoroughly: identity, authorization, decision, execution, evidence, and control.

What we hold to

WordPress is the ceiling
We can narrow what an agent may do. We will never widen it. Removing the plugin cannot leave behind a privilege that should not exist.
Default deny
Nothing is permitted until someone permits it, and uncertainty is resolved by refusing rather than proceeding.
Local-first
Identity, policy, decisions, and evidence live in your database. Governance keeps working on a site with no outbound connectivity.
Evidence over assurance
We would rather show you a verifiable record than tell you to trust one. Verification runs on your installation, not on our claims.
Security is not a plan tier
Editions differ in scale and optional features. Every security control is identical in every edition, and the test suite asserts it.
Say what it does not do
A boundary product that overstates itself is worse than none, because it moves risk out of sight.

How we work

Claims in this product are meant to be checkable. That shapes the engineering more than anything else:

  • Verify on the installed site. Runtime verification re-tests the governance controls where they actually run, rather than asserting them in a test double.
  • Fail closed, visibly. When a control cannot be evaluated or recorded, the request is refused and the reason is written down.
  • Prove the hard cases. Emergency stop, approval replay refusal, and input binding are exercised against real requests over HTTP, not only in unit tests.
  • Write the record for the operator. Decisions are described in operational language, because the person accountable for the site is rarely the person who wrote the integration.
Open source

The plugin is released under GPL-2.0-or-later. You can read exactly how a decision is reached, and you are not required to take our word for the parts that matter most.

How the business works

The free edition is not a decorative trial. It carries the complete authority model and every security control, and it is enough to run one governed agent on a real site.

Paid plans exist for operational scale: approvals and evidence in production workflows on Pro, and governance across multiple sites on Agency. You upgrade when your operating boundary grows — not to obtain a stronger definition of WordPress authority, because there is only one.

There is no per-call fee, and no AI API key is required to use the plugin.

Compare the plans

Talk to us

The most useful thing you can send is a real operating problem — the agent, the Ability, the decision you wanted to express, and why the current controls could not express it.

One boundary, held consistently

Decide how far your agents go.

Start free with one agent and one useful permission on a site you control.