No way to exclude document type properties from being sent to AI

[richarth]

Problem

There is currently no way to configure the package to exclude specific document type properties from being sent to the AI. Every property on a content item is sent, unfiltered, through two separate paths:

1. Backend agent tools — PropertyValueFormatter.ExtractProperties() (Umbraco.AI/src/Umbraco.AI.Core/Tools/Umbraco/PropertyValueFormatter.cs) iterates content.Properties with no filtering, feeding the agent's "read content" tool.
2. Frontend entity context — document.adapter.ts (Umbraco.AI/src/Umbraco.AI.Web.StaticAssets/Client/src/entity-adapter/adapters/document.adapter.ts) serializes every property from the live editor form into a JSON payload sent to the server, which is then rendered into the prompt via CmsEntityFormatHelper.FormatCmsEntity (EntityAdapter/Adapters/CmsEntityFormatHelper.cs).

This has two distinct downsides:

• Sensitive data risk: properties containing internal notes, PII, or secrets accidentally stored in a text field have no way to be excluded from AI context or from agent tool reads.
• Unnecessary payload/cost/latency: properties that are irrelevant to the AI's task (e.g. SEO metadata, tracking IDs, legacy/unused fields) are always included in the prompt context regardless of relevance. On content types with many properties this inflates token usage, increases request latency, and adds cost, with no way to trim it down.

The only existing related mechanism, [AIField(IsSensitive = true)] (EditableModels/AIEditableModelFieldAttribute.cs), only masks provider settings (e.g. API keys) — it does not apply to Umbraco content type properties.

Suggested approach

Add an opt-out mechanism editors/developers can use to exclude a property (or property editor type) from being sent to AI, e.g.:

• A per-data-type or per-property-editor flag (similar in spirit to "Mandatory"/"Readonly" flags on a data type), checked by:
  • PropertyValueFormatter.ExtractProperties / FormatElement on the backend (agent tool reads)
  • document.adapter.ts (and the analogous media.adapter.ts/block.adapter.ts) on the frontend, so the property is never even sent to the server, not just filtered server-side
• Optionally, a global options list (e.g. ExcludedPropertyEditorAliases) for excluding entire editor types (such as all "Label" or a custom "SEO metadata" editor) by default

Both the backend tool path and the frontend context-serialization path need to respect the same exclusion, since they are independent code paths today.

Why this matters

Without this:

• Content authors risk sensitive property values being sent to a third-party LLM provider whenever Copilot/agent tools read or reference that content item, with no way to opt out short of removing the AI package entirely.
• Every AI request pays the token/latency/cost overhead of properties (e.g. SEO fields) that add no value to the AI's task, on every content type, with no way to trim the payload down.