Website security doesn’t end at launch: why WordPress needs ongoing management
Many organisations assume that once a website is live, functioning and hosted on a secure platform, it will always be secure. In practice, those are very different things.
WordPress itself is actively maintained, but a WordPress website consists of much more than WordPress core. It will typically include plugins, themes, user accounts, hosting infrastructure and connections to third-party services, and none of these things remains static. Software changes, new vulnerabilities are discovered, staff join and leave, administrator accounts and permissions change, new integrations are introduced and business requirements evolve. Increasingly, AI systems may also be given access to information and functionality within websites.
But even if your organisation isn’t using AI in this way, AI still needs to be part of the threat model. AI agents can make it easier to discover and exploit weaknesses in websites, APIs and other publicly accessible systems. You don’t have to be using AI yourself for AI to change the security risks your website faces.
That means website security cannot sensibly be treated as something completed when the website launches. The important question isn’t simply “Was this website built securely?” It is “Who is responsible for keeping it secure?”
A modern website is part of your infrastructure
Modern organisational websites are no longer standalone online brochures. They may connect to CRM systems, payment providers, e-commerce platforms, membership databases, booking systems, email and marketing platforms, analytics services, document management systems, external data sources and internal business systems.
These connections are often made through APIs, or Application Programming Interfaces, which allow different software systems to communicate with one another. An API might allow an authorised application to retrieve information, update content, access an order, make a booking, upload a file or trigger another process.
None of this is inherently insecure. The important question is what each person or system is allowed to do. Good security follows the principle of least privilege: every person, application or automated process should have the access it needs to perform its legitimate role, and nothing more. If an integration only needs to read information, why should it be able to change it? If it needs to update one type of content, why should it have administrator access to the entire website?
These are established security principles, but the arrival of AI agents is making them newly important.
AI agents can do more than read your website
Much of the discussion about AI and websites has focused on AI systems reading publicly available content. AI agents take this a stage further: an authorised AI agent can potentially interact with a website or its underlying systems and perform actions on behalf of a user. It might retrieve information, analyse orders, update content, prepare reports or carry out routine administrative tasks.
Done well, this could save considerable time and improve services. Done casually, it introduces risk.
A recent Australian example provides a useful illustration. An AI agent interacting with a gym booking system discovered weaknesses in its underlying API. It was able to circumvent normal booking restrictions and even cancel another person’s reservation.
The important point is that the AI did not create the vulnerability. The weakness was already there. What AI changed was how easily it could be discovered and acted upon.
AI does not suddenly make previously secure systems insecure. But increasingly capable agents may make existing weaknesses easier to find and exploit, sometimes without the person using the agent understanding the underlying technology at all.
The interface isn’t the security boundary
The Australian example also illustrates an important principle in website security: you cannot rely on what somebody can see on the website itself. Removing a button, hiding an option or preventing an ordinary user journey does not necessarily prevent an action if the underlying system or API still allows it.
Security therefore needs to be enforced at the system level. Protected actions should be appropriately authenticated and authorised, regardless of whether the request comes from a person using the website, another piece of software or an AI agent.
This becomes more important as AI makes interacting with software interfaces easier. Previously, exploring an API directly generally required technical knowledge. AI agents are increasingly capable of understanding interfaces and determining how to interact with them, and that changes the practical significance of poorly protected functionality.
WordPress is already preparing for AI agents
This is particularly relevant to us because we develop and manage WordPress websites. WordPress has had a REST API for many years, allowing external applications to interact with WordPress data and functionality, subject to authentication and permissions.
More recently, WordPress introduced the Abilities API, providing a standard way for WordPress core, plugins and themes to define particular pieces of functionality, including their inputs, outputs and the permissions required to use them.
Alongside this, WordPress has developed an MCP Adapter capable of making selected abilities available to AI applications using the Model Context Protocol. This creates the foundations for something potentially very useful: rather than giving an AI agent broad access to WordPress, developers can increasingly think in terms of defined abilities that an authorised system is permitted to use.
An AI agent might, for example, be allowed to retrieve particular information or perform a narrowly defined task without being given unrestricted administrative access to the website. That leads to a new security question. It is no longer simply “How do we keep AI out?” Increasingly, it will be “How do we safely let the right AI agent in?”
Authentication is only the beginning
Knowing which agent is connecting is important, but authentication answers only one question: who or what are you? It doesn’t answer the equally important question: what are you allowed to do?
As AI agents begin interacting with websites and other business systems, organisations need to think about several separate controls:
- Identity: Which user, application or AI agent is making the request?
- Access: Which systems and information can it reach?
- Permissions: What actions can it perform?
- Approval: Which actions should still require human authorisation?
- Logging: Can we establish what information it accessed and what actions it took?
- Revocation: Can its access be removed quickly?
These are not fundamentally new security concepts. We already apply them to employees, administrators, contractors and software integrations. AI agents are another identity to which the same discipline needs to be applied.
Why secure hosting isn’t enough
This brings us to an important distinction between hosting WordPress and managing WordPress. Putting a website on well-maintained, appropriately secured hosting is important, but it does not make the website itself permanently secure.
A WordPress website is a changing software system. WordPress core evolves, plugins and themes are updated, new vulnerabilities are discovered, staff join and leave, administrator accounts accumulate, third-party services are connected, APIs expose new functionality and business requirements change. Every one of these changes can alter the site’s security profile.
The hosting provider can secure the underlying infrastructure but may have no responsibility for a vulnerable WordPress plugin. A plugin developer may release a security update but have no responsibility for ensuring it is applied to your website. A member of staff may manage the website’s content but have neither the expertise nor the responsibility to review administrator permissions, API access or suspicious activity.
This can create a dangerous gap where everybody assumes somebody else is looking after the security of the website. For an organisation that takes cybersecurity seriously, that isn’t a satisfactory security model.
What managed WordPress should mean
A properly managed WordPress service should establish clear, ongoing technical responsibility for the website. That extends considerably beyond providing server space and should include appropriate processes for:
- monitoring and applying WordPress, plugin and theme updates
- responding to newly disclosed vulnerabilities
- reviewing administrator accounts and permissions
- enforcing strong authentication
- removing obsolete plugins, themes, accounts and integrations
- controlling API and other programmatic access
- monitoring suspicious activity
- maintaining appropriate firewall and security controls
- managing changes safely
- maintaining and testing backups
- investigating unusual behaviour
The precise controls will depend on the website and the organisation, but the underlying principle is the same: somebody needs to remain responsible for the security, integrity and recoverability of the website after it launches.
Managed WordPress closes the gap between assuming these things are happening and making them somebody’s explicit responsibility.
A website can be secure today and vulnerable tomorrow
This is perhaps the most important reason ongoing management matters. A serious vulnerability could be announced in a plugin next week. An administrator could leave the organisation next month. A new integration could inadvertently receive more permissions than it needs. An old plugin might remain installed long after its original purpose has disappeared. An API endpoint introduced by third-party software could expose functionality nobody realised was available, or an AI agent might be connected to a system in a way nobody contemplated when the website was originally built.
None of this necessarily means somebody did a bad job when the site was launched. It means that security is a continuing process rather than a finished product.
The appropriate response is not to avoid plugins, APIs, integrations or AI. These technologies provide enormous value. The response is to manage them.
Managed WordPress is a governance decision
This is why we think managed WordPress should be viewed as more than a technical or hosting decision. For many organisations, the website is part of their operational infrastructure. It may process personal information, accept payments, connect to internal systems, provide important services to users and increasingly allow automated systems to interact with organisational data and processes. It deserves appropriate oversight and control.
AI adds another set of questions to that responsibility: What information are we giving AI? What systems are we allowing AI to access? What exactly can it do when it gets there? And can we see what it has done?
But the underlying principles remain familiar. Give people and systems only the access they need. Keep software maintained. Remove things you no longer use. Monitor important activity. Test recovery arrangements. Respond when vulnerabilities are discovered. And make sure somebody is responsible for doing all of those things.
For organisations that take data security seriously, managed WordPress is therefore a governance decision, not simply a hosting choice. It answers a fundamental question:
Who is responsible for the continuing security, integrity and recoverability of our website?
If the answer is unclear, that in itself is a security risk.
'
'