Privacy & Sandboxing — Security Architecture Specification

Formal description of Hydite IDE client-side privacy tiers and local sandboxing

Scope: technical alignment document for security audits, compliance assessment, and enterprise procurement review. Not a substitute for the customer's internal risk assessment.

Conformance language: MUST / MUST NOT / SHOULD / MAY follow RFC 2119.

1. Scope and terminology#

1.1 In scope#

• Data residency (source code, project semantic index, prompt context, model responses, telemetry).
• Local process sandboxing (filesystem, commands, network, third-party plugin / MCP / Skill invocation).
• Availability and switching constraints of the three privacy tiers.
• Transport and trust relationship between the IDE client and the Hydite Vtslx AO gateway.

Out of scope: server-side governance of the gateway (see Vtslx AO docs); internal controls of customer-deployed local inference services — only the boundary with them is specified.

1.2 Definitions#

1.3 Control identifier convention#

CTL-<DOMAIN>-<NN> where <DOMAIN> ∈ CFG.

2. Threat model#

Simplified STRIDE, restricted to client-side privacy and sandboxing.

3. Trust boundaries and data classification#

3.1 Boundaries (CTL-BND-01..04)#

1
T0: IDE main process
2
  └─ T1: Agent tool sandbox (OS primitives)
3
       └─ T2: Command / network sub-boundary
4
            └─ T3: Third-party Skill / MCP
5
                    │  Only when mode allows + user authorises
6
                    ▼
7
       Vtslx AO gateway (Shared / Dedicated / Self-Hosted)

3.2 Data assets (CTL-DAT-01..06)#

4. Formal privacy-mode matrix#

4.1 Tier definitions (CTL-PRV-01..03)#

4.2 Behaviour matrix#

4.3 Mode availability constraints (CTL-PRV-04)#

• The High Privacy toggle MUST be visible only in Agent mode. In Edit mode — whose scope is bounded to the current selection and which does not autonomously call the cloud — no separate toggle is exposed.
• When High Privacy is active, the input-box pill MUST show a lock indicator; the status bar SHOULD continuously surface the active privacy level.
• Any attempt to invoke a reachable cloud model while High Privacy is active MUST be denied. If the user has explicitly allow-listed certain cloud models, invocation MUST require an additional confirmation.

5. Sandbox control family#

Hydite Agent runs inside the T1 boundary. This section defines its control family.

5.1 Filesystem (CTL-SBX-01..04)#

5.2 Command execution (CTL-SBX-05..07)#

5.3 Network (CTL-NET-01..04)#

5.4 Third-party code: Skill / MCP (CTL-SBX-08..10)#

5.5 Worktree physical isolation (CTL-SBX-11)#

When Agent Hub runs multiple agents in parallel, each agent MUST execute in its own Git worktree (or temporary branch); writes MUST NOT directly land on the main branch and SHOULD pass a unified review before merging. Consequences:

• A single agent's failure or out-of-scope attempt MUST be confined to its worktree.
• Any agent's writes MAY be rolled back by deleting its worktree in one click.

6. High Privacy mode — formal specification#

6.1 Activation conditions (CTL-PRV-05)#

• The current session MUST be in Agent mode.
• The user activates the toggle on the input-box bottom-left pill, and MUST clear an explicit confirmation panel.
• The confirmation panel MUST itemise: source-code egress, index egress, command network, Skill / MCP network, telemetry.

6.2 Egress contract (CTL-PRV-06)#

Once High Privacy is active:

1. Source code MUST NOT leave the host. Any attempt to send file content, paths or metadata to a non-on-device model MUST be denied.
2. The project semantic index MUST be built and queried by on-device models only. Index data MUST NOT appear in any outbound request body.
3. Prompt context MUST be sent only to on-device models.
4. Telemetry MUST be off.
5. Network access from commands MUST be denied by default. The user MAY allow specific intranet destinations one rule at a time, but public-internet destinations MUST NOT be allowed.

6.3 Inference path restriction (CTL-PRV-07)#

Under High Privacy, inference is restricted to on-device models — including but not limited to:

• Local inference frameworks running directly on the client host.
• Private inference services reachable on the client's local network.

Any inference path pointing to the public internet MUST be disabled. If the user has registered specific cloud models in a permitted-list, invocation MUST trigger an extra confirmation before proceeding.

6.4 UI invariants (CTL-PRV-08)#

• The input-box pill MUST show a lock indicator, visible only while High Privacy is active.
• The status bar SHOULD display "Local-only" or a semantically equivalent badge.
• Exiting High Privacy MUST trigger an explicit prompt that explains the egress policy that will resume.

7. Standard mode — formal specification#

7.1 Data minimisation (CTL-PRV-09)#

• Prompt context MUST pass through Context Hub's local retrieval phase and be reduced to the slices most relevant to the current request.
• Whole-directory scans or full-index snapshots MUST NOT be placed directly into prompt context.

7.2 Transport protection (CTL-PRV-10)#

• Cross-network transport MUST use authenticated, encrypted channels.
• The client MUST verify peer identity. When configured to use a customer-supplied gateway, the client MUST verify the customer-provided certificate or SPKI anchor.

7.3 User-controllable items (CTL-PRV-11)#

The following items MUST be disable-able under Standard mode:

• Telemetry reporting.
• Client auto-update channel.
• Third-party Skill / MCP egress.
• Local response caching.

8. Self-Hosted Enterprise mode — formal specification#

8.1 Deployment assumption (CTL-PRV-12)#

• The customer deploys a Hydite Vtslx AO gateway in their own VPC / intranet.
• The client MUST be configured to a customer-supplied gateway address; Hydite-controlled network nodes MUST NOT appear in the call chain.

8.2 BYOK and identity (CTL-PRV-13)#

• Model API keys and inference credentials MUST be held by the customer (in the gateway or a customer KMS).
• The client MUST support enterprise SSO and SHOULD reuse its session identity for gateway authentication.

8.3 Audit cooperation (CTL-PRV-14)#

• All cross-network requests MUST traverse the customer gateway, which SHOULD provide complete access logs.
• The client SHOULD support exporting a local activity summary that can be reconciled with the gateway logs for unified audit.

9. Telemetry and minimisation#

9.1 Telemetry classification (CTL-AUD-01)#

9.2 Defaults (CTL-AUD-02)#

• Any telemetry containing code snippets, file paths, prompts, or model responses MUST NOT be enabled by default.
• Default-enabled telemetry items MUST NOT contain fields from which code assets could be reconstructed.

10. Auditability and self-verification#

10.1 User-level self-verification (CTL-AUD-03)#

10.2 Enterprise-level self-verification (CTL-AUD-04)#

• The customer's network team MAY configure egress allow-listing for client clusters that only permits the self-hosted Vtslx AO gateway, and SHOULD observe no traffic to unexpected destinations.
• The customer gateway logs SHOULD reconcile, by request count, with locally exported activity summaries.

11. Configuration surface reference#

11.1 Project files (CTL-CFG-01)#

11.2 Command palette (CTL-CFG-02)#

11.3 Settings (CTL-CFG-03, excerpt)#

12. Conformance levels#

For internal customer assessment, two conformance levels are defined:

• Baseline conformance: client default-enabled controls satisfy §5 and §9.
• Enterprise conformance: in addition to baseline, the deployment runs in Self-Hosted Enterprise mode and passes §8 and §10.2 self-verification.

This specification makes no claim of certification under any specific framework (e.g. SOC 2, ISO/IEC 27001, FedRAMP). When deploying in regulated industries, customers SHOULD treat this specification as one input to their compliance self-assessment alongside industry-specific requirements.

13. Revision history#

14. References#

• Agent vs Edit mode — mode switching and the High Privacy entry point.
• Context Hub — the project semantic index as classified in this document.
• Hydite Vtslx AO Overview — server-side specification for the gateway.
• RFC 2119 — Key words for use in RFCs — keyword semantics.