Hacker News new | ask | show | jobs
Verantyx – A native IDE that obfuscates code before sending it to Cloud LLMs (github.com)
4 points by kofdai 97 days ago
1 comments

I’m a student developer building Verantyx, a native macOS IDE solving a core dilemma in AI coding: We need the reasoning power of frontier models like Claude 4.7 Opus, but cannot legally or ethically leak proprietary source code, hardcoded secrets, or core business logic to their APIs. With the industry worried about losing "tacit knowledge" to AI, I built an architecture where the human retains ultimate control over semantics, while the AI is relegated strictly to structural logic patching. To achieve this, I built the "Gatekeeper" architecture. Before code leaves your local Apple Silicon machine, a Rust core parses the AST and converts it into "JCross IR"—a custom intermediate topology. It deterministically masks high-value identifiers (e.g., calculateTax() becomes [Symbol_A]()) while preserving structural logic and control flow. The Cloud LLM receives this obfuscated puzzle, writes a patch, and returns it. The local Rust vault then maps the IR patch back to your original source code. The Tech Stack & Architecture • Core (Rust): Handles the zero-copy memory vault, deterministic JCross IR generation, and AST parsing. The mapping dictionary is held strictly in local memory and never leaves the machine. • Frontend (Swift): Native macOS UI. Achieves 0-latency state sync (a 1-frame toggle response) between "Raw Code View" and "AI's JCross IR View" without heavy disk I/O. • The VS Code Bridge: To support LSPs without Electron's memory bloat, I built a background Node.js Extension Host communicating via JSON-RPC. Managing state synchronization between the Swift UI, the Rust Vault, and the Node.js host to prevent race conditions during reverse-compilation was an absolute nightmare. The Gatekeeper Flow 1. Request: User prompts the Swift UI for a refactor. 2. Obfuscation: Rust converts the file to JCross IR, locking the mapping dictionary in local memory. 3. Transmission: Swift sends only the JCross IR to the Cloud LLM. 4. Reasoning: The LLM processes the obfuscated topology and returns an IR patch. 5. Restoration: Rust uses the local dictionary to reverse-compile the IR patch back into raw code. 6. Approval: Swift presents a Diff UI to the user for final approval. Honest Trade-offs & Limitations • Semantic Loss Penalty: Blinding the AI to domain-specific context (e.g., it doesn't know [Symbol_A] means "DB Connection String") occasionally leads to syntactically correct but logically flawed code. • AST Topology Destruction: This is the most critical issue. When given complex instructions, frontier models sometimes hallucinate and destroy the AST topology of the obfuscated IR. When the structure is broken, the Rust vault cannot match it to the dictionary, causing reverse-compilation to fail and blocking the write. • API Cost Overhead: Processing obfuscated IR requires deeper reasoning steps and more tokens. • Lack of Quantitative Audits: As an independent project, enterprise-grade security audits to quantify the exact "leakage reduction rate" have not yet been performed. I built this from scratch by vibe-coding alongside AI agents. I’d love to hear your thoughts on this approach to semantic leakage and AST obfuscation.
Remember, two enters

to get a new paragraph.

Thanks for the heads-up! Since I'm new here, I didn't realize the formatting rules and ended up missing the 2-hour edit window. I've replied to my original comment with the properly formatted version. I appreciate the help!

I’m a student developer building Verantyx, a native macOS IDE solving a core dilemma in AI coding: We need the reasoning power of frontier models like Claude 4.7 Opus, but cannot legally or ethically leak proprietary source code, hardcoded secrets, or core business logic to their APIs.

With the industry worried about losing "tacit knowledge" to AI, I built an architecture where the human retains ultimate control over semantics, while the AI is relegated strictly to structural logic patching.

To achieve this, I built the "Gatekeeper" architecture. Before code leaves your local Apple Silicon machine, a Rust core parses the AST and converts it into "JCross IR"—a custom intermediate topology. It deterministically masks high-value identifiers (e.g., calculateTax() becomes [Symbol_A]()) while preserving structural logic and control flow.

The Cloud LLM receives this obfuscated puzzle, writes a patch, and returns it. The local Rust vault then maps the IR patch back to your original source code.

The Tech Stack & Architecture

- Core (Rust): Handles the zero-copy memory vault, deterministic JCross IR generation, and AST parsing. The mapping dictionary is held strictly in local memory and never leaves the machine.

- Frontend (Swift): Native macOS UI. Achieves 0-latency state sync (a 1-frame toggle response) between "Raw Code View" and "AI's JCross IR View" without heavy disk I/O.

- The VS Code Bridge: To support LSPs without Electron's memory bloat, I built a background Node.js Extension Host communicating via JSON-RPC. Managing state synchronization between the Swift UI, the Rust Vault, and the Node.js host to prevent race conditions during reverse-compilation was an absolute nightmare.

The Gatekeeper Flow

1. Request: User prompts the Swift UI for a refactor.

2. Obfuscation: Rust converts the file to JCross IR, locking the mapping dictionary in local memory.

3. Transmission: Swift sends only the JCross IR to the Cloud LLM.

4. Reasoning: The LLM processes the obfuscated topology and returns an IR patch.

5. Restoration: Rust uses the local dictionary to reverse-compile the IR patch back into raw code.

6. Approval: Swift presents a Diff UI to the user for final approval.

Honest Trade-offs & Limitations

- Semantic Loss Penalty: Blinding the AI to domain-specific context (e.g., it doesn't know [Symbol_A] means "DB Connection String") occasionally leads to syntactically correct but logically flawed code.

- AST Topology Destruction: This is the most critical issue. When given complex instructions, frontier models sometimes hallucinate and destroy the AST topology of the obfuscated IR. When the structure is broken, the Rust vault cannot match it to the dictionary, causing reverse-compilation to fail and blocking the write.

- API Cost Overhead: Processing obfuscated IR requires deeper reasoning steps and more tokens.

- Lack of Quantitative Audits: As an independent project, enterprise-grade security audits to quantify the exact "leakage reduction rate" have not yet been performed.

I built this from scratch by vibe-coding alongside AI agents. I’d love to hear your thoughts on this approach to semantic leakage and AST obfuscation.

> e.g., calculateTax() becomes [Symbol_A]()

I expect AI to guess it. For example here in Argentina the equivalent of the VAT is 21%, so I expect that if the AI see round(x*1.21, 2) will be enough (I'm not sure it's the correct rounding, this is not accounting advice :) .)

Thank you for your feedback. I have reconsidered the structure and revised it as follows. Please take a look.

## The Heart of Gatekeeper: "6-Axis Three-Dimensional Cross Structure (JCross 6-Axis IR)"

Gatekeeper is the "absolute gatekeeper" standing between the user's local environment and the external cloud LLM. Its core technology is the metamodel *"JCross IR (Intermediate Representation)"*, which reinterprets source code not merely as "text," but as a "spatial structure."

JCross IR decomposes source code into the following six dimensions (axes):

| Axis | Name | Role/Content | | :--- | :--- | :--- | | *X-axis* | *Control Flow* | Axis of time and sequence. if branches, loops, exceptions, etc. | | *Y-axis* | *Data Flow* | Axis of dependency and propagation. Variable assignment, argument passing, etc. | | *Z-axis* | *Type Constraints* | Boundary axis. Classes, type definitions, generics, etc. | | *W-axis* | *Memory & Lifecycle* | Lifespan axis. Scope lifespan, memory allocation/deallocation, etc. | | *V-axis* | *Scope & Hierarchy* | Inclusion axis. Modules, class nesting, etc. | | *U-axis* | *Semantics & Meaning* | * Most Important* Intent and concrete value axis. Specific variable names, function names, strings, etc. |

### Absolute Security through Physical Extraction of the "U-axis"

Simply encrypting variables uniformly prevents LLM from correctly interpreting even the logical structure of the code (loop scope and variable scope).

Therefore, Gatekeeper uses a rule-based parser to analyze the AST (Abstract Syntax Tree) and physically extracts only the "U-axis (semantics)" from this six-axis cross, isolating (masking) it in a local vault (JCrossIRVault). Only the "pure logic and structural framework" consisting of the remaining five axes (X, Y, Z, W, V) is sent to the external cloud LLM.

### Actual Transformation Image (Before / After)

Let's look at how the code is specifically hidden.

*[Before] Raw Source Code (as it is on the user's machine)* ```swift func calculateTax(price: Double) -> Double { let taxRate = 1.21 return round(price * taxRate, 2) }

[After] Masked JCross IR (as it is sent to Cloud LLM) When sent to LLM, business logic and sensitive information (U axis) are replaced with unique hash tokens, but the *topology (X/Y/Z/V/W axes)* where "function arguments are multiplied and returned as a value" is completely maintained.

func FUNC_0xA1B2(VAR_0x3C4: TYPE_DOUBLE) -> TYPE_DOUBLE { let VAR_0x9D5 = CONST_0xF1 return CALL_0xE5A(VAR_0x3C4 * VAR_0x9D5, CONST_0x02) } LLM looks at this symbolized structure puzzle, understands it at the structure level, and returns a patch. Finally, Verantyx restores the original complete code by reinjecting the U axis from the local Vault. Overall Flow: From Rule-Based Analysis to Inverse Transform This "extract" to "restore" pipeline is executed by robust rule-based processing, which does not tolerate inference errors. graph TD A[Raw Source Code] -->|1. AST Analysis| B[Rule-Based 6-Axis Parser] B -->|2. 6-Axis Decomposition| C{Gatekeeper Engine}

C -->|3. U-Axis Isolation| D[(Local Vault<br>JCrossIR Vault)] C -->|4. Extraction of Remaining 5 Axis| E[Masked IR<br>FUNC_0x...]

E -->|5. Submission| F((Cloud LLM<br>Claude / GPT-4))

F -->|6. Structural Inference| G[GraphPatch JSON<br>Structural Patch] G -->|7. Patch Application| H{Reverse Transpilation Engine<br>Reverse Transpilation}

D -->|8. U-Axis Reinjection| H H -->|9. Restoration Complete| I[Modified Source Code]