Security

Ansight is a privileged local development surface. It can expose live app state, screenshots, logs, preferences, files, databases, secure storage, reflection, custom tool execution, and app-specific artifacts to a paired developer workstation and agent.

Core Principles

• Use Ansight in local development, internal QA, and other controlled non-public builds.
• Keep Ansight Studio and its MCP bridge on trusted developer machines.
• Treat paired agents as privileged users of the running app.
• Keep pairing configs short-lived and scoped to the app and environment being debugged.
• Enable only the tool suites and scopes required for the current workflow.
• Treat captures, exported artifacts, logs, screenshots, and tool results as sensitive app data.

Trust Boundaries

Ansight has three separate trust boundaries:

Do not rely on only one boundary. A safe setup combines local Studio access, deliberate pairing, build-time package policy, runtime guard policy, and narrow tool registration.

Pairing Payload Handling

Signed pairing configs and QR payloads are trust material. Prefer short-lived configs and do not bundle them into public builds.

Ansight pairing uses a public/private-key trust model. Ansight Studio issues signed pairing material from its private key, and the SDK validates pairing and host requests against the public config installed in the app. Requests from a different Studio key, copied payloads signed by non-matching keys, and unsigned pairing attempts are rejected by the SDK even if the requester can reach the device on the local network.

If a developer workflow must reuse a pairing config on-device, prefer syncing or importing that config onto the device at runtime, storing it in app-owned secure storage, and loading it from there. This keeps the signed payload out of source control, JavaScript bundles, app resources, and distributable build artifacts.

Tool Scope Model

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

Use deny-all guards outside developer workflows. Use read-only guards first, then broaden only when a debugging task truly needs mutation.

Captures And Data Handling

Logs, screenshots, session JPEGs, touch input, database rows, file contents, preferences, secure-storage values, reflection payloads, and artifact downloads may contain private or user-specific data.

Best practices:

• keep session exports in trusted local locations
• avoid sharing raw captures in broad team channels
• use test accounts and the smallest useful dataset
• delete stale captures and pairing configs
• avoid enabling secure-storage, reflection, or broad file-system tools unless a workflow depends on them

SDK Security Articles

Use the SDK-specific article for concrete package, build, and runtime controls:

• .NET Security
• iOS Security
• Android Security
• React Native Security

Each SDK has different package managers, build flags, initialization points, and platform permissions. Keep the overarching model the same, but implement it using the controls native to that SDK.

Practical Checklist

• Run Ansight Studio locally on a trusted machine.
• Prefer the stdio MCP bridge for agent access.
• Issue pairing configs for the shortest useful duration.
• Rely on SDK pairing-key validation: only requests signed by the Studio key matching the app’s installed public config are accepted.
• Keep pairing files and generated developer artifacts out of source control.
• Prefer runtime sync/import into app secure storage over bundled pairing payloads when on-device reuse is required.
• Keep all-in-one packages and concrete tool suites out of public release builds where the SDK supports build-time exclusion.
• Deny all tool discovery and execution in protected builds.
• Prefer read-only tools.
• Restrict roots, stores, keys, prefixes, reflection roots, and custom tool ids.
• Review SDK-specific security setup before enabling remote tools.