KentiCopilot connects your AI tool to Xperience by Kentico. This page describes where the resulting project data travels, what each component records and retains, and which controls you configure yourself.
This page covers KentiCopilot, which is a suite of development tools. It does not cover AIRA, the AI capability built into the administration interface for business users. AIRA processes production content and has its own data-protection statement, see AIRA.
KentiCopilot is designed to accelerate development while helping teams follow Xperience by Kentico best practices and architectural guidance. However, AI-assisted development introduces additional data flows beyond the Xperience platform itself. Source code, content models, configuration data, prompts, and other project information may be processed by AI tools and model providers that operate outside of Kentico's infrastructure.
Understanding these data flows is important to help teams make informed decisions about what information is shared with AI systems, apply appropriate controls, and ensure AI-assisted development aligns with their organization's security, compliance, and data governance requirements. KentiCopilot helps provide context and tooling for AI agents, but customers remain responsible for selecting, configuring, and governing the AI tools and model providers used in their development workflow.
For the security of the Xperience platform itself, see Security guidelines. To make security a recurring part of your workflow, use the recommended security checklists alongside the guidance on this page.
KentiCopilot supplies MCP servers, instruction files, and helper tooling that give an agent tools and context. Your AI tool supplies the agent, and your model provider supplies the language model. Throughout this page, AI tool means the editor (IDE) or agent client you run, for example, Claude Code (opens in a new tab), Cursor (opens in a new tab), or Visual Studio Code with GitHub Copilot (opens in a new tab). It hosts the agent, starts the Management MCP server, and decides what gets sent to the model.
Because responsibility is split this way, different parts of the setup answer different security questions.
| Concern | Owned by | Why |
|---|---|---|
Which data an agent can reach in your Xperience project | Kentico | Determined by what the management API exposes and by whether you enable it at all. |
What the Kentico-hosted MCP servers receive, log, and retain | Kentico | Kentico operates the Documentation and Content Modeling MCP servers. |
Whether any project data leaves your machine at all | You | The Management MCP server, the KentiCopilot skills, and the helper tooling run on your machine. Project data crosses the boundary only through the model provider you connect and the Kentico-hosted MCP servers you choose to use. See What leaves your machine. |
Which model processes your prompts, and whether the provider logs or trains on them | You and your model provider | Prompts and responses travel between your AI tool and the provider you choose, under that provider's terms. |
Which tool results get forwarded to the model | Your AI tool | An MCP server returns a result to the agent. The agent alone decides what goes into the next model request. |
Whether a destructive operation runs without a human confirming it | Your AI tool | Tool-approval prompts are a feature of the agent, not of the MCP protocol or of the Kentico servers. |
The diagram below shows the connections a KentiCopilot setup makes, and which of them cross the boundary of your machine and network. See What Kentico records for what each Kentico-hosted destination retains.
The following table provides more detail on the data flows that do leave your machine.
| Destination | What is sent | Triggered by |
|---|---|---|
Your AI model provider | Your prompts, the definitions of every connected MCP tool, and any tool result your agent chooses to include, which can include content item field values returned by the Management MCP server. | Every turn of the conversation. |
| Documentation MCP server | The search query text, plus the standard metadata of an HTTPS request. | A documentation search or page fetch. |
| Content Modeling MCP server | The project description and draft content model you send for validation. | A content modeling workflow step. |
Public package registries | Requests for the packages that helper tooling depends on. No project data is sent. | Running helper tooling that resolves its own dependencies. |
The largest flow is the one to your model provider, and it is governed by your agreement with that provider rather than by Kentico. Any content an agent retrieves through the Management MCP server can be forwarded to your model on the next turn.
How that data is handled, whether it is retained, logged, or used to improve models, differs between providers and between tiers of the same provider, for example, Claude Code data usage (opens in a new tab). Where your project content carries regulatory or contractual obligations, check the terms of the tool and tier you use against them before you connect an agent to that content.
This section explains what is recorded by Kentico. It applies only to the two Kentico-hosted MCP servers; the Management MCP server records nothing at all.
| Server | Recorded | Not recorded |
|---|---|---|
| Documentation MCP | That a search occurred, how long it took, how many results it returned, and which published documentation pages were returned. Standard request metadata accompanies these events. | The query text itself. It is never written to a log and never stored. Nothing about a documentation search is persisted to a database or file. |
| Content Modeling MCP | Which workflow phase ran and whether it succeeded, together with the high-level answers you give during the requirements phase, such as the number of channels, team experience, and expected content volume. | The draft content model. Content type names, field names, and relationships are validated in memory and discarded. The server has no database and no storage of any kind. |
Neither server persists customer project data. What you send is processed only to produce a response and is discarded afterwards.
KentiCopilot plugins are distributed through a public GitHub repository (opens in a new tab). A plugin packages skills as Markdown instruction files, reference material, and optional helper tooling.
The instruction files themselves contain no executable code. They steer an agent's behavior and carry the security relevance of any dependency you add to a repository, so review them like source code.
The helper tooling is different. It is source code that a skill instructs the agent to run on your machine, for example, PowerShell (opens in a new tab) scripts or a .NET (opens in a new tab) command-line application, and running it requires the matching toolchain. The helper tooling code executes locally with the permissions of the account running your AI tool, and it can read project files, reach local services such as your database or your running site, write output to disk, and download its own dependencies from public package registries. Anything the tooling writes to disk can be read back by the agent and forwarded to your model provider on the next turn.
Treat helper tooling the way you would treat any script you run against your project. Read what it does before you let an agent run it, and grant it only the credentials the task needs. Pass a credential through an environment variable rather than on the command line, where it lands in shell history, and never store one in the installed plugin directory, which is replaced on every plugin update.
Everything is publicly available in the repository, so you can inspect every instruction and every script before it takes effect. Each plugin's README lists what its helper tooling requires and what it does. Pin the version you reviewed, and change anything that does not suit your organization's policies.
This is the only KentiCopilot component that can reach your project data, and the most important one to configure deliberately. See Configure the Management MCP for the setup itself.
The management API is intended for local development only. It provides authentication but no authorization, and must not be enabled on production deployments or on any publicly reachable instance.
Authentication – The management API authenticates callers with a single shared secret of at least 32 characters.
Authorization – The management API authenticates a machine, not a person. Every request executes with administrator-equivalent rights, independent of what the developer operating the agent may do in the administration interface. Workspace and permission checks do not constrain it.
Anyone holding the management API secret has full read and write access to every workspace, channel, folder, and content item in the connected instance. Grant it the same way you would grant an administrator account.
Data made available – Through the management API, an agent can read and write the content repository in full, including complete field values of content items and pages, along with the project's structural configuration. See Reference - Management MCP capabilities for the exact list.
Objects that hold personal data of your customers and users are not exposed. There is no endpoint for contacts, form submissions, members and their personal data, activities, the audit log, consents, or commerce orders and customers.
You can narrow what an agent reaches further by limiting which tools the MCP server exposes, either from your AI tool's own configuration or with the server's command-line options. See Limit the available tools. Tool limits govern what your AI tool can call. The management API itself still answers any request that reaches it directly.
The capabilities reference describes the tool set in general terms. The authoritative list for your project is the set of tools the MCP server advertises to your AI tool in the version you are running, so check there to see exactly what an agent can do against your instance.
The Documentation MCP server at docs.kentico.com/mcp is a public, unauthenticated, read-only search interface over published Xperience documentation. It is a search engine over pages that are already on the public web.
A query can still carry project context, for example, an error message, a class name, or a project name that a developer pastes in to narrow the search. As we discussed in What Kentico records, that text is never logged or stored.
The Content Modeling MCP server at ai.kentico.com/content-model-mcp supplies modeling prompts and deterministic validation tools. The language model runs on your side; the server performs no inference of its own.
This is the non-local KentiCopilot component that receives the most detail about your project, because a modeling workflow deliberately sends it a project description and a draft content model. Nothing you send is persisted, the server has no database and no storage.
Content modeling works from structure and intent, not from real records. Describe the shape of your content, not its contents. Do not paste production content, customer records, credentials, or documents your organization classifies as confidential into a modeling session.