Five Questions to Ask Before You Give an AI Agent Write Access

Uncategorized

Why I’m writing this

I recently hooked Claude up to this blog’s WordPress.com site through MCP so I could draft and edit posts without copy-pasting Markdown into the editor by hand. Convenient — but it’s also an AI agent with write access to my site, and “convenient” and “safe” aren’t the same claim.

WordPress shipped an official MCP Adapter with write capabilities in early 2026, built specifically so tools like Claude can discover and call site functionality directly. That’s one instance of a much bigger pattern: more of the software I touch is growing an “AI agent” door, and each one asks the same underlying question — how much do I trust the client on the other end of that door?

This isn’t really a WordPress post. It’s the checklist I used to think through giving an agent write access to anything, with WordPress MCP as the worked example because it’s the door I happened to be standing in front of.

For a deeper dive than this post attempts, two resources are worth reading directly. Anthropic’s Zero Trust for AI Agents framework covers a tiered Zero Trust architecture, an eight-phase implementation workflow, and the current threat landscape — prompt injection, tool poisoning, privilege abuse — at an enterprise scale. The Cloud Security Alliance’s Agentic Trust Framework is an open, vendor-neutral specification built around a similar five-question structure: identity, behavior, data governance, segmentation, and incident response. What follows here is the same “never trust the client, enforce at the resource” core idea, scaled down to a single self-hosted integration.

The five questions

1. Is there a “restrict to safe subset” setting — and does it restrict at the right layer?

My first move with WordPress MCP was checking whether there was a simple “drafts only” toggle. There was — sort of. WordPress.com’s MCP settings let you enable or disable individual write operations per category (posts, pages, media). That’s a real control, but it operates at the operation level, not the parameter level: publishing is inherent to posts.create/posts.update. There’s no toggle that keeps post creation on while switching the publish option off.

This is the first thing worth checking on any system: when you flip a permission switch, what granularity does it actually operate at? “Can create posts” and “can create posts but never published ones” sound similar and are not the same control. If the tool only offers the coarse version, don’t assume you’ve gotten the fine-grained restriction you wanted just because you found a switch labeled something close to it.

2. What’s actually enforcing my intended limit right now?

After the toggle, I still had two things telling the agent “drafts only”: the MCP tool’s own safety protocol (it requires explicit confirmation before any create/update call goes through), and my own project instructions, which state the agent should only ever create drafts.

Both of those are policy. They depend on the client — the agent, or the instructions I wrote for it — actually behaving. Neither is enforced by the server on the other end. That’s the distinction that matters: policy is what you intend, enforcement is what happens when the policy is ignored, malformed, or bypassed by a bug, a prompt injection, or a misconfigured session. If the honest answer to “what stops this from going wrong” is “the agent is supposed to behave,” you don’t have a security boundary yet — you have a request.

3. Can I push the constraint down to a reduced-privilege identity?

The actual fix, once I asked “is there a role that just can’t do the dangerous thing,” turned out to already exist. WordPress’s Contributor role has edit_posts (create, edit, submit for review) but explicitly lacks publish_posts. If the connector authenticates as a Contributor, a posts.create call with status: publish gets rejected by WordPress itself, no matter what the MCP client sends.

That’s the move worth generalizing: instead of trusting the client to self-limit, find or create an identity for the agent that is structurally incapable of the thing you don’t want, and have the resource enforce it. Most mature platforms — WordPress included — already have some form of least-privilege role sitting there unused, built for human staff, that works just as well for an agent. This is the layer that actually holds up if the client is confused, compromised, or just wrong.

4. Have I verified the live permission state, or only the settings page?

After changing the toggles, I had the agent query the live tool permissions directly against the account rather than trust that the settings UI reflected reality. That check caught a real gap — one write operation was still capable of a direct publish path I thought I’d closed off.

Settings pages are a claim about state, not the state itself. Whether it’s a WordPress MCP dashboard, an IAM console, or a firewall rule table, the UI can lag, cache, or simply be wrong about what’s actually enforced downstream. If the access matters, verify it against the live system doing the enforcing, not the panel that configured it.

5. Should I assume an attacker already assumes this is here?

WordPress now runs over 40% of the web, and the AI-agent write path onto it is a shipped, documented, publicized feature — not an obscure setting. Given that, “does this site have an AI agent connected” is a reasonable default assumption for anyone running automated recon against WordPress sites generally, not a specific insight about my blog. The same logic applies to whatever system you’re connecting an agent to: if the integration is common enough to have its own documentation page, assume it’s common enough to be a checked box on someone’s attack surface mapping.

That’s not a reason to panic — it’s a reason to make sure questions 1 through 4 actually have good answers, since the “nobody would think to check for this” assumption isn’t a control.

[PLACEHOLDER: screenshot — WordPress.com MCP settings page, Read/Write tool toggles by category]

What it looked like end to end, on WordPress MCP

  • Confirmed the write-operation toggles exist, but operate per-operation, not per-parameter (Q1).
  • Identified that “drafts only” currently rested entirely on tool confirmation prompts and my own instructions — both policy, neither enforced (Q2).
  • Set the connector to authenticate as a Contributor, which structurally cannot call publish_posts, moving enforcement to WordPress itself (Q3).
  • Had the agent pull live tool-permission state directly, rather than trust the settings page — this surfaced one operation that still had a direct publish path, which got closed (Q4).
  • Treated “AI is connected to this site” as a known-to-attackers baseline going in, rather than security-through-obscurity (Q5).

Here’s what that kind of live check tends to look like in shape, generically — not my actual current configuration, just illustrative of the pattern:

{
  "operations": [
    { "name": "posts.create", "enabled": true },
    { "name": "posts.update", "enabled": true },
    { "name": "posts.delete", "enabled": false, "reason": "Disabled in MCP settings" },
    { "name": "media.create", "enabled": false, "reason": "Disabled in MCP settings" },
    { "name": "tags.create", "enabled": false, "reason": "Disabled in MCP settings" }
  ]
}

The point isn’t the specific list — it’s that a response like this tells you what’s actually enforced right now, rather than what a settings page claims. If something you expected to be off shows up enabled here, that’s the gap worth closing before you move on.

The checklist

Before giving any AI agent write access to a system:

  1. Granularity check — Does the permission control operate at the level you actually need (parameter, not just operation)?
  2. Enforcement check — Is the limit enforced by the resource, or only by policy/instructions the client is trusted to follow?
  3. Least-privilege identity — Can the agent authenticate as a role/identity that is structurally incapable of the risky action, rather than one that’s merely told not to do it?
  4. Live-state verification — Have you confirmed the actual enforced permissions, independent of the settings UI?
  5. Attacker-assumption check — Are you treating “this system has an AI agent attached” as a known baseline rather than hidden information?

If you can answer all five with something more solid than “I told it not to,” the integration is probably safe to leave running unattended. If not, that gap is exactly where to spend the next hour.

References

[Anth26] Anthropic, “Zero Trust for AI Agents,” claude.com, https://claude.com/blog/zero-trust-for-ai-agents, (2026)

[W3Tech26] W3Techs, “Usage Statistics and Market Share of WordPress,” w3techs.com, https://w3techs.com/technologies/details/cm-wordpress, (July 2026)

Published