This document details the security architecture of Autolang — explaining how the runtime constrains AI-generated scripts through language-level sandboxing, explicit capability boundaries, default-deny rules, and bounded resource limits.

Threat Model

Autolang treats every AI-generated script as untrusted input. The runtime assumes scripts may contain invalid logic, hallucinated APIs, infinite loops, excessive allocations, or unauthorized operations. All security mechanisms are designed around this assumption.

Non-Deterministic Output

LLMs may emit incorrect logic, invalid types, or non-existent function identifiers under varying prompt contexts.

API & System Hallucination

Models often invent standard library functions, database drivers, dynamic imports, or direct socket access syntax.

CPU Resource Monopolization

Generated code may contain infinite loops (e.g. while(true)) or exponential computations that freeze single-threaded workers.

Heap Allocation Exhaustion

Scripts may attempt to allocate unbounded arrays or deeply nested structures that exhaust available process memory.

End-to-End Security Flow

Autolang does not rely on a single isolation mechanism. Instead, it enforces multi-layered checks from static compilation to dynamic VM execution and native capability dispatch:

AI Orchestration Script
         │
         ▼
Compile-Time Validation  (Imports, Static Types, Symbol Resolution)
         │
         ▼
Runtime VM Controls      (Opcode Instruction Budget, Heap Memory Quota, Stack Depth)
         │
         ▼
Capability Boundary      (Type-checked native binding bridge)
         │
         ▼
Host Application         (Authority, Credentials & Enterprise Business Logic)

Trust Boundaries & Ownership

Security in Autolang relies on strict division of responsibility across trust boundaries. The LLM and script reside in the untrusted domain, while the VM, native bindings, and host application form the trusted enforcement domain:

[ Untrusted Domain ]
LLM Model  ──generates──▶  Autolang Source Script
                                 │
                                 ▼
[ Trusted Enforcement Domain ]
Autolang VM  ──checks & dispatches──▶  Capability Boundary
                                            │
                                            ▼
[ Trusted Host Domain ]
Host Application  ──executes──▶  Business Systems

Defense in Depth Layers

Autolang security consists of five coordinated defense layers working in sequence:

Layer 1 — Static Compile ValidationSyntax, types, @import verification

Layer 2 — VM Runtime EnforcementInstruction budget & heap quota

Layer 3 — Capability BoundaryDefault-deny native bindings

Layer 4 — Host Parameter ValidationCallback parameter sanitation

Layer 5 — Isolated Business InfrastructureDatabase & API credential safety

Default-Deny Architecture

The Autolang runtime enforces absolute default-deny semantics. Nothing is reachable from an execution script unless it was explicitly declared and registered by the host application.

No Unregistered Modules

Scripts cannot @import any library or package that was not registered by the host application via compiler.registerBuiltInLibrary().

No Reflection or Dynamic Eval

Autolang lacks dynamic code evaluation (eval), reflection APIs, or runtime object inspection capabilities that could bypass type checks.

No Unexposed Network or Filesystem

Raw sockets, file I/O operations, and environment variables do not exist in the script execution context unless explicitly bound by host rules.

No Subprocess Execution

The runtime cannot fork processes, spawn shell commands, or access operating system primitives.

Capability Security vs. Global Permissions

AI scripts do not receive broad system permissions; they receive explicit capabilities.

What is a Capability?

A capability is a host-defined operation that the VM is allowed to invoke. Examples include crm.getCustomers(), mail.sendEmail(), or reporting.generateReport(). Scripts cannot call anything outside these registered capabilities.

// Allowed — explicit registered capability
val customers = crm.getCustomers("enterprise")

// Compilation Error — raw database drivers are unavailable in VM context
val db = Database.connect("postgres://...") // Symbol not found

Resource Governance

Security requires preventing resource exhaustion. Autolang enforces resource bounds across independent control layers:

Instruction Budget

Limits total opcodes executed per run (default 100,000 opcodes). If reached, VM terminates execution instantly, preventing CPU monopolization.

Managed Memory Quota

Limits allocations of VM-managed objects (AObject). Host-owned data structures remain accounted for by the host runtime.

Compile-Time vs. Runtime Security

Security checks are split cleanly between static pre-run analysis and dynamic in-flight execution:

Compile-Time Security (Static)	Runtime Security (Dynamic)
Syntax analysis & Lexing	Opcode instruction budget counting
Static type check & null safety	Heap memory quota tracking
Unregistered @import rejection	Stack depth & frame validation
Unresolved symbol verification	Type-safe native binding dispatch

Explicit Scope Limitations

Autolang provides language-level sandboxing. It does not replace OS isolation or host application security responsibility. Autolang does not protect against:

Host-Side Security Responsibilities

•Insecure native bindings (e.g. exposing unvalidated SQL string concatenation inside host functions).
•Bugs, memory leaks, or vulnerabilities inside the host application code itself.
•Leaked host API keys or database connection credentials stored in host memory.
•Operating system kernel vulnerabilities or host process compromise.

Technology Comparison & Positioning

Autolang complements OS and hypervisor sandboxes by providing language-level capability governance:

Metric	Autolang	Docker	Firecracker	V8 Isolates	QuickJS
Designed For	AI Orchestration	App Deployment	Strong VM Isolation	Multi-tenant JS	Embedded JS
Isolation Layer	Language VM	OS (cgroups)	Hardware (KVM)	JS Heap Isolate	JS Interpreter
Capability Model	Built-in Default Deny	Host Mounts	Virtio Devices	V8 Binding Context	C Binding API
Resource Governance	Opcode & Heap Quota	Container Limits	vCPU & Mem Alloc	Isolate Heap Cap	Custom Interrupt
OS / Kernel Boundary	No	Shared Kernel	Dedicated Guest Kernel	No	No

Core Security Principles

AI Code is Untrusted

The runtime never relies on the language model behaving correctly.

Default Deny

No capabilities exist in the VM context unless explicitly registered.

Least Authority

Scripts receive granular capabilities rather than general system access.

Bounded Execution

Opcode budgets and memory quotas prevent CPU monopolization.

Security Checklist for Host Integration

[✓]Register only strictly required capability libraries per script session.
[✓]Keep business logic and credentials entirely within host code.
[✓]Never expose raw database connection objects or SQL drivers to scripts.
[✓]Configure reasonable opcode instruction budgets (e.g. 50,000 – 100,000 opcodes).
[✓]Validate all parameter inputs inside native host binding callbacks.
[✓]Treat native binding declarations as your primary security boundary.

Security Model