SiteAgent for Aura

SiteAgent turns every WordPress site into one an AI agent can safely operate — update, maintain, audit, and fix. Once the site is connected to Aura and its approval key is provisioned, mutating actions are gated behind human approval and recorded in a full audit trail; safe batch updates and block edits are snapshotted so they can be rolled back. It’s the on-site half of Aura, the governed control room agencies use to run whole fleets of client sites alongside their servers, CDN, and DNS.

Plugin and core updates are the riskiest thing you do on a live client site. SiteAgent makes them safer: safe batch updates run behind health checks and roll back automatically if the site breaks, and every plugin in that path is zip-snapshotted first. With Aura’s approval key in place, an agent can’t silently push a change — mutating actions wait for a human to approve them. Think of it as the undo button for AI on your clients’ sites.

Install this plugin on any WordPress site to connect it to Aura — no SSH, no wp-admin juggling, no manual logins.

What You Can Do

• Monitor site health — See WordPress version, PHP version, installed plugins & themes, database info, and disk usage in real time.
• Update plugins, themes & core remotely — Push updates to any connected site from the Aura dashboard, no wp-admin login.
• Safe batch updates with auto-rollback — Run chunked updates with health checks; if an update breaks the site, the plugin restores the previous version automatically.
• Per-plugin rollback — Every update is zip-snapshotted first; restore any plugin to its last good state on demand.
• Bulk translation & database upgrades — Update all language packs and run WordPress database migrations remotely.
• One-click connect (magic link) — Connect a site to Aura straight from wp-admin — no manual token copy/paste.
• AI-agent ready (27 MCP tools) — Exposes machine-readable, JSON-schema tools for AI-driven management, including SEO/accessibility/performance/broken-link auditors, on-site SEO-meta read/write (Rank Math, Yoast, SEOPress), and Gutenberg block read/edit. Read tools run on demand; mutating tools are approval-gated through Aura, and every call is audited.
• Zero frontend impact — The plugin only registers REST API endpoints. No scripts, no styles, no database queries on visitor-facing page loads.

How It Works

After activation, click Connect to Aura on the Settings → SiteAgent page for a one-click magic-link connection, or copy the Site Token shown once and paste it into your Aura dashboard manually. From that point, Aura communicates with your site over a signed, authenticated REST API to pull health data and push updates.

Security

Defence-in-depth protects every request:

1. WordPress Application Password — Standard WordPress auth with capability checks (manage_options / update_*). Only authorized administrators can trigger actions.
2. Hashed Site Token — A per-site token sent via the X-Aura-Token header. Only a SHA-256 hash is stored (never the raw token), compared timing-safely. Tokens from older versions migrate to a hash automatically.
3. Brute-force throttling — Repeated bad-token attempts from an IP are blocked.
4. Signed magic-link connect — The onboarding callback is HMAC-signed with a one-time secret and timestamp, so the token exchange can’t be hijacked or replayed.
5. IP / Domain allowlist (optional) — Restrict API access to your Aura instance, with Cloudflare and reverse-proxy header support.

You can rotate the token anytime from Settings → SiteAgent → Regenerate Token.

REST API Endpoints

Core endpoints under /wp-json/aura/v1/:

• GET /status — Full site health report
• GET /updates — Check available updates (core, plugins, themes, translations)
• POST /update/core / /update/plugin / /update/theme / /update/translations — Apply updates
• POST /update/database — Run WordPress database upgrades
• POST /connect — Magic-link token exchange (public, HMAC-signed, 10-minute expiry)

Version 2 endpoints under /wp-json/aura/v2/:

• GET /health — HTTP, PHP fatal, white-screen and DB connectivity checks
• POST /update/batch — Chunked batch updates with auto-rollback on health failure
• POST /rollback/{plugin} — Restore a plugin from its most recent backup
• POST /rules — Receive Aura’s signed operator ruleset; carrying unbind: true it ends this site’s binding instead

While a site is disconnected by Aura, every write endpoint answers
403 aura_site_unbound and reads keep working; the disconnect answer carries
cleanup_complete and leftovers (what the site still holds), and GET /status
reports unbound until the site is reconnected or the remaining Aura data is removed
from the settings screen.

MCP tools under /wp-json/aura/mcp/:

• POST /tools/list / POST /tools/execute — Enumerate and run AI-agent tools
• GET /context — Full site context for AI decision-making

AI Agent Tools (MCP)

SiteAgent ships 29 built-in tools for AI agents. Read tools return information and run on demand; write tools change the site and are queued for human approval through Aura — an agent can never silently mutate a production site.

Read tools:

• get_site_context — WordPress/PHP/theme/plugin/disk/performance snapshot with detected issues
• get_database_info — Database size, largest tables, autoloaded-options weight, expired transients
• scan_security — Scored security posture (file-edit lockdown, debug exposure, SSL, default admin/prefix, open registration, PHP version)
• scan_seo — SEO posture (search-engine visibility, permalinks, XML sitemap, site title) plus a sampled content audit (thin content, missing excerpts/featured images)
• scan_a11y — Accessibility audit over sampled content (images missing alt text, non-descriptive link text, heading structure, document language)
• perf_check — Performance posture (persistent object cache, OPcache, page-cache plugin, PHP version, autoload weight, active plugin count, memory limit)
• scan_broken_links — Link triage over a content sample with no outbound HTTP (empty/anchor-only links, dev/staging hosts, unresolved internal links)
• list_users — Users with roles and post counts, administrators flagged (never returns secrets)
• check_health — Live health gate: HTTP status, PHP fatals, white-screen, database connectivity
• scan_error_log — Tails and severity-groups the error log, surfacing recent fatals
• check_vulnerabilities — Plugin update-currency check against WordPress.org (a version check, not a vulnerability/CVE feed; covers wp.org-hosted plugins)
• check_core_checksums — Core-file integrity against the official WordPress.org checksum manifest (modified/missing/unexpected files, fetched over HTTPS only)
• scan_executable_files — Uploads-directory observations: PHP/executable files, .htaccess overrides, and symlinks (reported, never followed)
• audit_admin_accounts — Privileged-account facts: administrators with recency, admin capabilities outside the role, application-password counts, multisite super admins
• audit_cron — Bounded WP-Cron inventory with sub-60-second-schedule and unresolved-callback fact-flags
• audit_mcp_exposure — Which other MCP servers are registered on this site, and how many abilities pass the discovery rule such a server applies (abilities are registered site-wide, not per-plugin, so a server resolving targets from that registry picks up mutating ones outside SiteAgent’s approval path). The counts describe the abilities, not what any server currently serves. Reports only; changes nothing
• audit_agent_code — Executable code an AI agent authored or can author on this site: Angie code snippets (recorded, agent-authored, live per environment), the SiteAgent Power Pack’s execute-php / file-write / wp-cli flags, and third-party exec stores. Counts and presence only; never file contents, never a verdict. Reports only; changes nothing
• audit_rules — Whether a signed operator ruleset is present and how old it is, 24h block/warn counts, expired-but-listed rules, and the enforcement points in this build. Reports only; changes nothing
• get_seo_meta — Read a post/page’s SEO title, description, and focus keyword from the active SEO plugin (Rank Math, Yoast, or SEOPress)
• list_page_blocks — Read a page’s Gutenberg block structure (block names, attributes, nesting)
• snapshot_get — Retrieve a stored snapshot of page content (reversible write metadata)

Write tools (approval-gated):

• elementor_replay_ability — Executes an approved held Elementor write (destructive, requires Aura approval): claims the hold, re-judges it against the current ruleset, and runs the original Elementor mutation as the user who asked
• update_plugin_safely — Backup, update, health-check, auto-rollback on failure
• clear_caches — Flush object/opcode caches and detected page-cache plugins
• cleanup_transients — Remove expired transients to reduce autoload bloat
• cleanup_orphaned_assets — Find and remove unused media (dry-run by default)
• backup_plugins — Zip-snapshot one or all active plugins as a rollback safety net
• set_seo_meta — Write a post/page’s SEO title / description / focus keyword on the active SEO plugin (Rank Math, Yoast, or SEOPress) — on-site, so it works even when a WAF blocks the plugin’s own REST endpoint
• update_page_block — Update a Gutenberg block’s content or attributes (snapshot-first, reversible)
• create_page_from_blocks — Create a new page from a Gutenberg block spec (draft-first)

Tools are classified by verb so the Aura Fleet gateway applies the right risk and approval policy automatically.

Pro: the SiteAgent Power Pack

Everything above is free and ships in this plugin. Agencies that need an agent to fix a site — not just report on it — can add the SiteAgent Power Pack, a separate companion plugin that registers higher-capability tools through this plugin’s own tool registry.

It is not included in this download and is not distributed on WordPress.org — the tools it adds execute code, so they don’t belong in a hosted repository. It comes with the Aura Agency and Studio plans, or as SiteAgent Pro.

What it adds:

• read_file — read a text file from inside wp-content (jailed; refuses wp-config.php).
• db_query — a single read-only SQL statement (SELECT / SHOW / EXPLAIN), row-capped.
• write_file — write a file inside wp-content, snapshot-first so it can be rolled back.
• run_wp_cli — run an allowlisted WP-CLI command, with no shell and no metacharacters.
• execute_php — run a PHP snippet against the full WordPress API.

These are governed harder than anything in the free set, deliberately:

1. Off until you arm them. The write and code tools do nothing until the site owner sets an explicit constant in wp-config.php for each one. Installing the Power Pack alone enables no writes and no code execution.
2. Human approval, cryptographically enforced. Once the site holds Aura’s approval key (provisioned when you connect the site), each of these calls requires a single-use, signed grant bound to that exact tool and its exact parameters — one only the Aura dashboard can mint, after a human approves the action. A leaked Site Token cannot run them. (Until a site has that key, the gate is dormant — so connect the site from Aura before arming anything.)
3. Reversible where it can be. File writes are snapshotted first, so there’s a previous state to restore.

The safety model is governance, not a sandbox: execute_php is powerful by design. The controls are the constant you set, the human who approves the call, and the audit trail — not a promise that arbitrary code is safe.

Learn more at my-aura.app/siteagent.

About Aura

Aura is a full-stack operations dashboard by Digitizer that brings servers, applications, DNS zones, and CDN pull zones from Cloudways, Hostinger VPS, Cloudflare, and Bunny.net into a single unified interface.

SiteAgent extends that reach into every WordPress installation — so you can manage your entire infrastructure, including WordPress sites, from one place.

Free to Use

The plugin is completely free and open source (GPLv2+). You need a free or paid Aura account to connect your sites. Sign up at my-aura.app.

Links

• Aura Dashboard
• Documentation
• GitHub Repository
• Digitizer

Via WordPress Admin (Recommended)

1. Go to Plugins → Add New in your WordPress admin.
2. Search for SiteAgent.
3. Click Install Now, then Activate.
4. Navigate to Settings → SiteAgent.
5. Click Connect to Aura for one-click magic-link onboarding — or copy the Site Token (shown once) and paste it into your Aura dashboard manually.

Via WP-CLI

wp plugin install digitizer-site-worker --activate

Manual Upload

1. Download the plugin ZIP from WordPress.org.
2. Go to Plugins → Add New → Upload Plugin.
3. Upload the ZIP and click Install Now, then Activate.
4. Navigate to Settings → SiteAgent to connect or get your Site Token.

1. 

   Settings → SiteAgent in wp-admin: site token status, optional IP / domain allowlists, one-click Connect to Aura, and a live connection test.

2. 

   Aura → Apps → Connection tab: connection status, plugin version, release channels (stable / beta), re-test, disconnect, and credential rotation.

3. 

   Health tab: WordPress / PHP / MySQL versions, server info, settings, active theme, and the full plugin inventory with status.

4. 

   Updates tab: SiteAgent rollout control (release channel, auto-update, policy and risk state), update status, and per-plugin database migration status.

5. 

   Fleet AI: the catalog of agent tools every connected site exposes — each tagged Read or Power — runnable across the whole fleet from one control plane.

6. 

   SiteAgent Power Pack: the companion plugin's write and code tools, each off until armed in wp-config.php and approval-gated through Aura.

7. 

   Connections: provider connections (Cloudways, Cloudflare, Bunny, Hostinger, Vultr, xCloud) with resource counts, status, and credential-rotation reminders.

2.19.1

• audit_mcp_exposure‘s elementor.governor block reports proxy_refused_30d — how many times in the last 30 days the door governor turned an authenticated non-browser caller (an Application Password or bearer identity: an agent) away from Elementor’s editor proxy (403 aura_door_proxy_closed, 2.19.0). Anonymous requests get the same 403 but are not counted, so no unauthenticated traffic can write to the site. Same hourly buckets and counters_as_of cutoff as the four existing counters; null when the count could not be read.

2.19.0

• Security: Elementor’s editor-internal MCP proxy (elementor/v1/mcp-proxy) is closed to anything but a browser session while the Aura door governor is active — an Application Password or bearer client is answered 403 aura_door_proxy_closed and pointed at the governed /elementor/mcp door. Six of the eleven governed Elementor writes were reachable there past the governor since 2.16.0; the editor’s own Global Classes / Variables UI is unaffected.
• Security: the door governor’s route matchers are case-insensitive, as WordPress’s REST dispatcher is — a mixed-case spelling of a governed route no longer walks past the transport closer.
• audit_mcp_exposure‘s elementor block now reports Elementor 4.3.0-beta3’s kill switch on the token door (switch: the elementor_mcp_enabled option, absent means off) and which vendored WP MCP adapter and elementor-mcp-composer copies actually resolve on the site (adapter, composer: version and ABSPATH-relative path).

2.18.4

• Security: an empty port after a webhook host (https://hooks.zapier.com:/hooks/..., hooks.zapier.com:/...) is now read as a URL parser reads it, so such URLs are redacted in plain text too — the case 2.18.3 listed as a known limit. A colon followed by anything but a port and a slash is still not a port.

2.18.3

• Security: redaction now reads a URL the way a browser’s URL parser does. A backslash used as the path separator under http, https, ws, wss, ftp or a protocol-relative prefix (https://hooks.zapier.com\hooks\catch\1/…, also percent- or HTML-encoded) is redacted whole, including the part after the first backslash that earlier releases left in place.
• Security: hostname characters a URL parser normalises away (fullwidth and mathematical letters, the ideographic full stop, zero-width and soft-hyphen characters — Unicode 18.0.0’s IDNA mapping table) are mapped before matching, so ｈooks.zapier.com and hooks。zapier.com are redacted like hooks.zapier.com.
• A URL parser’s userinfo (a@b@host, an encoded slash or backslash inside it) and an empty port (host:/) are read as the parser reads them in the backslash and encoded forms above; a plain https://host:/path with nothing encoded is still matched by the older rule that wants a port digit (tracked as #121).
• Redacting a very large field with millions of words now takes about three times the field’s size in memory instead of eighteen.
• Kept as they are: a backslash after a bare host with no scheme, Windows and UNC paths, file: URLs.

2.18.2

• Security: redaction now decodes HTML references (including the double encoding WordPress itself produces on save and render), percent escapes and JSON escapes before looking for webhook URLs, so encoded or double-encoded Make, Zapier, Slack, Discord, IFTTT or Telegram hook URLs are now redacted.
• The whole encoded word is replaced, not just the part that decoded into a match.
• An encoded word whose host only looks like a webhook host is redacted too.
• More than four encoding layers are replaced as a field.

2.18.1

• Security: receiver URLs are now redacted even when their /, : or @ are percent-encoded or HTML-escaped, including numeric character references left without a trailing semicolon. Before this, an encoded Make, Zapier, Slack, Discord, IFTTT or Telegram hook URL could reach an agent unredacted.
• The redaction walk now runs under a total node budget, so a self-referencing payload no longer runs until the request times out; a snapshot payload that exhausts the budget is withheld as payload: null, payload_redacted: true instead.
• The gateway’s early placeholder/grant check now only fires for a caller the IP/Origin allowlist and token throttle would already admit, so a throttled or disallowed caller no longer learns whether its token was right.
• A legacy plaintext token is migrated before an MCP-path grant is verified.

2.18.0

• Security: known webhook endpoints no longer leave the site in a REST response an AI agent reads — Aura’s gateway tools, an MCP client using an Application Password, or any logged-in non-browser caller. Make, Zapier, Slack, Discord, IFTTT and Telegram hook URLs, and Elementor Pro form webhooks on any host, are replaced with aura-redacted:v1:<kind>, including inside Elementor page data and snapshot payloads. People in wp-admin, public visitors and Aura’s own system calls see the real values.
• An agent write that carries a redacted placeholder is refused (aura_redacted_placeholder): leave that field out and the stored value is kept.
• Aura’s own page snapshots stay complete: a signed header proves the read is Aura’s (aura_unredacted_grant_invalid when it does not verify).
• audit_rules reports redacted_24h and placeholder_refused_24h; /status reports redaction.

2.17.5

• Plugin updates: on a host where PHP may not write or delete .php files (WP Engine is the proven case), every Aura-driven plugin change — the self-update, a single or batch plugin update, update_plugin_safely — is refused before anything is touched, with code: aura_php_writes_blocked (or aura_upgrade_dir_unwritable when wp-content/upgrade cannot be written at all). Such a host failed every update at unpack, and the restore that followed deleted the plugin’s non-PHP files: SiteAgent’s own readme.txt, and a plugin’s CSS, JS and images. The check creates and removes a temporary file, and runs only when WordPress writes files directly.
• Restore: a restore checks that it can finish — PHP can write .php files in the plugins directory, and every directory of the plugin is writable — before it deletes anything; otherwise it answers stage: preflight and leaves the directory untouched. A failed install that changed no file is no longer restored at all (restore_skipped: unchanged).
• /status reports the host’s last recorded answer as host: { php_writes, checked_at }, so Aura can stop sending updates to such a site.
• update_plugin_safely returns the refusal’s code and message (it lost both before).

2.17.4

• Self-update: a package that carries the version already running is refused before anything changes. The verified download is inspected in place, the plugin is not backed up, and no install runs. Before this, a same-version request backed the plugin up, reinstalled over the live directory, refused and restored — and on one host lost readme.txt on every run. The refusal answers code: aura_self_update_same_version. An archive that cannot be read falls through to the previous path.
• Self-update: when the post-install version check fails, the message now says what the evidence supports. A verified package with a different version means the upgrader did not replace the plugin directory (aura_self_update_not_replaced); without that proof both causes are named (aura_self_update_version_unchanged).
• Self-update: a restore that cannot finish reports which stage failed (clear or extract), and the message says what is on disk. A failed clear can remove some files before it stops, so the directory is no longer described as untouched.

2.17.3

• Snapshots: an overwrite_file() record now stores the sha256 of the content it wrote (replaced_with_sha256), and restoring that record puts the old bytes back ONLY while the file still holds exactly what the write left there. A file edited since is refused untouched (aura_file_changed_since); a file already holding the old bytes answers already and is not rewritten; a record taken without that hash — a direct POST /aura/v2/snapshot, or a Power Pack older than 0.2.5 — is refused as unfenced (aura_snapshot_unfenced), because nothing proves what it would be writing over.
• Snapshots: every engine write to a path records a write_seq, taken under that path’s lock and strictly increasing per target, so two writes to one file can be ordered after the fact — Aura rolls a run back in that order.
• Snapshots: a file restore that cannot act says why with a code instead of a bare failure — aura_file_changed_since, aura_snapshot_unfenced, aura_snapshot_voided (the create’s rollback record is gone) and aura_path_locked (another write to the path is in progress) — each answered as an HTTP 409 refusal rather than a 500. Restoring a created file that is already gone answers already.

2.17.2

• Snapshots: every engine write to a path — create_file(), the new overwrite_file(), and the restore of a created file — runs under a per-path lock, so two agent writes racing one new file can no longer interleave in the same inode (a concurrent in-place overwrite passed the inode check). After a publish the target must hash to the recorded content, else the record is voided as interrupted and the staged bytes kept.
• Snapshots: overwrite_file() replaces an existing file the way the engine creates one — old bytes snapshotted, new content staged beside the target with its own mode, then renamed over it: a reader sees the old file or the new, never a truncated one, and a short write touches nothing. The Power Pack’s write_file adopts it in 0.2.5.
• Snapshots: on a host without flock() the record and path locks are mkdir() directories (atomic everywhere; a lock older than five minutes is a crashed holder and is broken) instead of running unlocked, which let a stage sweep retire the record of a publish that then completed.
• Snapshots: without link(), an executable created file that was edited since is verified in place and left where it is on file_changed_since — the claim by rename came first and the put-back refused exec bits, stranding the edited file under its .aura-restore-* name.
• Snapshots: delete() removes the record’s lock file with the record.

2.17.1

• Snapshots: create_file() publishes without link(). Most managed hosts put link() in disable_functions for web PHP (Cloudways does), and 2.17.0 refused every new-file create there (unsupported_filesystem). Without link() the target is now claimed with an exclusive create — it refuses an existing path and returns an inode this call owns — and the bytes are written into that handle; ownership is checked by inode after the write, so nothing that took the path meanwhile is ever overwritten. What this mode gives up is the empty-to-complete jump: a reader in the milliseconds of the write can see the file grow. A short write leaves the entry empty, never truncated content. Restoring a created file that was edited since puts it back the same way instead of leaving it aside under its .aura-restore-* name. A publish interrupted mid-write is reconciled by the stage sweep: the record is voided and marked interrupted, the file is never deleted by a restore. create_file() answers published: link | write.
• audit_agent_code: power_pack.create_publish says how a create lands on this host (link or write).

2.17.0

• New read-only tool audit_agent_code: executable code an AI agent authored or can author on this site — Angie code snippets (recorded, agent-authored, and which are live in the environment the loader includes, correlated per snippet directory in both environments), the SiteAgent Power Pack’s execute-php / file-write / wp-cli flags, and third-party exec stores (EMCP Pro sandbox, Atarim exec abilities). Counts and presence only; never file contents, never a verdict. Bounded (200 directory entries per environment, coverage.truncated), null for anything unreadable, { error } per subtree.
• Snapshots: create_file() creates a NEW file with the engine owning the whole create — staged beside the target under a non-PHP name, recorded, then published with link() (atomic, no-clobber) — so no target ever exists without its record and no partial content is ever visible. Restoring the record claims the path with an atomic rename, verifies the claimed file, and removes it only while its bytes still match; a file edited since is put back and refused (file_changed_since), never deleted. The Power Pack’s write_file adopts it in 0.2.4.
• Tool metadata lists an empty parameter map as {} rather than [] (SA#83).
• Generic SiteAgent mutations (batch entry, generic single update, generic rollback) renew the self-update lease between phases and heartbeat it from inside the upgrader’s own sub-phases, so a slow download, unpack or install is never seized as stale, and a lost lease stops the entry rather than racing its successor (SA#80).
• Every Aura-driven mutation of SiteAgent’s own files — self-update, generic single update, the batch entry, the guarded rollback — refuses on a multisite network with aura_self_update_multisite_unsupported: the update lock is per site while the plugin directory is shared (SA#79). Other plugins are unaffected.
• A rule-blocked call now says to scope the rule out of the site with sites, or release it.

2.16.2

• /status‘s door fragment carries observation, a per-site door-version witness bumped atomically by every door-state mutation (never by a mere poll) and clock-floored so a restored backup can never reissue a value it already served, so Aura can order overlapping polls by the site’s own witness instead of request timestamps; elementor.governor reports the current value. The observation witness requires InnoDB for wp_options and 64-bit PHP; without them ordering falls back to Aura’s own request order for that site (elementor.governor reports why via observation_unsupported: engine or php32).
• /status also accepts door_observation_seen — Aura’s own last accepted observation, echoed back — so the site can bump its witness forward, clock-floored, when a restore rewound its own copy behind Aura’s. Accepted for ANY non-negative integer the site’s own witness could ever report (no magnitude ceiling — the witness only counts up); honoured only within a fixed headroom below the class ceiling, silently ignored (200, no bump, no error) above it.
• elementor.governor reports counters_as_of beside the four _30d rolling counters, which observation does not cover; the counters themselves are int|null.
• interrupted / running / held are null, not [], when their own queue could not be read, and observation is withheld entirely whenever any read behind the fragment was unreadable.
• New door_write_unsupported reason reconnect_guard_unavailable: a governed write refuses outright on a $wpdb replacement that cannot disable reconnects, rather than risk a mutation replaying on a session this plugin no longer controls.
• Door writes report a committed tri-state (true / false / unknown) and answer a retryable 503 with may_have_run: true whenever a commit cannot be proven — claims, holds, acks, and rotations alike; replay() now forwards claim()‘s own error instead of a generic one.
• Hold references and pending log-row reservations are derived from the request’s own identity, so a retry after an ambiguous commit finds and reuses its own prior write instead of risking a duplicate.

2.16.1

• /status door fragment and audit_mcp_exposure‘s elementor.governor carry binding, the site’s current binding generation, so Aura can label a departed client’s door-log entries without inferring the generation from the rows.

2.16.0

• Elementor MCP door governance: every write through Elementor >= 4.3’s official MCP server is held for approval in Aura unless an operator allow rule covers it; block refuses; every write that runs is snapshotted first on the site and recorded in a per-site door log Aura drains. New tools elementor_replay_ability, snapshot_get; new routes /aura/v1/door/reject, /aura/v1/door/ack; /status carries door; audit_mcp_exposure carries elementor.governor. Rules gain the allow effect and the design_system / page_create targets.

2.15.0

• audit_mcp_exposure reports an elementor block: Elementor >= 4.3’s official MCP module state, every elementor_mcp_consent row, every Elementor MCP… Application Password across all users (full detail), and the other Application Passwords of edit_posts users as counts. Every list is bounded (50 / 50 / 200) with a truncation flag beside it; no usermeta value over 256 KB is decoded; a scan that fails is reported as { error } in its place, never as an empty list. Read-only.
• aura_worker_app_password_list() accepts an optional byte bound, enforced in the same statement that returns the value.

2.14.0

• Feature: a self-update can now undo itself. Before installing, SiteAgent
  archives its current build — best-effort: a site without ZipArchive or with
  an unwritable backup directory still updates, and the result says
  backed_up: false so the caller knows this one had no way back. After
  installing, SiteAgent asks the new build to prove it came up. The proof is
  written by the build itself: a boot beacon recorded the first time the new
  code serves a request, and a fatal beacon recorded by
  a shutdown guard when the new code dies while loading. A build whose own
  records say it broke is rolled back to the archived one, and compiled
  copies are asked out of the opcode cache (best-effort — a host that
  restricts opcache_invalidate() may serve the old compiled code until its
  cache revalidates). The result reports exactly what happened (backed_up,
  verified, rolled_back). When neither record appears, the update stands
  and says it was not verified, never guessed.
• Feature: one SiteAgent mutation at a time. Every path that can replace
  SiteAgent’s own files — the self-update, the generic plugin update, a batch
  entry, the rollback endpoint — runs under a single per-site claim: taken by
  a conditional insert, seizable only after its holder has gone silent for ten
  minutes (a request that dies never releases), and released only by its
  owner. The self-update additionally renews the claim between its phases,
  so a slow step costs the lease nothing once the next phase begins. An
  overlapping request is answered “in progress” and touches nothing.
• Hardening: backups follow a symlink only while its target stays inside the
  plugin folder — a link pointing out of the tree makes the backup report
  itself incomplete instead of copying unrelated files into an archive.
  Restores never delete through a symlink, root or child, and refuse to run at
  all when a link cannot be removed. A package carrying the version already
  running is refused, because its boot records could not be told apart from
  the old build’s. Backup filenames carry a per-operation suffix, so two
  backups started in the same second never overwrite each other.

2.13.0

• Feature: Aura can now disconnect a site in two phases, and the site
  refuses changes the moment it is told to. When Aura sends a disconnect,
  SiteAgent records it and every mutation on the site — SiteAgent’s own write
  endpoints, MCP write tools, grant-signed calls, and any WordPress REST write
  made with the Application Password or site token of the departing connection
  — is answered 403 aura_site_unbound until the site is reconnected. Reads
  keep working, /status keeps answering, and Aura’s own ruleset endpoint
  stays reachable so the disconnect can be finished or retried.
• Feature: a departing connection’s Application Password stops working
  everywhere, not just on the REST API. WordPress authenticates Application
  Passwords on XML-RPC as well, so a credential the disconnect could not revoke
  is now refused where WordPress decides whether it authenticates at all. Your
  own Application Passwords are untouched, and so is admin login.
• Feature: the cleanup is proven, not assumed. SiteAgent revokes the
  Application Password(s) Aura minted, clears the stored ruleset and the
  gateway public key, forgets the connect bookkeeping, and deletes the site
  token LAST — and only when Aura says the disconnect is final. Every step is
  idempotent, runs in one fixed order, and continues past a step that failed.
  An interrupted disconnect finishes itself on the site’s next page load
  (throttled, at most once every five minutes), so a site Aura can no longer
  reach still converges.
• Feature: the answer to a disconnect now names what is still owed:
  leftovers lists the credentials or stores this site could not prove it had
  released (app_passwords, options, ruleset, grant_pubkey), alongside
  cleanup_complete. An empty list means only the shared site token was still
  outstanding; a non-empty one means Aura must keep waiting.
• Feature: the settings screen tells you when Aura disconnected the site
  (“Disconnected by Aura at …”) and offers Remove remaining Aura data — an
  admin-initiated teardown that runs the same proven cleanup, and only clears
  the disconnect record once everything it names, the site token included, is
  gone.
• Feature: manually connected sites (those with no gateway public key, which
  therefore cannot verify a signed document) can be disconnected with a bare
  { “unbind”: true, … } body on POST /wp-json/aura/v2/rules, authenticated
  by the site token alone. A site that DOES hold a gateway key refuses the
  bare form and requires the signed envelope.
• Safety: every ruleset push now runs under the site-wide claim the connect
  flow already used, so a push, a disconnect and a reconnect can no longer
  interleave. A site already busy answers 503 aura_site_busy, which is
  retryable. A claim left behind by a killed request is taken over after two
  minutes rather than blocking the site indefinitely.
• Safety: reconnecting (magic link) and Regenerate Token now settle the
  previous connection’s outstanding cleanup BEFORE installing a new token, and
  release the disconnect record only after the replacement connection is
  installed and read back — so a reconnect that fails halfway leaves the site
  still refusing the departed connection instead of quietly reviving it.
• Fix: a disconnect record damaged in the database is now REPAIRED — rebuilt
  from the site’s own state, under the claim — and then torn down through the
  ordinary path. Previously a damaged record was a permanent dead end: the
  site refused every change and no control could clear it.
• Diagnostics: /status reports unbound: { at, site_ref } while a
  disconnect is outstanding, and app_password_probe_unproven:
{ count, at, owner } when the site cannot prove an Application Password was
  revoked — the usual reason a disconnect never finishes. Both are bounded and
  contain no secrets.
• New error codes: aura_site_unbound (403 — the site is disconnected),
  aura_site_busy (503 — retry), aura_unbind_incomplete (409 — something is
  still owed; the answer lists it), aura_unbind_unreadable (409 — the
  disconnect record could not be read, which is NOT the same as an incomplete
  cleanup), aura_unbind_unrepairable (409), aura_unbind_marker_stuck
  (500 — everything was removed but the record itself would not delete),
  aura_unbind_marker_malformed (500), aura_unbind_store_failed (500) and
  aura_ruleset_client_mismatch (409 — a disconnect addressed to a different
  Aura client), which the bare unkeyed form now checks too.
• Compatibility: a 2.13 site that is never sent a disconnect behaves exactly
  as 2.12 did. Nothing on the site changes until Aura asks for one.

2.12.0

• Feature: a rule can now apply to some of a client’s sites instead of all
  of them. Aura’s signed ruleset names the site each document was issued
  for, SiteAgent stores that identity, and a rule that lists the sites it
  applies to is enforced only where it belongs. Rules that name no sites are
  client-wide exactly as before.
• Safety: a site that cannot prove its own identity — an older record, a
  document issued before this field existed — enforces EVERY rule rather than
  skipping the ones it cannot place. Scoping only ever narrows on proof.
• Upgrade: the identity is recovered offline from the ruleset already stored,
  by re-verifying its signature locally. No new network traffic, and a site
  whose ruleset has not changed since the upgrade is repaired on its next
  request rather than waiting for the next push.

2.11.0 and earlier

• WordPress.org truncates a Changelog over 5,000 words, and this plugin’s history is longer than that.
  The entries for 2.11.0 and every release before it were moved out of this file verbatim and are kept in full at:
  https://github.com/Digitizers/SiteAgent/blob/main/docs/changelog-archive.md