Get Started
Key Takeaways
Applying least privilege protects sites from OWASP LLM06 “excessive agency” risks. Structuring permissions into Read, Draft, and Execute tiers prevents automated tools from acting beyond their intended scope.
Each agent requires a unique credential paired with integration-specific rate limits. Dedicated credentials contain runaway execution loops and allow instant access revocation.
All write actions must remain restricted to staging environments behind mandatory human-approval gates. Creating regular restore points and enforcing draft-only statuses ensures unverified changes never reach live production.
Managed hosting-level integrations provide uniform scoping, authentication, and audit logging at the platform layer. This centralized control eliminates the maintenance burdens and security gaps common to individual plugins.
Teams should initiate AI adoption with a read-only pilot focused strictly on public content before expanding permissions. Auditing weekly request logs confirms system safety and establishes baseline performance before granting higher access.
When you add an AI agent to a site built on WordPress®1, it’s critical to decide exactly what it should be allowed to do: search your posts? Draft a new one? Publish it, change a setting, or delete a page it decides is out of date?
Until recently, the main AI decision for site teams was whether to block crawlers. Now agents want to query, draft, and act on live sites. That turns AI agent access control from a robots.txt setting into a much larger strategy decision.
Most guidance on this topic is written for developers building agents. Much less is written for the team deciding what an outside agent may do to a live website that customers and editors depend on. This guide is for that team. It treats agent access as a permissions question, with a three-tier model (read, draft, execute), the controls for each tier, and a rollout checklist.
What does “limited, safe access” for an AI agent actually mean?
Limited access means an AI agent can reach only the content and actions it needs for one defined job. Safe access means every action it takes is scoped to that job, logged so you can review it, and reversible if something goes wrong. Both rest on a principle security teams already use for people: least privilege.
Least privilege for AI agents means granting the smallest set of permissions an agent needs to do its job, and nothing more. An agent built to answer customer questions about your catalog needs to read published product pages. It doesn’t need drafts, user accounts, or site settings.
The risk least privilege guards against has a name. The OWASP Top 10 for LLM Applications (2025 edition) lists excessive agency as LLM06 and traces it to three root causes: excessive functionality, excessive permissions, and excessive autonomy. Put simply, excessive agency is an agent acting beyond its intended purpose because it was given more reach than the job required.
Why agent access is different from bot blocking
Bot blocking and agent access control solve different problems. Bot blocking decides which automated traffic gets turned away at the door. Agent access control decides what an invited agent is allowed to do once it’s inside. The first is a perimeter question. The second is a permissions question, and it needs its own model.
Keeping malicious bots out still matters. But on the agentic web, where AI agents act on behalf of people instead of only reading pages for them, some agents are ones you want to let in. A support assistant or an internal knowledge tool needs some access to be useful. The goal is to admit the right agents with the right limits.
What can an AI agent read, draft, or execute on my site?
AI agent permissions on a site fall into three tiers. Read lets an agent retrieve content it’s allowed to see. Draft lets it create or edit content that a person must approve. Execute lets it change the live site directly. Start every agent at the read tier, limited to published content, and move up only when a specific job requires it.
| Permission tier | What the agent can do | Example actions | Risk level | Recommended controls |
| Read | Retrieve content it is allowed to see | Search published posts, fetch a page by ID | Low | Published content only, rate limits, unique credential |
| Draft | Create or edit content that a person must approve | Draft a post, suggest metadata changes | Medium | Staging only, human approval, version history |
| Execute | Take actions that change the live site | Publish, delete, change settings, install code | High | Avoid by default; if granted, narrow scope, approval gate, backup first, full audit log |
The tiers aren’t a ladder every agent should climb. Agents that answer questions or power on-site search rarely need more than read access, and execute access should stay rare.
The useful question isn’t what an agent can do. It’s what you’ve decided it’s allowed to do.
Read: Retrieve what the agent is allowed to see
Read access lets an agent search and retrieve content without changing anything. For most sites, the right read scope is published content only: the pages and posts visitors can already see. Drafts, private pages, user data, and admin screens stay out of reach, so the worst case is an agent quoting something you’ve already made public.
WP Engine’s Smart Search AI MCP server is a working example of read-only AI agent access. It exposes two tools: fetch, which retrieves a specific post by its ID, and search, which queries the site’s indexed content. Neither tool modifies or deletes data. A is limited to approved, published content and comes with a unique server URL, permission-based authentication, and built-in rate limiting.
Draft: Create changes that a person approves
Draft access lets an agent create or edit content, but nothing it produces goes live until a person approves it. The safe pattern keeps draft-tier work in a staging environment or an unpublished state, with version history recording each change, so an editor can compare, accept, or discard what the agent produced.
Typical draft-tier jobs include a first pass of a post or suggested meta descriptions. The control that matters most is the approval gate: if an agent can save a draft and also publish it, it has execute access in practice.
Execute: Change the live site
Execute access lets an agent change the live site directly: publishing, deleting, changing settings, or installing code. It carries the highest risk because a single bad instruction takes effect immediately. Avoid it by default. If a job truly needs it, grant only narrow, tested actions, with a backup and an approval step in front of it.
There’s a second reason for caution. An agent that reads untrusted input, such as a customer message or a comment, can be steered by instructions hidden in it (prompt injection). At the read tier, a manipulated agent gives a wrong answer. At the execute tier, it can delete a page.
How do I control which AI agents can access my website?
Effective AI agent access control starts with identity. Give each agent its own credential, grant access through a deliberate opt-in step rather than an open endpoint, and make revocation a single action. Then add rate limits and rotation, so a leaked credential can do only limited damage.
These five controls do most of the work:
- One credential per agent. A unique server URL or token for each agent tells you which agent made a request, and lets you revoke one without disrupting the others.
- Bearer-token authentication. The agent sends a secret token with every request, and requests without it are rejected. Store the token in a secrets manager, never in client-side code.
- Domain allowlisting. When an agent runs inside a browser-based chat widget, restrict which domains can use it, so a copied credential can’t be embedded on another site.
- Rate limiting. A per-agent request ceiling stops a runaway loop or scraping attempt from consuming resources or slowing the site for human visitors.
- Short-lived or rotatable credentials. Rotate tokens on a schedule, and immediately when someone with access leaves the team or a credential may have been exposed.
WP Engine’s Smart Search AI MCP server rate-limits by integration type: general API and custom-code integrations get a 30-request burst capacity refilling at 5 requests per second, while ChatKit sessions are capped at 10 requests per minute. Excess requests are rejected until the limit resets.
Opting an agent in versus leaving an endpoint open
An opt-in model keeps agent access off until someone with authority turns it on, for a specific purpose and a specific credential. An open endpoint is reachable by any client that finds it. Opt-in gives you a record of who approved what. An open endpoint leaves you inferring intent from traffic logs after something has already happened.
WP Engine’s AgentKit and ChatKit setup guide shows what token-based opt-in looks like. You copy an MCP URL and token from the Smart Search AI settings in the WP Engine User Portal, connect the Smart Search AI MCP server in OpenAI’s Agent Builder with bearer-token authentication, and add your domain to OpenAI’s allowlist before turning on the chat interface. Each step is a deliberate decision.
On WP Engine, Smart Search AI MCP access is enabled by default as soon as the AI Toolkit is added to a site, which generates a unique server URL and token. Site owners who want to block Smart Search AI MCP access for a specific website can disable it from the AI Toolkit settings
What guardrails keep an AI agent from changing or deleting content?
Three guardrails do most of the work: keep write actions out of production, require a person to approve them, and make sure every change can be rolled back. Add an audit log that records each agent request, and you can answer what happened, who approved it, and how to undo it. These controls reduce and contain risk; they don’t remove it.
Keep draft-tier work in staging
A staging environment is a copy of your site where changes can be reviewed without affecting visitors. Point draft-tier agents at staging, never at production. A bad output then costs you review time instead of a public mistake.
Put a person in the approval path
Human-in-the-loop approval means the agent proposes and a person decides. Define who can approve which actions, and make sure the agent’s credential can never approve its own work.
Take a restore point before any agent-driven change
Version history covers individual posts. A restore point covers the whole site, database and files together. Take one before granting draft or execute access and before any batch of agent changes. On WP Engine, automatic daily backups create a new restore point every day, with 30 days of checkpoints kept per site. Restoring one typically takes anywhere from a few minutes to several hours, depending on site size.
Log every request
An audit log should record which credential made each request, which tool or endpoint it called, what it read or changed, and when. Without that record, you can’t tell a bug from an attack. Confirm where logs live and how long they’re kept before you connect an agent.
What to do in the first hour after an unwanted change
If an agent makes a change you didn’t intend, contain first and investigate second. Cut off the agent’s access, use the logs to see everything it touched, roll back what needs rolling back, and only reconnect it at a narrower scope once you understand the cause. In order:
- Revoke or disable the agent’s credential so no further requests go through.
- Pull every request that credential made since the last known good state.
- Decide whether to revert individual items from version history or roll back to a restore point.
- Restore, then check the live site and any connected integrations.
- Find the cause: an over-broad permission, a missing approval gate, or a manipulated input.
- Reconnect the agent only at the narrower scope your review supports.
Is hosting-level agent access safer than a plugin or custom API?
Hosting-level access is the most consistently controlled of the three common models, because the platform scopes, authenticates, and rate-limits every connection the same way. Plugins and custom APIs can be safe too, but they move that responsibility onto the site owner or development team, and the outcome depends on how well each one is built and maintained.
| Access model | Who manages permissions | Typical default scope | Main tradeoff |
| Hosting-level (managed Smart Search AI MCP server) | The platform, with site-owner opt-in | Read-only, published content | Less flexible, most consistent controls |
| Site plugin | The site owner | Varies by plugin; can include write access | Fast to set up, depends on plugin quality and updates |
| Custom API | The development team | Whatever the team builds | Most flexible, highest maintenance and review burden |
Each model has a place. A custom API gives a development team full flexibility, at the cost of maintaining all permissions themselves. A plugin is often the fastest way to connect an agent, but default scopes vary, and security depends on the plugin’s code and update cadence.
A managed Smart Search AI MCP server trades some flexibility for consistency. With MCP server hosting handled by the platform, the same authentication, rate limits, and scope apply to every site. That’s the line between site-level AI tools and platform-level infrastructure, which our guide to AI hosting covers in more depth.
AI agent hosting at the platform level also shapes what agents query. Smart Search AI pairs semantic search with a Managed Vector Database, so agents search an index of approved content rather than reaching into the site’s database directly.
What is a safe rollout checklist for giving an AI agent access?
A safe rollout moves an agent from no access to the narrowest useful access, tests it away from production, and keeps a person watching closely for the first month. Work through these eight steps in order, and don’t move an agent to a higher tier until it has run cleanly at the one below:
- Write down the one job the agent is for and the content it needs.
- Start at the read tier, limited to published content.
- Issue a unique, revocable credential for that agent alone.
- Turn on rate limits before the agent goes live.
- Test the agent in staging, including with misleading inputs.
- Put a human approval gate in front of any draft or execute access.
- Take a restore point before expanding the agent’s permissions.
- Review the agent’s request logs weekly for the first month.
FAQs about agent access control
Grant read-only access to content that’s already public, through a credential issued to that one agent. That caps the worst outcome at the agent repeating something visitors can already see. Turn on rate limits and logging from day one, and treat any wider access as a separate decision.
Default to read-only. Answering questions, summarizing pages, and powering search need nothing more. Consider write access only when a specific workflow calls for it, and even then route the agent’s output through staging and a human reviewer, so nothing reaches visitors without someone signing off.
Require every agent to authenticate with its own token or unique server URL, and enable access only for agents you’ve approved. Add rate limits and, for browser-based chat tools, a domain allowlist. A client without a valid credential is rejected, so unknown agents never reach your content.
You should be able to, and it’s worth checking before you connect anything. With a per-agent credential, revoking access means disabling or rotating that one token, which cuts off the agent without touching any others. If removing one agent means changing a shared password or code, your access model is too broad.
Look at the request log tied to that agent’s credential. A useful log shows each tool or endpoint called, the content read or changed, and a timestamp. For draft-tier agents, version history and staging comparisons show exactly what changed. If you have neither, add logging before you expand the agent’s access.
Start small and on purpose. The safest first step is read-only access to published content through a unique, revocable credential, with rate limits and logging turned on. Every permission beyond that should be its own decision, made for a specific job, with a person who can approve, review, and reverse what the agent does.
- WP Engine is a proud member and supporter of the community of WordPress® users. The WordPress® trademark is the intellectual property of the WordPress Foundation. Uses of the WordPress® trademarks in this website are for identification purposes only and do not imply an endorsement by WordPress Foundation. WP Engine is not endorsed or owned by, or affiliated with, the WordPress Foundation. ↩︎
