Local access (Agency)

Reviso can be driven by an AI agent: reading the feedback on a page, replying, resolving, and editing the page itself. Normally that runs through Reviso Cloud, which relays your agent’s calls down to your site.

Some agencies cannot use a relay. If you hold mandates in law, insurance, healthcare or the public sector, sending client feedback, screenshots and page content through a hosted service abroad is a processor and third-country-transfer question you may not be able to answer.

Local access is the same feature with the relay removed. Your agent talks to your site directly, authenticated with a WordPress application password. Nothing reaches getreviso.io.

Local access is part of the Agency plan, and it is off by default.

What it changes, and what it does not

Nothing about how Reviso works changes. Every one of the thirteen operations (reading reviews and comments, fetching a screenshot, reading a page’s structure, replying, resolving, assigning, refining, updating an element, inserting one, reverting) already runs on your own server. Reviso Cloud never executed any of them; it only forwarded the request.

Local access simply lets your site accept a second credential. Turning it on does not disconnect Reviso Cloud, and turning Reviso Cloud off does not affect local access. They are independent.

Turning it on

Settings → Reviso → Reviso Cloud → Local access → Turn on.

You need HTTPS. WordPress refuses to issue application passwords over plain HTTP, and Reviso refuses local requests over it too. The credential is replayable and these routes can rewrite page content, so this is not negotiable.

Creating an application password

Application passwords are a WordPress core feature, not a Reviso one. They are per-user, individually named, and individually revocable.

1. Go to Users → Profile and scroll to Application Passwords.
2. Enter a name that identifies the agent, such as “Claude Code” or “Ops laptop”. The name is how you will know what you are revoking later.
3. Click Add New Application Password.
4. Copy the password. WordPress shows it once. If you lose it, delete it and make another.

Give your agent three things:

Address	https://your-site.com/wp-json/reviso/v1/mcp/ready
Username	your WordPress username (not your email)
Password	the application password you just copied

They go together as HTTP Basic authentication, which is what almost every client uses by default. Your exact address is shown on the settings screen once local access is on.

To check it works:

curl -u "USERNAME:APPLICATION PASSWORD" https://your-site.com/wp-json/reviso/v1/mcp/ready

A JSON response means you are connected. 401 or 403 means something below applies.

Who gets access

Any user who can edit posts on the site, and who holds a valid application password.

That is deliberately the same bar as editing a page in wp-admin, because that is what these routes do. If you want it tighter (administrators only), add this to a small plugin or your theme’s functions.php:

add_filter('reviso_local_mcp_capability', fn() => 'manage_options');

Deleting the application password revokes that agent immediately. Turning local access off revokes every agent immediately. Both take effect on the next request; there is no cache to wait out.

If it returns 401 or 403

What you see	What it means
403 with local access on and a correct password	The site is not on the Agency plan, or the user cannot edit posts
401	The username or application password is wrong, or none was sent
401 after several wrong attempts	Ten failures from one address locks it out for fifteen minutes. Wait, then retry with the right password
Anything over http://	Local access refuses plain HTTP

Every one of these is recorded, see below, so if you are unsure which applies, the log will tell you.

The audit trail

Every local call is logged, allowed or refused, with the route, the method, the user, and the reason for any refusal. Refusals are logged as well as successes; a log of successes only is not an audit trail.

On a retainer this record is often part of what you are selling. It is the same table Reviso uses for review history.

Showing that Reviso Cloud is not in use

For most people, never connecting is enough. If you have to demonstrate it, to a client’s DPO or in a processing register, “we did not connect it” is a weaker claim than “it is switched off”, because an unused connection is still a connection that could be made.

There are two ways to switch it off, and they answer different questions.

From settings. Settings → Reviso → Reviso Cloud → Switch Reviso Cloud off. The site stops sending anything to getreviso.io and refuses the Reviso Cloud credential outright, whether or not an account is connected. Local access is unaffected.

This is reversible from the same screen, which is convenient and is also its limitation: an administrator can switch it back on.

In code. Put this in an mu-plugin:

add_filter('reviso_cloud_enabled', '__return_false');

This overrides the setting and cannot be undone from wp-admin. It sits in the filesystem under whatever change control the site already has, which is usually what counsel is actually asking for. The settings screen will say so, and will not offer a control to re-enable it.

Questions we are still asking

Which of those two forms a German mandate actually requires is a question we have put to the agency that asked for this, rather than guessed at. If your compliance requirements need something else (a wp-config.php constant, per-route scoping, a signed attestation), tell us at ben@getreviso.io. We would rather build the thing that is genuinely accepted than the thing we imagined.