AI-assisted WordPress plugin development has a specific failure profile. The generated code usually works. It activates, renders, saves settings, and does the thing you asked. What it frequently gets wrong is the set of conventions that WordPress treats as non-negotiable: escaping output, sanitizing input, verifying nonces, and checking user capabilities before acting.
That failure profile is not random. These are the parts of plugin development where a model produces plausible code rather than correct code, because the insecure version and the secure version look nearly identical. A function that echoes a stored value and a function that escapes it differ by one wrapping call. The difference is invisible in a functional test and decisive in a security review.
This article lays out a nine-stage build process that treats security as a verification pass rather than an afterthought. It follows the WordPress plugin workflow in the AI Engineering OS methodology and its plugin-specific checklist, and it separates official WordPress requirements from practical recommendations.
Why this failure profile exists
WordPress is unusually explicit about its security conventions. The official plugin developer handbook documents validating, sanitizing, and escaping as distinct operations, and the developer resources cover nonces and capability checks as standard practice. None of this is hidden or debated.
The problem is that these conventions are contextual. Escaping depends on where the data lands: HTML body, attribute, URL, or JavaScript require different functions. Sanitization depends on what the data is: a text field, an email, a URL, a numeric ID. A model producing code without knowing the destination context will pick a function that looks right and frequently is not.
There is a second reason, specific to AI-generated code. The security mistakes that appear in AI-assisted projects are not novel. They are the same recurring errors that have always existed in hand-written plugins. AI has not invented them. It has made them much faster to produce at scale. That reframing matters because it points at the fix. If the errors are known and enumerable, they can be checked systematically, which is exactly what a checklist does better than vigilance.
The nine-stage plugin build process
The workflow runs a fixed sequence with a gate on each stage.
| Stage | Key actions | Gate |
|---|---|---|
| 1. Understanding | Read material and site context; confirm purpose, users, environment | Understanding approved |
| 2. Requirements | Functional, compatibility against WordPress core and PHP, coexistence with other plugins, quality | Requirements baseline frozen |
| 3. Research | WordPress coding standards, hooks and APIs, security patterns, performance patterns | Research approved |
| 4. Planning | Files, hooks, data, build order, risks | Plan baseline frozen |
| 5. Architecture | Plugin structure, main file, activation and deactivation, data handling, security model | Architecture baseline frozen |
| 6. Development | Implement in approved units with proper hooks, escaping, sanitization, nonces, capability checks, upgrade-safe patterns | Unit gates |
| 7. Verification | Functional, security, performance, compatibility, regression, validation, integrity | Verification approved |
| 8. Documentation | Installation, configuration, hooks and filters docs | Docs reviewed |
| 9. Packaging | ZIP packaging, upgrade path, rollback notes | Release-ready |
Two features of this sequence are load-bearing.
The architecture stage produces a health model before any code exists. A plugin’s security posture is largely determined by decisions made here: what data it stores, who can access which actions, what runs on activation, and how it handles uninstall. Deciding these during development means deciding them one file at a time, which is how a plugin ends up with inconsistent permission rules across screens.
The verification stage is named as security-focused rather than generic. The plugin workflow’s verification step includes escaping, sanitization, nonces, and capabilities as explicit items alongside performance, compatibility, and regression. Naming them is what makes them checkable.
The four WordPress security conventions
These four appear in the official documentation and form the core of the plugin checklist. Each one addresses a different attack surface.
Escaping output
Escaping happens at the moment data is rendered, and the correct function depends on the destination. WordPress provides distinct functions for HTML text, HTML attributes, URLs, and JavaScript contexts. The rule of thumb is to escape as late as possible and to escape for the specific context rather than applying a generic function everywhere.
The practical instruction for AI-assisted work is to specify the destination when generating. “Echo this option value” produces a guess. “Echo this option value inside a data attribute in an admin table” produces the correct function.
Sanitizing input
Sanitizing happens on the way in and depends on the expected data type. A display name, an email address, a URL, and an integer option each need a different treatment. WordPress provides sanitization functions for the common cases.
The pairing rule matters here. Sanitizing input does not remove the need to escape output, because sanitized data can still be rendered into a context where it breaks out. Both steps exist because they defend against different things.
Verifying nonces
A nonce is a token that confirms a request came from where it claims to come from. WordPress nonces are created when a form or link is generated and verified when the request is handled. Without verification, an attacker can construct a request that a logged-in user’s browser submits without their knowledge.
The practical detail that trips people up is that nonces are checked on state-changing requests, which includes AJAX handlers, form submissions, and admin-post handlers. Modern WordPress practice treats GET requests that change state as a defect regardless of nonce handling.
Checking capabilities
Capability checks answer a different question from nonces. A nonce verifies that a request was intentional. A capability check verifies that the user is permitted to perform the action. Both are required, and confusing them is a common error.
This is the convention most likely to be inconsistent in AI-generated code, because permissions logic tends to be scattered across handlers. Centralizing it in the architecture stage is what prevents a plugin where one screen checks for an administrator and another only checks that a user is logged in.
There is a useful way to remember how the four relate. Escaping and sanitization handle data. Nonces and capability checks handle requests. A plugin needs all four because data can arrive from a request you did not authorize, and an authorized request can still carry data you mishandle downstream. Teams that treat the four as one topic tend to implement one well and forget the rest.
The plugin checklist as a working tool
The methodology’s WordPress plugin checklist is a domain-specific list rather than a generic development list. That specificity is the point. A checklist that could apply to any project guides none.
For plugin work, the items that consistently produce findings are worth calling out:
| Check area | What usually fails | Why it matters |
|---|---|---|
| Escaping | Output escaped late, or escaped for the wrong context | Context-dependent; functional tests cannot detect it |
| Sanitization | Input trusted because the form validated it | Client-side checks are not a security control |
| Nonce verification | Present on forms, missing on AJAX and admin-post handlers | Every state-changing entry point needs one |
| Capability checks | Checked on the main screen, not on every action | Permissions must be enforced at the handler |
| Upgrade safety | Stored data shape changed without a migration path | Breaks existing installs on update |
| Uninstall behavior | Data left behind, or deleted without user intent | A documented decision matters more than the choice |
| Compatibility | Assumed PHP version, WordPress version, or plugin coexistence | Requirements stage is where this belongs |
| Prefixing and namespacing | Generic function and class names | Collisions with other plugins cause hard-to-diagnose faults |
The last row is worth explaining, because it is not a security issue and it causes some of the most confusing bugs. WordPress runs thousands of plugins in one global space. A function named get_options will eventually collide. Prefixing everything is unglamorous and prevents a category of failure that presents as a mystery.
Two other checklist items deserve expansion because they are frequently skipped.
The first is upgrade safety. A plugin that changes the shape of its stored data without a migration path will break existing installs the moment it updates. The failure is silent at the author’s end if they tested on a fresh install, and loud at the user’s end where the site already has data in the old shape. This is why the plugin workflow’s packaging stage includes an upgrade path and rollback notes rather than treating packaging as a zip operation.
The second is the difference between deactivation and uninstall. Deactivation should stop the plugin’s behavior without destroying data, because a user may deactivate to troubleshoot and intend to reactivate. Uninstall is the point where a deliberate decision about data removal is made. Conflating the two produces either data loss during troubleshooting or permanent residue after removal, and both generate the kind of support request that damages trust in a plugin’s reliability.
Building this with AI assistance
The process works with an AI model, but only if the model is working inside the structure rather than around it.
Load the standards before the code. The model needs WordPress-specific conventions in context, not generic PHP knowledge. The plugin workflow’s research stage exists to gather coding standards, hooks and APIs, and security patterns before implementation.
Build in units, not in one dump. The workflow specifies unit gates. A plugin delivered as a single large output is reviewed once, at the end, when a security finding means re-reviewing everything. Units allow each piece to be verified as it lands.
Ask for the destination context when generating output. This single habit removes most escaping errors, because it lets the model select the correct function instead of a plausible one.
Require evidence, not confirmation. Asking a model whether its code is secure produces a confident answer regardless of the truth. Asking it to list where each escape, sanitize, nonce, and capability check occurs produces something you can verify. If the list has gaps, the gaps are the findings.
Keep the verification pass separate from development. The methodology runs verification as its own stage with its own gate. Combining it with development means the same pass that wrote the code judges the code, which is precisely the review structure that misses its own errors.
What to verify before you ship
A pre-release pass for a plugin, regardless of how it was built.
- Every output is escaped for its specific context, not generically.
- Every input is sanitized according to its expected type.
- Every state-changing entry point verifies a nonce, including AJAX and admin-post handlers.
- Every action checks a capability, not merely that a user is logged in.
- Every function, class, and option name is prefixed or namespaced.
- Stored data changes include a migration or a backward-compatible read.
- Activation, deactivation, and uninstall each do something deliberate.
- Compatibility claims state the tested WordPress and PHP versions.
- The plugin coexists with a second plugin that uses similar hooks.
- Installation and configuration are documented for a user who did not build it.
Items one through four are the security core. Items five through seven are the ones that generate support requests. Items eight through ten are what distinguish a plugin someone can adopt from one only its author can run.
Limitations to be honest about
This process reduces known error classes. It does not make a plugin secure in an absolute sense. Security depends on the surrounding environment, the other plugins installed, the hosting configuration, and decisions a checklist cannot make for you.
The methodology is also explicit that it does not guarantee production success, and that implementation quality depends on the project, environment, tools, and inputs. A checklist verified by a model that misreads the checklist is still a failed check. That is why the plugin workflow ends with a completion gate approved by the person running the project rather than by the AI.
A further limitation is specific to AI-assisted work. Models improve, and their default output changes over time. A process built around known recurring errors stays useful as the errors change, because the checklist items are stable concepts. That is the argument for checking conventions rather than checking for a particular model’s known weaknesses.
There is one more honest caveat about process itself. A checklist is only as good as the reviewer applying it, and it is easy to mark items complete by pattern-matching rather than inspection. The methodology’s requirement that verification report evidence rather than claims exists for this reason. “Escaping verified” is a claim. “Line 214 escapes an option value for a data attribute context” is evidence. The second version costs more to write and is the only version that catches anything. For each security item, require a location rather than an assurance. Locations can be checked in seconds; assurances cannot be checked at all.
The WordPress plugin security documentation and the handbook section on validating, sanitizing, and escaping are the authoritative references for the conventions described here. The studio maintains a plugin development toolset alongside a book production system and a free tools platform.
FAQ
Does AI-assisted development make WordPress plugins less secure?
It changes the speed at which known error patterns appear, not the patterns themselves. The recurring mistakes in AI-generated plugin code are the same ones found in hand-written plugins: missing escaping, absent nonce checks on AJAX handlers, and inconsistent capability checks.
Is sanitizing input enough, or do I also need to escape output?
Both. They defend against different things. Sanitizing constrains what enters storage. Escaping prevents stored data from breaking out of the context where it is rendered. Skipping either leaves a gap.
Where do I put a nonce check?
On every state-changing entry point: form submissions, AJAX handlers, and admin-post handlers. Modern practice treats a state-changing GET request as a defect regardless of nonce handling.
What is the difference between a nonce and a capability check?
A nonce confirms the request was intentional. A capability check confirms the user is permitted to perform the action. Both are required and neither replaces the other.
Should a plugin delete its data on uninstall?
That is a product decision, not a technical one. What matters is that it is deliberate and documented, and that the user’s expectation is matched. Silent deletion and silent retention both cause complaints.
Why does prefixing matter for security?
It is not a security control, but it prevents collisions with other plugins that operate in the same global namespace. Collisions produce faults that are difficult to diagnose and are often misattributed to unrelated plugins.
Can I rely on a model to tell me whether its code is secure?
No. Ask for a list of where each check occurs and verify it yourself. A model asked for assurance will provide it whether or not it is warranted.
The takeaway
Secure WordPress plugin development with AI comes down to treating four conventions as gates rather than preferences: escape output for its context, sanitize input by type, verify a nonce on every state-changing entry point, and check a capability on every action.
The build process around them matters as much as the conventions. Decide the security model at architecture, build in verified units, and run verification as a separate stage with evidence you can inspect. The generated code will look finished either way. Only the process tells you whether it is.