Roadmap
What we are building, and what we will not.
Direction rather than dates. Everything here extends the same control loop — identify, authorize, approve, execute, audit, control — and nothing on this page will arrive by loosening it.
- Direction, not commitments
- Updated with each release
- Security controls stay in every edition
Shipped
Available in 1.0.0 today. Read the changelog for the detail.
- IdentityManaged agents and connections
Per-agent identity, Application Password connections, health tests, rotation, and revocation.
- PolicyDefault-deny permission matrix
Allow, require approval, or block over every discovered Ability, with conservative risk classification.
- ApprovalOne-time, input-bound approvals
Approve-once decisions with expiry, fingerprint binding, and atomic claiming.
- EvidenceHash-chained audit trail
HMAC-SHA-256 chaining, signed head, full-chain verification, and fail-secure writes.
- ControlEmergency modes
Normal, read-only, and paused, applied immediately across every agent and connection.
- AssuranceReadiness and runtime verification
An explainable 100-point score plus checks that re-test the controls on the installed site.
In progress
Work that is underway. It ships when it is verifiable on a real installation, not when a date arrives.
| Theme | What it changes | Status |
|---|---|---|
| Evidence export | Portable, redacted decision records for review outside the site, with the chain verifiable after export. | Building |
| Fleet governance | One console for agents across a WordPress Network, with each site keeping its own authority and its own audit chain. | Building |
| Reusable policy profiles | Named permission standards an agency can apply to a new site without copying decisions by hand. | Building |
| Approval routing | Sending a waiting request to the person accountable for it, rather than to whoever opens the dashboard first. | Design |
Under consideration
Ideas we think are right but have not committed to. Their order will change based on what operators actually run into.
- Richer outcome verification for providers that can return more than a success flag.
- Scheduled governance reviews — a periodic prompt to re-examine permissions that have not been used.
- Per-Ability rate and volume limits, expressed as a governance decision rather than a server setting.
- Staging-to-production policy diffs, so a boundary proven on staging can be promoted deliberately.
- Additional connection identities beyond Application Passwords, where they can be made least-privilege.
Items move between sections, and some are removed. If a plan depends on one of these, ask us where it stands before you build on it.
Explicitly out of scope
Some requests are declined permanently. Saying so here is more useful than leaving them ambiguous.
- Raising the WordPress authority ceiling. The plugin can narrow what an agent may do. It will never widen it.
- A bypass path. No mode, plan, or setting will execute a governed action without the decision and the record.
- Standing approvals. An approval will stay bound to one request and one use. “Approve everything like this from now on” is a permission change, and it belongs in the matrix where it is visible.
- Silent evidence deletion. Shortening retention will always require explicit confirmation.
- Security behind a paywall. Plans will differ in scale and optional features. Every security control stays identical in every edition.
- Mandatory cloud dependency. Governance will keep working on a site with no outbound connectivity.
How to influence it
The most useful input is a real operating problem: the agent, the Ability, the decision you wanted to express, and why the current controls could not express it. That is a far stronger argument than a feature name.
Built on one boundary
Everything new extends the same control loop.
Identify, authorize, approve, execute, audit, control — in that order, every time.