Whether an AI assistant should have access to portal content is rarely the key issue in discussions with customers. What’s more important is: Who determines which data is allowed to leave the company—and how can this be tracked later?
In practice, this often determines whether an AI integration can be deployed in production or gets stuck in the approval loop. This is exactly where Liferay DXP 2026.Q3 comes in.
From a Beta Project to a Full-Fledged Integration
The MCP Server was previously available as a beta. With full support for OAuth 2.0, it has now reached the next stage of development.
An AI assistant’s access thus runs through the same authentication mechanisms already used in the portal for applications and interfaces. For operators, this is an important step: The integration is based on existing identities and can be operated and monitored using existing tools.
Profiles for Different Use Cases
Using MCP Server Profiles, administrators define which actions an AI assistant is permitted to perform in a specific use case.
The actions are grouped by application area. In addition, there are protection mechanisms at the field level and configurable masking options. Multiple separate profiles can be run in parallel—for example, one for an assistant in the editorial department and another for providing information in the service department.
The default settings are intentionally conservative. At the same time, the system logs which accesses a profile permits.
This allows a discussion to be mapped directly within the system—a discussion that would otherwise have to be held anew in every project: Instead of initially granting broad technical access and then restricting it organizationally, the restrictions are technically enforced 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, among other things, email addresses, phone numbers, and credit card numbers.
The mechanism works across all connected tools and generates a complete audit trail.
The main advantage over custom-developed filtering lies in its scope: A custom solution must be implemented at every relevant point, maintained, and re-evaluated whenever new interfaces are added. The integrated protection mechanism, on the other hand, applies centrally to all data passing through the server.
Rules for AI Crawlers
With llms.txt , operators can specify in the site root how large language models and AI crawlers are permitted to use their content.
The principle is based on robots.txt: Sensitive paths can be excluded without having to develop a custom technical solution. The feature is currently labeled as beta.
Interfaces That Describe Their Own Capabilities
The Headless Search API provides more comprehensive, self-describing OpenAPI metadata. AI tools that parse the schema should thereby better understand which functions the API offers and how to call them correctly.
This benefits more than just AI applications. In traditional integration projects as well, clear metadata reduces queries, failed attempts, and the need for additional coordination.
Modular Developer Skills for Development
In the Liferay Workspace, the existing AI rule files are now available as modular Developer Skills. They are organized by frequently used DXP areas, including Site Initializer, Fragments, Frontend Client Extensions, and Objects.
AI agents load only the information needed for the specific task. This keeps the context manageable and can improve the quality of generated customizations.
For development teams already working with AI support, this means, above all, more precise results and less rework in their day-to-day work.
What’s Changing for the Approval Process
A technical connection to a language model can be established relatively quickly. Delays often arise during the approval process—because it cannot be sufficiently documented which data is transferred under what conditions and who established the rules for doing so.
Profiles, field-level protection, masking, and logging provide key building blocks for this. Data protection officers, auditors, and the works council receive answers that are not only organizationally assured but can also be traced within the system.
However, it’s also important to note that some features are optional, while others are still in beta. The direction is clearly evident. For a concrete production decision, however, the level of maturity and suitability must be assessed in the respective use case.
