Whether an AI assistant should access portal content is rarely the decisive question in customer conversations. What matters more is: who determines which data may leave the company – and how can this be traced later?
In practice, this often determines whether an AI connection can be used in production or gets stuck in the approval loop. This is exactly where Liferay DXP 2026.Q3 comes in.
From beta project to regular connection
The MCP Server was previously available as a beta. With full support for OAuth 2.0, it now reaches the next stage of development.
An AI assistant's access thus runs via the same authentication mechanisms that are already used in the portal for applications and interfaces. For operators, this is an important step: the connection is based on existing identities and can be operated and monitored with existing tools.
Profiles for different use cases
With MCP Server Profiles, administrators define which actions an AI assistant may perform in a specific use case.
The actions are grouped by scope of application. In addition, there are protection mechanisms at field level and configurable masking. Several separate profiles can be operated in parallel – for example, one for an assistant in the editorial team and another for providing information in the service area.
The default settings are deliberately restrictive. At the same time, it is logged which access a profile permits.
This makes it possible to map a discussion directly in the system that otherwise has to be held anew in every project: instead of first opening technical access broadly and then restricting it organizationally, the restriction is stored technically and made verifiable.
Masking before data leaves the company
MCP Server Data Masking checks responses and masks configured content before it reaches the AI provider. This includes email addresses, phone numbers and credit card numbers, among other things.
The mechanism works across all connected tools and generates a complete audit trail.
The advantage over custom-developed filtering lies above all in its reach: an in-house development has to be built in, maintained and rechecked for new interfaces at every relevant point. The integrated protection mechanism, by contrast, applies centrally to all data that passes through the server.
Rules for AI crawlers
With llms.txt, operators can define in the site root how large language models and AI crawlers may use their content.
The principle is based on robots.txt: sensitive paths can be excluded without having to develop a separate technical solution. The feature is currently marked as beta.
Interfaces that describe their own capabilities
The Headless Search API provides more comprehensive, self-describing OpenAPI metadata. AI tools that read the schema are thus meant to better understand which functions the API offers and how to call it correctly.
It is not only AI applications that benefit from this. In classic integration projects, too, understandable metadata reduces queries, failed attempts and additional coordination effort.
Modular developer skills for development
In the Liferay Workspace, the previous AI rule files are now available as modular developer skills. They are organized by frequently used DXP areas, including site initializers, fragments, frontend client extensions and Objects.
AI agents load only the information required for the respective task. This keeps the context manageable and can improve the quality of generated customizations.
For development teams that already work with AI support, this means above all in everyday work: more precise results and less rework.
What changes for approval
A technical connection to a language model is established comparatively quickly. Delays often only arise during approval – because it cannot be sufficiently demonstrated which data is transferred under which conditions and who defined the rules for it.
Profiles, field-level protection, masking and logging provide key building blocks for this. Data protection, auditing and the works council receive answers that are not only assured organizationally, but can be verified in the system.
For context, however, it should also be noted: some features are optional, others are still in beta. The direction is clearly recognizable. For a concrete production decision, however, maturity and suitability must be checked in the respective deployment scenario.
