Security

Ansight should be treated as a privileged development surface.

Do Not Ship It Publicly

The default recommendation is simple:

• do not publish Ansight-enabled builds to an app store
• do not ship Ansight all-in-one tool packages or individual tool packages in release or distribution builds
• do not embed developer pairing assets in public builds

Use Ansight in local debug, internal QA, or other tightly controlled development builds only.

If you need release-like validation, prefer internal non-public builds and keep the surface area as small as possible.

Keep the MCP Bridge Local

Ansight Studio listens locally over HTTPS and is intended for localhost-only agent access.

Best practices:

• run Ansight Studio only on trusted developer machines
• do not expose the MCP endpoint beyond localhost
• do not leave the bridge running on shared desktops
• treat all connected agents as privileged

Manage Pairing Configs Intentionally

Pairing configs contain trust material and should be treated as sensitive.

Prefer:

• durations that match the workflow you actually need
• one config per app and environment
• reissuing configs when the current one is no longer appropriate
• removing configs you no longer need

Keep Tool Exposure Narrow

Remote tools are the highest-risk part of an Ansight setup.

Use these rules:

• install Ansight, Ansight.Maui, or individual tool packages only in local development builds when remote tools are enabled
• keep AnsightRemoteToolsPolicy=AllowedWithWarnings scoped to Debug-only conditions, or use Allowed only when you intentionally want to bypass scanning and warnings
• prefer WithReadOnlyToolAccess() over broader guards
• enable write or delete scopes only when a specific workflow requires them
• restrict roots, stores, keys, and prefixes at registration time

Delete-scoped operations should be rare. They are blocked by the standard read-only and read-write guards for a reason.

Treat Captures as Sensitive

Logs, screenshots, database rows, file contents, preferences, and secure-storage values may all contain private or user-specific data.

Best practices:

• export session archives only to trusted locations
• clean up saved captures when they are no longer needed
• avoid copying session artifacts into broad team channels
• use the smallest possible dataset when asking an agent to inspect a problem

Recommended Build Hygiene

Scope packages and properties to Debug-only conditions:

<ItemGroup Condition="'$(Configuration)' == 'Debug'">
  <PackageReference Include="Ansight.Maui" Version="0.1.0-pre9" />
</ItemGroup>

<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
  <AnsightRemoteToolsPolicy>AllowedWithWarnings</AnsightRemoteToolsPolicy>
</PropertyGroup>

<PropertyGroup Condition="'$(Configuration)' != 'Debug'">
  <AnsightRemoteToolsPolicy>Disallowed</AnsightRemoteToolsPolicy>
</PropertyGroup>

In non-Debug builds:

• omit the all-in-one tool packages and individual tool packages entirely, or use Ansight.Core for core telemetry-only builds
• use AnsightRemoteToolsPolicy=Disallowed for protected Release or CI builds
• do not bundle ansight.developer-pairing.json

Practical Checklist

• Use Ansight Studio locally on a trusted machine.
• Use pairing config durations that match the workflow.
• Prefer read-only tools.
• Restrict file roots, preference stores, and secure-storage keys.
• Avoid App Store or public release builds.
• Remove old configs and captures when they are no longer needed.