The I2EA Execution Boundary is not defined by specific technologies such as eBPF, LSM, or BPF Maps. What matters is the separation between Architectural Requirements that must remain constant and the Implementation used to realize them.

First, the Execution Boundary requires Decisions to be formed on the Governance side. The Execution Layer does not reinterpret Policy or form new Decisions; it receives an already formed Decision and Enforces it at Runtime. Second, Deterministic Enforcement is required so that the same Decision and Execution Conditions produce a consistent Enforcement Result.

Additional requirements include Fail-Safe Behavior, which prevents Execution when valid Enforcement State cannot be verified; Non-bypassability, which ensures that Governed Execution cannot circumvent the Enforcement Point; and Evidence Return, which returns actual Enforcement results to the Governance Layer as Evidence.

Together, these properties constitute the Architectural Requirements of the Execution Boundary.

How these requirements are implemented may vary across environments. In Linux environments, eBPF / LSM may provide one implementation approach, while OS-specific Control Mechanisms, Sandboxes, API Gateways, Device Controllers, or other Enforcement Mechanisms may satisfy the same Requirements. Physical AI and connections to external Systems may require Boundaries outside the OS Kernel.

I2EA therefore does not prescribe a specific Implementation. It requires the preservation of Governance-side Decision, Deterministic Enforcement, Fail-Safe Behavior, Non-bypassability, and Evidence Return.

This Non-Prescriptive Design allows the Execution Boundary to remain independent of any particular OS, Model, Agent Framework, or Application Architecture, while enabling each environment to adopt an appropriate Implementation.

Requirements remain constant; implementation may vary.

This is the fundamental principle supporting the Portability of the Execution Boundary.