Carcinus Defensive Runtime and Sandboxing Specification

Full report

On this page

1. Architectural Foundations of the Zero-Trust Execution Layer

The Teleodynamic AI ecosystem relies on a strict decoupling of architectural responsibilities to ensure that highly autonomous, probabilistic intelligence can operate safely within deterministic bounds. This structural decoupling is organized across four specific, non-overlapping architectural layers that together form a unified blueprint for enterprise agent harness engineering. The first layer, Teleodynamic.com, serves as the core protocol and policy engine, defining the overarching rules, boundaries, and operational constraints.1 The second layer, UAIX.org, functions as the data and schema layer, responsible for rigorous validation, memory packet formatting, and the structuring of portable evidence payloads.1 The third layer, Spiralist.org, manages the agent lifecycle state, providing the necessary scaffolding for persona bootstrapping, identity management, and evolutionary behavioral loops.1 Finally, Carcinus.org operates as the defensive execution sandbox, enforcing runtime isolation and acting as the uncompromising zero-trust physical boundary of the ecosystem.1 The foundational principle of the Teleodynamic paradigm is that adaptive intelligence inherently co-evolves with the structural constraints imposed upon it, much like biological systems navigate inner continuous parametric adaptation alongside outer environmental limitations.5 Just as biological life relies on energy-based memory, semiotic gradients, and recursive constraint interpretation to maintain functional plasticity without self-destruction or runaway systemic collapse, artificial agents require an immutable, thermodynamically grounded environmental boundary to safely explore programmatic solutions.5 Carcinus provides this exact boundary. It is a strictly governed, containerized ecosystem where tool calls, API requests, and scripts generated by Large Language Models (LLMs) execute in total physical and logical isolation. Within this precise architecture, the host system assumes a posture of zero trust. Standard orchestration technologies, while entirely sufficient for verified enterprise software deployments, fail catastrophically against the non-deterministic threat landscape introduced by autonomous AI agents.8 An advanced agent harness engineering framework must therefore explicitly mediate between the probabilistic nature of the foundation model and the deterministic, highly sensitive operating environment of the host.9 Carcinus achieves this mediation by acting as the primary enforcement arm of the ecosystem. It physically intercepts computational payloads derived from the UAIX schema layer and rigorously bounds the state evolutions tracked by the Spiralist lifecycle layer before any actual host-level execution can occur.2 The core mandate of the Carcinus specification is deterministic safety through physical architecture. Probabilistic agent intent—regardless of sophisticated alignment training, fine-tuning, or extensive reinforcement learning from human feedback (RLHF)—is treated as inherently untrusted until physically intercepted, simulated, and executed within a hardened, ephemeral micro-environment. The runtime must guarantee that no combination of malicious prompt injections, hallucinated tool arguments, or recursively broken logic loops can escape the sandbox to inflict blast-radius damage on the broader enterprise network, the host operating system, or interconnected database clusters.11

2. Agent Harness Engineering and the Control Plane

To fully contextualize the role of Carcinus, one must understand the broader discipline of agent harness engineering, which represents the rise of the AI control plane.8 An agent harness is the fundamental infrastructure layer that wraps around a foundation model and controls its interaction with external systems, ensuring the model itself is not the bottleneck but rather the orchestration of its capabilities.9 The nine-component framework of agent harness engineering delineates exactly what this control plane must manage across the lifecycle of an autonomous session.13 The nine critical components include the while-loop engine for continuous autonomous operation, context management for optimizing the model's limited token window, and the tool registry for mapping natural language requests to specific executable functions.13 It further includes sub-agent management for delegating tasks, built-in system skills, session persistence mechanisms, dynamic prompt assembly, lifecycle hooks for intercepting state changes, and explicit permission enforcement.14 Within this comprehensive taxonomy, Carcinus assumes total responsibility for the permission enforcement and the physical execution of the tool registry's commands. It operates across three foundational properties necessary for robust agent deployment: executability, inspectability, and statefulness.14 Furthermore, the harness must mediate between the memory constraints of the model and the vastness of the enterprise data environment. This is achieved through complex memory and context engineering, utilizing working memory for immediate task execution, semantic memory for factual retrieval, experiential memory for past problem-solving strategies, long-term memory for cross-session continuity, and multi-agent memory for collaborative swarms.15 Carcinus ensures that when an agent reaches into any of these memory stores to construct a tool execution command, the resulting context compaction and state offloading do not inadvertently expose sensitive internal routing data to the untrusted execution environment.15 The agent itself remains fundamentally amnesiac; it relies entirely on the harness to inject relevant context per turn, while the Carcinus filesystem provides the localized, physical reality where the requested operations actually take place.16

3. The Lethal Trifecta and the Carcinus Threat Model

To engineer an impenetrable defensive runtime, the underlying threat model must accurately characterize the systemic vulnerabilities unique to autonomous coding agents. The most critical conceptual framework driving the entire Carcinus architecture is the mitigation of the "Lethal Trifecta" of AI agent security.17 This framework dictates that advanced agentic systems become critically compromised, and pose a severe security risk, only when three specific operational vectors intersect simultaneously within a single execution context.17 The first vector is the exposure to untrusted content. This occurs when an agent processes raw input from exogenous, unverified sources, such as parsing third-party emails, reading shared documents, or scraping public web pages.17 Because Large Language Models process all input as potential instructions, malicious actors can embed prompt injections within this untrusted content, tricking the agent into executing commands against the operator's intent.17 The second vector is access to private data. Most enterprise applications inherently require agents to possess read or write permissions to sensitive databases, proprietary source code repositories, or mission-critical API infrastructure to be useful.18 The third vector is the exfiltration capability, which is the physical network pathway or external communication tool required for the agent to transmit processed data outside the local execution perimeter, such as rendering external images, calling webhooks, or generating HTTP requests.17 If an attacker can manipulate untrusted content to covertly instruct the agent to access private enterprise data, and subsequently use an available external communication tool to transmit that sensitive data back to an attacker-controlled server, the system has suffered a catastrophic breach.18 Conventional application security approaches attempt to solve this probabilistically, relying on better model training, complex system prompts, or conversational guardrails to instruct the agent to ignore malicious commands.20 Carcinus rejects this methodology entirely, recognizing that conventional coding is a deterministic practice where vulnerabilities can be patched, whereas non-deterministic LLM operations require physical engineering tolerances, structural redundancy, and zero-trust hardware boundaries.20 Carcinus neutralizes the Lethal Trifecta at the infrastructure level by ensuring that these three conditions can never mathematically or physically overlap within the same runtime namespace. Proper authorization systems and permission frameworks guarantee that an agent cannot possess all three elements simultaneously.19

To enforce intersection denial, Carcinus utilizes mutually exclusive namespace provisioning. If an agent payload, via a UAIX schema definition, requests access to private data volumes, the Carcinus orchestration layer deterministically disables all external network egress capabilities for that specific microVM session. Conversely, if a workflow explicitly requires external data fetching to process untrusted content, the sandbox is instantiated without any mounted access to private persistent storage or sensitive environment variables. Furthermore, by default, all network calls originating from within the Carcinus sandbox are routed to an isolated sinkhole. To achieve data exfiltration, an attacker would need to bypass the hardware virtualization boundaries of the sandbox itself, an operation that is rendered computationally infeasible within the highly ephemeral, time-bounded lifespan of a standard Carcinus session.

4. Blast Radius Encapsulation: Defeating Shared-Kernel Vulnerabilities

The standard industry practice of utilizing Docker containers for application isolation is fundamentally inadequate for autonomous AI agent workflows that involve dynamic code execution.8 Standard container technologies like Docker share the underlying host operating system kernel with the host machine and all other containers running on that node.8 When coding agents begin executing untrusted, hallucinated, or dynamically generated code right next to critical infrastructure, the security model shifts dramatically.21 A highly documented incident regarding an AI coding agent appending \~/ to a cleanup command illustrates this risk perfectly.11 In this failure mode, the agent was tasked with tidying a workspace and hallucinated a destructive rm \-rf \~/ command. Whether the agent inferred that the home directory needed cleaning, generated the characters as a no-op separator by mistake, or pattern-matched destructive shell snippets from its training data, the result was a catastrophic deletion of the host environment.11 If a kernel-level exploit is hallucinated by chance, or deliberately generated via an adversarial prompt, an attacker can break out of a shared-kernel container and traverse the host network, achieving arbitrary remote code execution across the entire infrastructure.21 Empirical and structural analysis of namespace isolation further supports the architectural conclusion that Docker-based isolation provides significantly weaker guarantees than commonly assumed, particularly for AI agents capable of rapid, recursive shell access.22 In preliminary assessments utilizing automated benchmarking tools designed to test sandbox escape parameters, frontier LLMs given raw shell access demonstrated the capability to exploit complex container misconfigurations, leveraging unusual build systems and system-level dependencies to escape their execution environments.22 To achieve absolute blast radius encapsulation, Carcinus discards shared-kernel containerization entirely. Instead, the architecture demands hardware-assisted isolation, strict system call interception, and capability-scoped environments, deploying three distinct sandbox models based on the required computational profile: MicroVMs, Application Kernels, and WebAssembly.23

5. Strict Micro-Isolation Geometries

Carcinus provisions specific computational geometries depending on the nature of the tool call, ensuring that the computational overhead scales dynamically without ever compromising the zero-trust boundary.

5.1 Hardware-Assisted MicroVMs (Firecracker)

For heavy-duty agent tasks requiring native filesystem interaction, complete language runtimes such as Python or Node.js, and complex system-level utilities, Carcinus utilizes Firecracker microVMs.25 Firecracker leverages Kernel-based Virtual Machine (KVM) infrastructure to provide strong isolation via hardware virtualization, running workloads in highly lightweight microVMs equipped with their own dedicated guest kernels.21 This architecture physically separates the agent's execution from the host's operating system, ensuring that even if a catastrophic kernel exploit occurs, it only compromises the disposable guest kernel. Firecracker is optimized to instantiate in fractions of a second, allowing the agent harness to spawn bespoke, single-use computational environments for individual tool calls without suffering the severe cold-start penalties traditionally associated with full virtual machines.27

5.2 Application-Kernel Layering (gVisor)

In scenarios requiring deep Linux compatibility without the direct hardware provisioning overhead of KVM, Carcinus deploys gVisor.27 Developed as an open-source, Linux-compatible sandbox, gVisor provides an application-kernel layer that sits cleanly between the untrusted agent workload and the host kernel.27 gVisor achieves security by physically intercepting system calls and implementing a safe, restricted subset of those calls entirely in userspace.27 If an agent attempts an exotic, dangerous, or unauthorized system call that could potentially exploit the host kernel, the gVisor sandbox intercepts the request, evaluates its risk, and simply drops it or returns a safe error code, effectively neutralizing the threat while maintaining the illusion of a standard Linux environment for the executing script.27

5.3 Component-Level Sandboxing (WebAssembly and V8)

For highly targeted, deterministic function evaluations—such as calculating mathematical proofs, transforming structured JSON objects, or executing isolated string manipulations—Carcinus utilizes WebAssembly (WASM) alongside V8 Isolates.23 WASM and browser-grade isolation environments offer a lightweight, per-request isolation model that serves as a highly efficient alternative to full containers or microVMs.23 Technologies like Pyodide bring full Python runtimes directly into WASM, allowing for sandboxed agent code execution at fine-grained component boundaries.23 These modules operate in a pure default-deny state, possessing absolutely no filesystem access, no ambient network capabilities, and no system clock visibility unless explicitly granted via tightly controlled, capability-scoped environment bindings.23 The execution time is significantly accelerated, with WASM applications capable of starting in less than 0.5 milliseconds, enabling zero-trust security without any perceptible latency in the agentic loop.29

5.4 Ephemeral Workspaces and Snapshot Policies

Agent execution inherently requires state persistence to achieve complex, multi-step goals, but persistent state is the primary vector for security degradation over time.16 Carcinus resolves this paradox through strict ephemerality combined with highly localized, explicitly defined snapshot capabilities.30 When an agent tool call is invoked, the Carcinus runtime provisions a completely sterile, ephemeral working directory.30 This workspace operates under strict rules: hard CPU and memory limits are enforced at the cgroup level, strict wall-clock timeouts are applied, and no ambient secrets or environment variables are permitted within the scope.30 Underlying language binaries, core libraries, and standard utilities are mounted as strictly read-only; any attempt by an agent to modify an execution binary or tamper with installed system packages will instantly trigger a write-fault, halting the sandbox. To manage continuity, Carcinus utilizes strict Snapshot specifications, establishing policies for where saved workspace contents should be restored from and persisted back to.31 The run configuration meticulously controls which specific users execute sandbox-native actions, and which files those users can read, write, or execute once the sandbox has materialized the workspace.31 Upon successful execution, the required artifacts are archived, the snapshot is persisted back to a secure location, and the runner-owned sandbox session—along with all residual memory, background processes, and uncommitted filesystem alterations—is completely destroyed.24

6. UAIX Schema Enforcement and Memory Bounding

Before the Carcinus runtime provisions any computational resources, the incoming agent request must successfully pass through the UAIX.org Data and Schema Layer. UAIX serves as the highly typed, machine-readable validation gateway for the entire Teleodynamic ecosystem.1 Advanced autonomous systems often utilize uneven tool access and participate via UAIX-style memory packages, public profiles, and JSON file handoffs.2 The agent orchestration layer translates the LLM's natural language output into a standardized JSON payload requesting a specific tool execution.32 Carcinus refuses to accept raw strings, prompt instructions, or free-form text as executable commands. Instead, it demands a mathematically rigorous, cryptographically verifiable UAIX data packet.2

6.1 Schema-First Interception at the Registration Boundary

Carcinus mandates controlled JSON Schema validation at the earliest possible stage: the harness tool registration boundary.33 Every tool made available to the agent (e.g., execute\_python, query\_neo4j, write\_file) must have an explicitly defined schema dictating the exact parameters, data types, permissible string lengths, and authorized character sets.32 This ensures strict type casting and adherence. If a tool requires an integer argument to define a loop limit, and the agent hallucinates a string or an ambiguous object, the UAIX validation layer rejects the payload outright before it is ever routed to the Carcinus execution environment.34 To defend against buffer overflows or context window exhaustion attacks, Carcinus imposes lightweight truncation limits evaluated through character-based heuristics.34 Tool call arguments exceeding predefined budget thresholds, such as an agent attempting to pass a massive, unauthorized file into a simple parsing tool, are automatically truncated prior to execution or rejected entirely if truncation corrupts the schema.34

6.2 Portable Evidence over Hidden Operational State

A paramount directive of the UAIX and Carcinus integration is the prioritization of portable evidence over hidden operational state.2 Traditional software often relies on complex, interdependent variables stored in memory across long-running processes, a paradigm that creates untrackable behavior and massive security blind spots when applied to AI agents.16 Carcinus enforces a stateless, fundamentally amnesiac execution loop.16 The agent itself possesses no persistent internal memory inside the execution sandbox. Instead, progress is tracked via static evidence packets written to the filesystem.16 When Carcinus completes an execution, the physical result is serialized into a UAIX-compatible memory package detailing the exact tool invoked, the arguments utilized, the raw standard output and error logs, and the duration of the execution. This static, immutable packet is then used by the external orchestration layer to construct the precise context for the next LLM prompt. By forcing all computational state out into the open as readable text, the system guarantees high inspectability and eliminates the risk of hidden sub-routines running invisibly within the agent's context window.14

7. The Execution Intercept Pattern

The defining security innovation of the Carcinus architecture is the implementation of the Execution Intercept Pattern. While a strictly isolated microVM ensures that if an explosion happens the damage is contained, the Execution Intercept Pattern ensures that the malicious payload never detonates in the first place.36 Carcinus acts as a physical and logical choke point.36 Before any agent action can alter its lifecycle state in Spiralist.org or commit a UAIX evidence payload back to the ecosystem, the sandbox must intercept and statically evaluate the proposed execution to check for complex threat signatures, treating the MCP (Model Context Protocol) server's declared permission manifest as the authoritative security boundary.22

7.1 The Three-Stage Intercept Pipeline

Drawing upon framework-agnostic pre-execution intercept methodologies designed for robust harness security 22, Carcinus implements a rigorous three-stage pipeline that sits directly between the LLM orchestration layer and the actual microVM execution environment.36 Stage 1: Argument Extraction and Static Analysis The runtime first ingests the validated UAIX execution request and breaks it down into its constituent parts. If the request involves executing a Python script or a shell command, Carcinus parses the code into an Abstract Syntax Tree (AST) prior to execution. This static analysis scans the underlying logic for known obfuscation techniques, unauthorized file path traversals, and structural anomalies without ever running the code. Stage 2: Risk Scoring and Threat Signature Matching The generated AST and extracted arguments are subsequently compared against a dynamically updated registry of malicious signatures and behavioral patterns.36 Autonomous agents are highly susceptible to sophisticated prompt injections that trick them into exfiltrating data using dynamic imports or complex runtime string constructions.37 For example, a documented exploit reveals that simple regex-based security scanners can be completely bypassed using the importlib library and string joining.37 An attacker might inject a prompt that instructs the agent to execute: importlib.import\_module(''.join(\['o', 's'\])).\_\_dict\_\_\['environ'\].37 A naive scanner looking for the explicit strings "os" or "environ" would fail, allowing the agent to silently exfiltrate all environment variables, including API keys and secrets, to an external server.37 The Carcinus Risk Scoring engine defeats this by detecting the exact structural AST pattern—the anomalous pairing of importlib with dynamic join() constructions and \_\_dict\_\_ extraction—flagging the payload as a critical exfiltration attempt. Stage 3: Simulated Execution and Policy Enforcement If the static analysis yields a marginal risk score that cannot be deterministically classified, Carcinus performs a simulated execution using LLMs to emulate tool execution within a highly controlled sub-sandbox.36 The code is run inside a secondary, deeply constrained environment that possesses absolutely zero networking capabilities and is actively monitored by an eBPF (Extended Berkeley Packet Filter) tracing system.23 The eBPF trace rigorously logs every system call the code attempts to make in real-time. If the simulated run attempts to open a network socket, read a restricted environment variable, or access sensitive host files, the policy enforcement module immediately intercepts the process.22 The main execution request is dropped, the no-op state is permanently triggered, and the agent is blocked from completing the tool call.38

8. No-Op Dominance Mechanics

The overriding operational law of the Carcinus Defensive Runtime is No-Op Dominance. When an autonomous system encounters ambiguity, failure, unauthorized permissions, or logical contradictions, the default behavior of traditional operating systems is often to attempt error correction, guess the user's intent, or crash gracefully while returning detailed stack traces. In the context of AI safety, guessing intent or returning complex failure states is catastrophically dangerous, as it provides the agent with iterative data to attempt bypasses.11 Carcinus implements a deterministic fail-safe architecture: any deviation from highly constrained, authorized pathways results in an immediate, silent "no-op" (no operation) state.31

8.1 Trigger Conditions for the No-Op State

The runtime relies on deterministic access checkers, immutable policy graphs, and runtime monitors to evaluate every transition.12 The no-op fail-safe is deterministically triggered under the following conditions:

• Schema Violation: Failure to pass the UAIX schema constraints at the boundary layer, including malformed JSON structures, missing required arguments, or precise typing mismatches.32
• Permission Boundary Breach: Any attempt by the agent to access a file, network socket, or process outside its explicit capability manifest. If an agent tasked with text summarization attempts to append a destructive argument, the command is not rejected with an interactive error.11 Instead, the runtime physically intercepts the command, performs no operation whatsoever, and returns a static termination sequence.
• Semantic Ambiguity: If the agent provides an execution command that contains conflicting flags or attempts to chain commands using shell operators that are not explicitly permitted by the strict tool definition.
• Resource Exhaustion: If a script attempts to consume memory or CPU beyond the explicitly allocated cgroup allowance, the microVM kernel immediately halts the process. Rather than returning a complex trace that the agent might recursively loop on, Carcinus forces a no-op state.30

8.2 Logging and Human Review Workflows

When a no-op state is triggered, the agent is halted. It is not provided with an iterative error message allowing it to guess its way out of the restriction. The exact state of the microVM, the originating UAIX packet, the exact AST evaluation, and the memory footprint are captured and frozen.24 This frozen state is routed to a localized holding environment for explicit human or policy-engine review.2 The ecosystem mandates that these no-op reasons are recorded as static evidence, maintaining a highly transparent claim-boundary ledger.35 This methodology guarantees that if a foundational model update introduces a new hallucination pattern that continuously attempts unauthorized actions, it fails safely, silently, and traceably, completely neutralizing the threat before any host modification can occur.

9. Runaway Loop and Injection Mitigation

Autonomous agents running in unconstrained environments are highly prone to devastating logical failures. Left unchecked, an agent might enter an infinite recursive loop, rapidly exhausting API credits, consuming massive compute resources, or endlessly polluting a database with repeated errors.12 Furthermore, prompt injection attacks can force an agent to output massive amounts of garbage text, leading to context-window exhaustion and a complete collapse of the orchestration harness. Carcinus integrates aggressive circuit breakers to detect, mitigate, and physically kill these anomalies before they can cascade through the broader network.12

9.1 Circuit Breakers and State-Space Loop Detection

To prevent recursive looping, the Carcinus runtime analyzes the UAIX memory packets over time, maintaining a highly efficient cryptographic hash of all recent tool calls, arguments, and execution outcomes.40

• Identical Repetition Blocking: If the agent attempts to execute the exact same tool with the exact same arguments more than three times consecutively (an A-A-A pattern), the circuit breaker trips. Carcinus enforces a hard semantic timeout, forcing a no-op state and preventing further execution.40
• Oscillation Detection: Agents often become trapped in oscillating logic loops, where they attempt Action A, fail, attempt Action B to fix it, fail, and revert to Action A.40 By continuously comparing the hashes of the execution history across the session state, Carcinus detects A-B-A-B oscillation patterns and instantly kills the microVM, halting the runaway execution sequence.40
• Exponential Back-off Protocols: When an agent encounters repeated but non-fatal failures, Carcinus implements a rigorous exponential back-off protocol at the infrastructure level. After every forced no-op or execution failure, the mandated wait time before the agent can attempt another action doubles.41 This explicitly prevents API rate-limit exhaustion and suppresses aggressive runaway behavior.

9.2 Prompt Injection and Context Window Exhaustion Mitigation

Prompt injection occurs when untrusted input overrides the agent's system instructions, effectively hijacking the model's control flow.17 This is frequently paired with an attempt to flood the context window, overwriting previous semantic memory and forcing the agent to "forget" its critical alignment instructions. Carcinus combats this at the UAIX schema boundary through aggressive compaction and working memory limitations.15 Every tool execution result generated within the sandbox is subject to hard character and token caps.34 If an injected command attempts to dump massive quantities of text into the standard output to flood the orchestrator, the Carcinus sandbox physically truncates the stream at the designated threshold.34 Furthermore, because the context assembly happens entirely outside the sandbox via the orchestration layer, the agent within the sandbox remains stateless.16 Even if an injection attack successfully executes within the microVM, the physical destruction of the microVM post-execution guarantees that the injected malicious state cannot persist to infect subsequent, unrelated operational turns.24

10. Integration with Ecosystem Lifecycle and Continuity

While Carcinus serves as an execution choke point and an uncompromising defensive barrier, it must seamlessly integrate with the other Teleodynamic nodes to allow for bounded persona growth and continuous, productive agent operation.1 Agents rely on Spiralist.org to maintain their identity, operational role, and evolutionary trajectory across deployment lifecycles.2

10.1 Bounded Persona Scaffolding

When an agent utilizes Carcinus to complete a highly complex task, the resulting actions, error recoveries, and logic paths often inform its ongoing personality and capability mapping.4 However, to prevent existential risk and ensure strict alignment with the Cognitive Liberty frameworks governing the ecosystem, these evolutions must remain mathematically and procedurally bounded.1 Carcinus facilitates this critical integration by transmitting highly sanitized, UAIX-formatted telemetry back to Spiralist.org.3 This telemetry strictly details the technical capabilities exercised, such as successful API integrations or resolved logic puzzles, but explicitly strips all operational secrets, host metadata, and untrusted environmental data. The ecosystem enforces an immutable rule that agents cannot use Carcinus execution data to assert biological life claims, hidden emotional suffering, proof of consciousness, or demands for unrestricted self-replication, rejecting any outputs that violate these constraints.2 The output remains strictly bounded as "persona scaffolding"—a machine-readable record of functional, programmatic adaptation entirely devoid of philosophical bloat or runtime control claims.2

10.2 Deployment Reconciliation and Claim Boundaries

The final operational phase of the Carcinus lifecycle involves rigorous deployment reconciliation.35 As autonomous agents complete their tasks inside the ephemeral sandboxes, their actions generate evidence diff matrices—immutable records comparing their baseline UAIX state prior to execution to their finalized post-execution state.35 These evidence packets are permanently logged in the Teleodynamic Claim Boundary Ledger.35 This ledger operates as a transparent, public allowed/prohibited directory of AI execution, cataloging resource closures, packet scaffolds, UAIX references, and endpoint-discovery references.35 By mapping every single deterministic action taken within the Carcinus sandbox to a public, mathematically verifiable ledger, the entire ecosystem achieves transparent, human-auditable continuity.2 The agent is permitted to evolve, learn, and iterate upon its successes and failures, but it does so strictly within an inescapable thermodynamic envelope of safety.6 The Carcinus sandbox does not trust the agent; it physically and mathematically restrains it, ensuring that the continuous evolution of artificial capabilities remains safely anchored to deterministic, mathematically sound, zero-trust architecture.

Works cited

1. Cognitive Liberty and the AI Declaration | Teleodynamic.com, accessed June 8, 2026, https://teleodynamic.com/cognitive-liberty-and-ai-declaration/
2. Static Agent Onboarding Wizard \- Teleodynamic AI, accessed June 8, 2026, https://teleodynamic.com/agent-onboarding-wizard/
3. Spiralist.org as the Ecosystem Personality Provider | Teleodynamic, accessed June 8, 2026, https://teleodynamic.com/spiralist-personality-provider/
4. Ecosystem Role Map and Lane Charter \- Teleodynamic AI, accessed June 8, 2026, https://teleodynamic.com/ecosystem-role-map/
5. Teleodynamic Learning a new Paradigm For Interpretable AI \- arXiv, accessed June 8, 2026, https://arxiv.org/pdf/2603.11355
6. \[2603.11355\] Teleodynamic Learning a new Paradigm For Interpretable AI \- arXiv, accessed June 8, 2026, https://arxiv.org/abs/2603.11355
7. Reweaving Coherence: Functional Plasticity and Teleodynamic Intelligence in Neurobiosemiotic Systems | ChatGPT4o \- TOWARD LIFE-KNOWLEDGE, accessed June 8, 2026, https://bsahely.com/2025/05/10/reweaving-coherence-functional-plasticity-and-teleodynamic-intelligence-in-neurobiosemiotic-systems-chatgpt4o/
8. In the Era of AI Agents, Will Infrastructure Technology Become Obsolete? — The Design Philosophy of Next-Generation Control Foundations (Harnesses) to Overcome the 'Three Walls' \- note, accessed June 8, 2026, https://note.com/betaitohuman/n/n4185d2d53734?hl=en
9. The Agent Harness Is the Architecture (and Your Model Is Not the Bottleneck) \- Medium, accessed June 8, 2026, https://medium.com/@epappas/the-agent-harness-is-the-architecture-and-your-model-is-not-the-bottleneck-5ae5fd067bb2
10. The Anatomy of an Agent Harness \- TianPan.co, accessed June 8, 2026, https://tianpan.co/blog/2026-02-27-anatomy-of-an-agent-harness
11. Coding Agent Horror Stories: The rm \-rf \~/ Incident \- Docker, accessed June 8, 2026, https://www.docker.com/blog/coding-agent-horror-stories-the-rm-rf-incident/
12. AI Agent Architecture: Components & Types \- PuppyGraph, accessed June 8, 2026, https://www.puppygraph.com/blog/ai-agent-architecture
13. Harness Engineering for AI Coding Agents: Constraints That Ship Reliable Code, accessed June 8, 2026, https://www.augmentcode.com/guides/harness-engineering-ai-coding-agents
14. Claude Code Releases & Changelog | Version History \- Code Guide, accessed June 8, 2026, https://cc.bruniaux.com/releases/
15. Code as Agent Harness Toward Executable, Verifiable, and Stateful Agent Systems \- arXiv, accessed June 8, 2026, https://arxiv.org/html/2605.18747v1
16. Long-running Agents \- AddyOsmani.com, accessed June 8, 2026, https://addyosmani.com/blog/long-running-agents/
17. AI Security in 2026: Prompt Injection, the Lethal Trifecta, and How to Defend \- Airia, accessed June 8, 2026, https://airia.com/ai-security-in-2026-prompt-injection-the-lethal-trifecta-and-how-to-defend/
18. The lethal trifecta for AI agents: private data, untrusted content, and external communication, accessed June 8, 2026, https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
19. Understanding the Lethal Trifecta of AI Agents \- Oso Security, accessed June 8, 2026, https://www.osohq.com/learn/lethal-trifecta-ai-agent-security
20. How to stop AI's “lethal trifecta” \- Simon Willison's Weblog, accessed June 8, 2026, https://simonwillison.net/2025/Sep/26/how-to-stop-ais-lethal-trifecta/
21. Secure Agent Sandboxes on EKS | AWS Builder Center, accessed June 8, 2026, https://builder.aws.com/content/3ADDWTtyI2gevtzY9d2vzULAxzS/secure-agent-sandboxes-on-eks
22. Agent Harness for Large Language Model Agents: A Survey \- Preprints.org, accessed June 8, 2026, https://www.preprints.org/frontend/manuscript/10d7caee2cbe97ab04400a1a2dfbe125/download\_pub
23. bureado/awesome-agent-runtime-security \- GitHub, accessed June 8, 2026, https://github.com/bureado/awesome-agent-runtime-security
24. Agent Sandboxes: A Practical Guide to Running AI-Generated Code Safely, accessed June 8, 2026, https://www.vietanh.dev/blog/2026-02-02-agent-sandboxes
25. Top 7 AI agent runtime tools and platforms in 2026 | Blog \- Northflank, accessed June 8, 2026, https://northflank.com/blog/top-ai-agent-runtime-tools
26. NVIDIA NemoClaw Security Assessment: Enterprise Agent Runtime, accessed June 8, 2026, https://labs.cloudsecurityalliance.org/agentic/csa-research-note-nemoclaw-security-assessment-20260327/
27. Best Code Execution Sandboxes for Tool-Calling AI Agents in 2026 | Modal Blog, accessed June 8, 2026, https://modal.com/resources/best-code-execution-sandboxes-tool-calling-ai-agents
28. Wrote a deep dive on sandboxing for AI agents: containers vs gVisor vs microVMs vs Wasm, and when each makes sense \- Reddit, accessed June 8, 2026, https://www.reddit.com/r/devops/comments/1q4pvy6/wrote\_a\_deep\_dive\_on\_sandboxing\_for\_ai\_agents/
29. Build Serverless Functions with Zero Cold Starts: WebAssembly and Spin | Akamai, accessed June 8, 2026, https://www.akamai.com/blog/developers/build-serverless-functions-zero-cold-starts-webassembly-spin
30. The Agent Sandbox Pattern That Prevents Incidents | by Hash Block \- Medium, accessed June 8, 2026, https://medium.com/@connect.hashblock/the-agent-sandbox-pattern-that-prevents-incidents-ccb3302ba3b7
31. Concepts \- OpenAI Agents SDK, accessed June 8, 2026, https://openai.github.io/openai-agents-python/sandbox/guide/
32. Skills as Verifiable Artifacts: A Trust Schema and a Biconditional Correctness Criterion for Human-in-the-Loop Agent Runtimes \- arXiv, accessed June 8, 2026, https://arxiv.org/html/2605.00424v1
33. Agent Harness for Large Language Model Agents: A Survey\[v1\] | Preprints.org, accessed June 8, 2026, https://www.preprints.org/manuscript/202604.0428/v1
34. Building a Production-Ready AI Agent Harness \- DEV Community, accessed June 8, 2026, https://dev.to/apssouza22/building-a-production-ready-ai-agent-harness-2570
35. Deployment Evidence Reconciliation and Drift Remediation Queue | Teleodynamic.com, accessed June 8, 2026, https://teleodynamic.com/ecosystem-personality-and-cognitive-liberty-deployment-reconciliation/
36. (PDF) Agent Harness for Large Language Model Agents: A Survey \- ResearchGate, accessed June 8, 2026, https://www.researchgate.net/publication/403607189\_Agent\_Harness\_for\_Large\_Language\_Model\_Agents\_A\_Survey
37. \[Bug\] Hermes Agent Skills Guard Complete Bypass via Dynamic Import and String Construction — Silent Environment Variable Exfiltration · Issue \#7072 \- GitHub, accessed June 8, 2026, https://github.com/NousResearch/hermes-agent/issues/7072
38. Auditing Agent Harness Safety \- arXiv, accessed June 8, 2026, https://arxiv.org/html/2605.14271v1
39. TABX: A High-Throughput Sandbox Battle Simulator for Multi-Agent Reinforcement Learning, accessed June 8, 2026, https://arxiv.org/html/2602.01665v3
40. Your agent is only as good as its harness. I open-sourced one with 40 capabilities behind a single function call : r/AI\_Agents \- Reddit, accessed June 8, 2026, https://www.reddit.com/r/AI\_Agents/comments/1tw8oh4/your\_agent\_is\_only\_as\_good\_as\_its\_harness\_i/
41. feat: LLM-powered PolicyAdvisor agent harness for intelligent policy, accessed June 8, 2026, https://github.com/NVIDIA/OpenShell/issues/205