AI Proposes, the Compiler Disposes: Inside LOOM’s Machine-Checked Trust Layer for Generative Code

As artificial intelligence systems increasingly transition from simple text generators to autonomous software engineers, the global tech industry faces an unprecedented crisis of trust. Today, LLMs (Large Language Models) write a significant and rapidly expanding share of the world’s production code. However, this shift has exposed a critical systemic vulnerability: the same AI model frequently generates both the functional code and the unit tests designed to validate it.

When a single intelligence authors both the solution and the evaluation criteria, the assertion that "the tests passed" ceases to guarantee safety. Instead, it creates a self-referential loop of circular trust—a vulnerability that cannot be solved simply by building larger, more computationally expensive models. A larger model that grades its own homework remains a model grading its own homework.

To address this challenge, a new, open-source programming language called LOOM has emerged. Developed by a solo engineer operating out of Ukraine, LOOM is an effect-typed language designed to act as a machine-checked trust layer for AI-written code. Rather than relying on the hope that an AI model has behaved honestly, LOOM uses formal, mathematical verification at the compiler level to prove exactly what a piece of code is permitted to do before a single line is executed.

Main Facts: What is LOOM?

LOOM is a lightweight, open-source programming language designed to secure the pipeline between AI code generation and deployment. Licensed under the MIT license, LOOM operates on a fundamental security principle: "AI proposes, the compiler disposes." It does not attempt to prevent AI from writing bad or buggy code; instead, it prevents untrusted or dishonest code from executing.

+-------------------------------------------------------------+
|                      AI Code Proposal                       |
+-------------------------------------------------------------+
                               |
                               v
+-------------------------------------------------------------+
|                      LOOM Compiler                          |
|  - Validates declared effects (Pure, IO, Net, Alloc, etc.)  |
|  - Enforces provenance requirements (trust N e)             |
|  - Verifies linear/affine resource constraints              |
+-------------------------------------------------------------+
                               |
            +------------------+------------------+
            |                                     |
    [Passes Verification]                 [Fails Verification]
            |                                     |
            v                                     v
+---------------------------------+       +-------------------+
|      Safe Cross-Platform        |       | Execution Blocked |
|          Execution              |       | (Compiler Refusal)|
| (Interpreter, Wasm, JS, Python) |       +-------------------+
+---------------------------------+

At its core, LOOM introduces several security and architectural innovations:

Effect Honesty: Every function must explicitly declare its side effects (such as network access, file I/O, memory allocation, or foreign function interfaces). The compiler transitively tracks these effects across call stacks, branches, and recursion, blocking execution if a function attempts an undeclared action.
No Ambient Authority: External and foreign calls do not possess default privileges. Access to system resources must be explicitly granted through defined interfaces ("seams").
Provenance and Trust Gates: Every value within the runtime carries metadata tracking its origin. The language enforces rules that require independent, human-verified anchors to validate data generated by an AI.
Universal Compilation: A single verified LOOM program can compile to Python, JavaScript, and WebAssembly, or run directly via its native interpreter, maintaining identical safety guarantees across all execution environments.

Currently, LOOM exists as an alpha research kernel. The project maintains a suite of 385 self-verifying checks, all of which are validated through adversarial testing. To encourage public analysis and experimentation, the creator has launched a live browser-based playground where developers can write, compile, and test LOOM programs in real time.

Chronology: From Ukrainian Sandbox to Autonomous Evolution

The development of LOOM follows an unconventional path, shaped by geopolitical pressures and automated engineering systems:

Phase 1: Identifying the AI Trust Gap (Early 2024)

As autonomous coding agents began gaining widespread adoption in enterprise workflows, security researchers observed an uptick in "hallucinated" dependencies, accidental security vulnerabilities, and logic flaws that bypassed traditional CI/CD pipelines. The developer, operating under the pseudonym umbraaeternaa in Ukraine, began designing a language that assumed all input code was hostile or untrusted by default.

Phase 2: Establishing the Core Kernel (Mid 2024)

Working in isolation amid the ongoing war in Ukraine, the developer built the core compiler, interpreter, and multi-backend code generators. Instead of relying solely on manual engineering, the project implemented a self-testing suite. Every new language feature required an accompanying "adversarial test"—a test designed to break or trick the compiler. If the compiler could be deceived, the feature was rejected.

Phase 3: The "Autonomous Organism" and Public Launch (Late 2024)

To accelerate development, the creator built a private, autonomous system to manage the codebase. This system runs continuously on a single machine, generating code modifications, verifying them against the test suite, and launching automated adversarial attacks against its own proposals.

Only after a change passes this automated pipeline is it presented to the human developer for final review and integration. This method has allowed the project to scale its test coverage to 385 fully verified green checks. In late 2024, the source code was officially published on GitHub under the MIT license, alongside a live web playground.

Supporting Data: Technical Architecture and Deep-Dive

LOOM’s security model relies on a combination of programming language theory concepts, synthesized into a unified security toolchain.

1. The Effect-Typed System

Unlike traditional programming languages that only verify data types (e.g., ensuring a variable is an integer or a string), LOOM’s compiler tracks effects. Functions must be annotated with the specific real-world actions they perform:

LOOM: a language that proves what AI-written code is allowed to do

Effect	Description	Security Risk Addressed
`Pure`	No side effects; deterministic execution.	Code injection, state corruption.
`IO`	Basic input/output operations.	Unauthorized file access or system modification.
`Net`	Network transmission and reception.	Data exfiltration, command-and-control communication.
`Alloc`	Memory allocation.	Denial-of-service via memory exhaustion.
`FFI`	Foreign Function Interface (native code execution).	Arbitrary code execution outside the runtime.
`Rand`	Random number generation.	Predictable cryptography, entropy exhaustion.

If an AI-generated function claims to be Pure but attempts to make a network request (either directly or by calling another function that eventually accesses the network), the LOOM compiler identifies the mismatch during static analysis and rejects the program.

2. Capability-Based Security and Seams

In standard environments, a program inherits the "ambient authority" of the user running it. If a Python script is run by an administrator, any package imported by that script can access the entire file system.

LOOM eliminates ambient authority. Foreign function calls are blocked unless they are wrapped in an explicit "seam." For example, the expression:

$$text(seam (Pure) (ffi untrusted_library))$$

strips the foreign library of all system access, making physical I/O mathematically impossible during its execution.

3. Provenance and the Trust Gate

To prevent circular reasoning in automated software development, LOOM introduces a provenance tracking system. Every variable and data structure is tagged with its author (e.g., AI_Model_Claude, Human_Developer, or CI_System).

Using the construct:

$$text(trust N e)$$

the language enforces that a value $e$ cannot be trusted unless it is backed by $N$ independent, non-AI authority anchors. This acts as a circuit breaker against autonomous systems approving their own code changes without human intervention.

Furthermore, LOOM supports role quorums, requiring that the code generator, the specification writer, and the proof verifier be distinct entities before a program is cleared for execution.

       [AI Code Generator] ------> Generates Code (Tagged: AI)
                                        |
                                        v
[Human Spec Writer] (Anchor 1) ---> [LOOM Trust Gate] <--- [CI Verifier] (Anchor 2)
                                        |
                             (Requires N=2 Anchors)
                                        |
                                        v
                             [Execution Approved]

4. Accountable Gates

When LOOM approves or denies a program, it does not output a simple binary decision. The compiler generates an accountable gate verdict, which includes:

A manifest of all declared and inferred effects.
Cryptographic, single-use signatures that prevent authorization replay attacks.
A read-only Git observer record to preserve audit trails.
A structured receipt detailing the evidence used during verification.

Official Responses and Industry Context

The release of LOOM has drawn attention from software security researchers, compiler engineers, and advocates for AI safety.

Developer Perspective

The creator of LOOM, posting under the handle umbraaeternaa, emphasized that the language’s strength lies in its synthesis of existing academic concepts rather than the invention of new ones:

"The individual ideas—effect rows, capabilities, provenance—aren’t new; the synthesis is: one legible signature channel, checked at a trusted gate, as a trust layer for AI-generated code… AI proposes, the compiler disposes."

Regarding the development process in Ukraine, the developer noted that the language’s resilience is tested by its own automated generation engine:

"An autonomous organism I built grows it—day and night, on a single machine… It proposes a change, proves it green itself, adversarially attacks its own proposal, and only then a human decides. It self-heals."

Security Industry Context

Security analysts note that LOOM addresses a major blind spot in current AI deployment pipelines. While tools like static application security testing (SAST) and runtime application self-protection (RASP) attempt to find vulnerabilities after code is written, they rely on heuristics and pattern matching, which are prone to false negatives. LOOM’s approach uses formal proof, meaning that if a program compiles, its safety guarantees are mathematically verified.

However, some language designers point out that effect systems have historically struggled with mainstream adoption due to their complexity. Languages like Koka and Frank have demonstrated the power of algebraic effects in academic settings, but integrating these paradigms into industrial software pipelines remains a challenge. LOOM’s focus on serving as an intermediate target language for AI-generated code, rather than a general-purpose language for human developers, may help it bypass these adoption barriers.

Implications: The Future of Verified Software

The rise of LOOM highlights a broader shift in how software security must evolve in the era of generative AI. When code generation costs drop to near zero, the bottleneck in software engineering shifts from writing code to verifying code.

+-----------------------------------------------------------------------------+
|                               Traditional Paradigm                          |
|  - Bottleneck: Code Generation (Humans writing code slowly)                 |
|  - Security: Heuristic-based testing, code reviews, and manual QA           |
+-----------------------------------------------------------------------------+
                                       |
                                       v
+-----------------------------------------------------------------------------+
|                                 AI-Agent Paradigm                           |
|  - Bottleneck: Verification (AI writing code at massive scale)              |
|  - Security: Formal proofs, effect typing, and machine-checked trust layers |
+-----------------------------------------------------------------------------+

1. Mitigating Supply Chain Attacks

Modern software relies heavily on open-source packages (e.g., npm, PyPI). AI agents tasked with writing code frequently pull in these third-party dependencies, occasionally introducing malicious packages through "dependency confusion" or hallucinated package names. By enforcing strict effect typing and stripping ambient authority, LOOM ensures that even if an AI agent pulls in a malicious library, that library cannot access the host system’s network or disk without triggering a compiler error.

2. Sandboxing Autonomous Agents

As AI agents transition from generating static code snippets to running loops where they write, test, and execute code dynamically, they require safe sandboxes. LOOM provides a lightweight runtime where agents can execute code with mathematically defined boundaries. If an agent attempts to escalate its privileges, the runtime halts execution instantly, preventing rogue loops or accidental damage to production systems.

3. The Coexistence of Open and Private Tooling

The development model of LOOM presents an interesting hybrid approach to open-source software. While the language specification, compiler, and target backends are fully open-source under the MIT license, the automated engine that generates and tests the language remains private. This model allows the public to inspect, verify, and trust the output, while the creator retains the proprietary engine used to evolve the system.

Next Steps for the Project

LOOM remains in an early alpha phase. The developer’s stated roadmap includes:

Expanding low-level and cross-platform compilation targets.
Strengthening the external auditing engine, allowing LOOM to analyze external, non-LOOM AI agent code and model its potential weaknesses.
Fostering adoption among enterprises that utilize autonomous AI coding pipelines.

By shifting the definition of "trust" from human review to mathematical verification, LOOM offers a potential path forward for a software industry increasingly reliant on machine-generated code.