Aether-9 v3.0 A Policy-Aware Secure Bytecode Execution Layer for AI-Native and Automation Workflows

Ahmed Harb Akeely Independent Researcher and Builder

Version 1.0 - April 2026

Abstract

Modern automation systems and AI agents increasingly execute tools, write files, call APIs, and transform

data without a dedicated execution layer that can verify integrity and enforce policy before actions complete.

Aether-9 v3.0 is a source-available secure execution language and runtime designed to address this gap. It

combines a small domain-specific language, structural execution gates, cryptographic integrity verification,

controlled I/O, policy constraints, and a direct bytecode VM path. The system is not positioned as a

general-purpose replacement for Python, Rust, or JavaScript. Instead, it targets high-risk workflows where

execution should be constrained, auditable, and rejectable before harm occurs. Version 3.0 introduces a

bytecode interpreter and disassembler, allowing Aether-9 programs to be inspected and executed through

a VM-oriented path rather than relying only on source-to-Python transpilation. This paper describes the

threat model, architecture, execution model, security boundaries, evaluation status, and practical use cases

for Aether-9 as a secure execution substrate for AI agents, automation pipelines, and policy-controlled

runtime environments.

Keywords: secure execution, bytecode VM, policy control, AI agent security, integrity verification, sandboxed

runtime, pre-execution control

1. Introduction

AI-native systems are moving from passive text generation toward active execution: they call tools, modify

files, run workflows, invoke APIs, and produce operational side effects. In such environments, the core

security problem is no longer only whether an action can be detected after it happens. The higher-value

question is whether execution should be admitted at all.

Aether-9 approaches this problem at the execution layer. It is designed to enforce integrity and policy

before and during runtime execution. Rather than treating security as an external scanner, Aether-9 embeds

execution constraints into the language/runtime boundary itself.

The project began as a physics-constrained and deterministic execution architecture, then evolved into a

working language toolchain with compiler, verifier, policy layer, sandboxing, tests, and a v3.0 bytecode VM

path.

The intended role of Aether-9 is narrow but important: a secure execution substrate for untrusted,

sensitive, or AI-mediated actions.

1. Problem Statement

General-purpose languages optimize for expressiveness and developer productivity. Security controls are

usually added externally through permissions, containers, endpoint detection, static analysis, or runtime

monitoring. These layers are useful, but they do not always provide a simple execution contract: this action

1

is allowed, this output path is permitted, this source matches the approved artifact, and this instruction

stream can be inspected before it runs.

This gap becomes more important in AI-agent workflows, where the caller may be non-human, the instruction

chain may be dynamic, and the impact of file writes or tool calls may be immediate. Aether-9 is designed

for environments where the runtime itself must be conservative.

1. Design Goals

Goal Meaning in Aether-9 v3.0

Pre-execution control Execution should be admitted only after structural

and policy checks pass.

Integrity binding Source and execution artifacts should be tied to

verifiable cryptographic state.

Controlled I/O Writes and sensitive operations should be explicit

and policy-governed.

Auditability Bytecode disassembly should make execution intent

inspectable.

Small trusted surface The core runtime should remain compact enough to

reason about and test.

Practical use The system should be installable and testable by

external developers without private setup.

1. System Overview

Aether-9 v3.0 consists of a language frontend, parser and AST representation, bytecode compiler, verifier,

policy layer, and VM executor. The runtime path is designed so that the program can be inspected as

bytecode before execution and then interpreted under a controlled instruction model.

Aether-9 source (.a9)

-> Parser + AST + semantic checks

-> Bytecode compiler (.a9b)

-> Verifier: HMAC + policy

-> VM executor: controlled I/O

Execution is admitted only after integrity, policy, and bytecode-level checks pass.

The v3.0 command surface includes two important capabilities: aether disasm, which exposes bytecode

instructions, and aether vm, which executes the program through the VM path.

Example operational flow:

aether disasm program.a9

aether vm program.a9

1. Execution Model

Aether-9 source programs are compiled into an intermediate bytecode representation. The VM interprets

this instruction stream directly. Representative instructions include loading constants, loading variables,

registering lattice functions, beginning iteration, calling functions, performing controlled writes, and halting

execution.

2

Instruction Purpose

LOAD_CONST Push a constant or literal value onto the VM stack.

LOAD_NAME Resolve a local or global name while preserving

valid falsey values such as 0.

MAKE_FUNC Register a lattice/function object for later

invocation.

FOR_START Begin controlled iteration over a collection.

CALL_FUNC Invoke a function through the VM call protocol.

WRITE Perform a controlled write operation under policy

restrictions.

HALT End execution.

A key implementation lesson in v3.0 was the treatment of falsey values. For example, a variable value

of 0 must be treated as a valid resolved value rather than as an unresolved name. This kind of issue is

typical in VM implementation and demonstrates the need for explicit sentinel-based lookup rather than

truthiness-based fallback.

1. Security Model

Aether-9 v3.0 should be understood as a defensive execution layer, not as a claim of absolute security. Its

security value comes from combining multiple conservative mechanisms at the execution boundary.

Mechanism Security contribution

HMAC-SHA256 integrity Binds approved source/artifact state to

cryptographic verification instead of informal trust.

AST Guard Limits unsafe constructs before execution reaches

the VM path.

Policy Layer Controls sensitive operations such as writes and

denies operations outside declared policy.

Write Whitelist Prevents arbitrary filesystem writes by requiring

allowed destinations.

Bytecode disassembly Allows inspection of the instruction stream before

execution.

VM interpretation Reduces reliance on direct exec-style execution

paths.

The security model is intentionally layered. A policy failure, integrity mismatch, disallowed write, or unsafe

syntax should stop execution before the action produces an external effect.

1. Threat Model

Aether-9 is designed for constrained execution scenarios. The following threat model summarizes the current

intended scope.

Threat Desired behavior

Tampered source or artifact Reject execution if integrity no longer matches the

approved state.

Unauthorized file write Deny unless the path is permitted by policy.

3

Threat Desired behavior

Unsafe generated script Block or reject constructs outside the allowed

execution model.

AI tool misuse Force tool-like actions into a policy-controlled

runtime path.

Opaque execution Expose bytecode instructions for inspection before

execution.

Out of scope for the present paper are formal proofs of complete isolation, kernel-level sandboxing, nativecode

hardening, side-channel resistance, and protection against a malicious host operating system. These

are future audit and engineering concerns.

1. Evaluation Status

The current project reports 103 passing tests for the v3.0.0 codebase and a set of smoke tests covering core

language and VM behavior. The test set includes examples for basic lattice execution, conditionals, loops,

nested calls, standard-library functions, and controlled writes.

Test class Example behavior

Basic lattice call Compile and execute a lattice function with bound

data.

If / else Branch correctly under VM execution.

For loop Accumulate values without losing falsey state such

as acc = 0.

While loop Run bounded iterative logic.

Nested calls Call one lattice function from another.

Standard library Use helper functions such as digital-root style

reduction and concatenation.

Controlled write Write output only through the controlled I/O path.

The test results should be treated as internal project validation rather than as independent third-party

certification. Future work should include reproducible benchmark scripts, external audit, adversarial testing,

and comparison against existing sandbox and policy systems.

1. Positioning Against Existing Technologies

Technology Primary strength How Aether-9 differs

Python / JavaScript General productivity and

ecosystem

Aether-9 intentionally restricts

execution and emphasizes policy.

Rust Memory safety and systems

programming

Aether-9 targets runtime

admission control, not general

systems replacement.

WASM Portable sandboxed bytecode Aether-9 adds language-level

policy and integrity goals around

the execution path.

OPA / Rego Policy-as-code decisions Aether-9 combines policy with an

execution runtime rather than

only external decisions.

4

Technology Primary strength How Aether-9 differs

Containers Process-level isolation Aether-9 operates at

language/bytecode semantics and

controlled I/O level.

Aether-9 should not compete with mainstream languages on ecosystem size. Its practical path is to become

a small, auditable execution layer for workflows where uncontrolled execution is unacceptable.

1. Practical Use Cases

AI agent tool execution. Aether-9 can serve as a constrained layer for file writes, structured transformations,

and policy-bound tool calls generated by AI agents.

Automation pipelines. Sensitive scripts can be expressed or wrapped in an execution model where writes

and operations are explicitly governed.

Security demonstrations and research. The language provides a compact environment for experimenting

with pre-execution policy enforcement, integrity verification, and inspectable bytecode.

Education. Aether-9 can be used to teach the difference between language syntax, bytecode, VM interpretation,

and policy enforcement.

1. Limitations

Aether-9 v3.0 is still an early-stage secure execution language/runtime. It is not yet a general-purpose

language, a formal verification platform, a complete operating-system sandbox, or a substitute for mature

security infrastructure. It requires external audit, expanded documentation, broader test coverage, and

clearer reproducibility before production claims should be made.

The strongest current claim is not absolute security. The strongest defensible claim is that

Aether-9 v3.0 implements a working policy-aware bytecode execution path with integrity checks,

controlled I/O, and test-backed runtime behavior.

1. Release Summary: v3.0.0

Version Security/runtime milestone

v2.7 Cryptographic integrity using HMAC-SHA256.

v2.8 Execution isolation and AST Guard.

v2.9 Policy layer, write whitelist, and hardening.

v3.0 Bytecode VM path and disassembler.

1. Conclusion

Aether-9 v3.0 represents a transition from a secure-language concept into a working secure execution layer.

Its main contribution is the combination of language-level constraints, cryptographic integrity, policy control,

controlled I/O, bytecode inspection, and VM execution in a compact system. The project is best understood

as an early but serious attempt to move security closer to the execution boundary, especially for AI-native

and automation workflows where pre-execution control matters.

5

Appendix A: Minimal Example

data = [54, 36, 72]

lattice verify(x) uses data:

return (x * 9) % 9 or 9

print(verify(54))

Expected workflow:

aether disasm example.a9

aether vm example.a9

Appendix B: Responsible Release Note

This paper intentionally avoids claiming total security, universal correctness, or complete protection against

all adversaries. Aether-9 is a source-available project intended for evaluation, research review, testing, feedback,

and non-commercial experimentation unless a separate written license is granted. Production, commercial,

enterprise, or revenue-generating use should be governed by a separate license agreement with the

author.

Copyright (c) 2026 Ahmed Harb Akeely. All rights reserved unless otherwise licensed in writing.