Apparatuses, methods, and non-transitory computer-readable media for intent-driven secure execution of workflows

Abstract

Apparatuses and methods for intent-driven secure execution of workflows and non-transitory computer-readable media are described herein. A non-transitory computer-readable medium storing instructions that, when executed by one or more processing circuitries, cause the one or more processing circuitries to perform a method is provided. The method includes receiving a user-defined intent specifying a high-level computing goal. The method further includes generating an execution workflow of the computing goal based on one or more computing components corresponding to the user-defined intent. The method further includes executing the execution workflow in accordance with obtained execution constraints. The execution workflow is executed within an isolated execution environment that is deployed inside a trusted execution environment. The method further includes monitoring execution of the execution workflow within the isolated execution environment to ensure compliance with the execution constraints.

Description

Background Technology

[0001] Intent-driven computation (also known as intent-based programming) can be represented as a shift from traditional instruction-based computation (where the system is explicitly told what to do) to more flexible and context-aware systems that can understand and respond to user intents. (This is achievable, for example, through advances in artificial intelligence, machine learning, and natural language processing.) This shift allows the system to interpret the goals the user wants to achieve, rather than simply executing predefined commands. Combined with the broader concept of machine programming (where the system can dynamically generate its own software), this leads to scenarios where the user may no longer have complete control or visibility over what is being performed. Once the user specifies a high-level intent, the system automatically interprets the intent and dynamically assembles and executes software or services to achieve the specified computational goal. However, this dynamic and autonomous assembly of software components and services can introduce trust gaps. When a system performs a task using dynamically selected and assembled computational components, even if the individual components are trustworthy, uncertainty remains regarding the correctness, security, and reliability of the assembled solution as a whole. Guarantees may be required not only for the individual components but also for their orchestration and interaction. This challenge can be further complicated by the uniqueness of each execution instance, making comparisons with known good references impractical. From the service provider's perspective, there is a desire to retain the flexibility of dynamically exchanged components, for example, to optimize costs or meet service level agreements without the need for renegotiation or manual intervention. Attached Figure Description

[0002] Examples of apparatuses and / or methods will be described below by way of example only and with reference to the accompanying drawings, in which:

[0003] Figure 1 The diagram illustrates an example of a non-transitory computer-readable medium;

[0004] Figure 2 A block diagram illustrating an example of a device or apparatus;

[0005] Figure 3 The flowchart illustrates an example of the method;

[0006] Figure 4 The diagram illustrates an example of the setup phase of a programming flow for user-defined intent programming; and

[0007] Figure 5 The diagram illustrates an example of the runtime phases of a programming flow used for user-defined intent programming. Detailed Implementation

[0008] Some examples will now be described in more detail with reference to the accompanying drawings. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications to the features, as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not limit other possible examples.

[0009] Throughout the description of the accompanying drawings, the same or similar reference numerals refer to the same or similar elements and / or features, which may be identical or implemented in modified form while providing the same or similar function. For clarity, the thickness of lines, layers, and / or areas in the drawings may also be enlarged.

[0010] When two elements A and B are combined using "or", it should be understood that this discloses all possible combinations: A only, B only, and A and B, unless otherwise explicitly defined in individual cases. As alternative wording for the same combination, "at least one of A and B" or "A and / or B" can be used. This is equivalent to combinations of more than two elements.

[0011] If singular forms such as “a / an” and “the” are used and the use of only a single element is neither explicitly nor implicitly mandatory, further examples may also use several elements to achieve the same functionality. If the functionality is described below as being implemented using multiple elements, further examples may use a single element or a single processing entity to achieve the same functionality. Further understanding is that when the terms “include,” “including,” “comprise,” and / or “comprising” are used, the presence of the features, integers, steps, operations, processes, elements, components, and / or groups thereof specified in the description is included, but the presence or addition of one or more other features, integers, steps, operations, processes, elements, components, and / or groups thereof is not excluded.

[0012] Specific details are set forth in the following description, but examples of how the techniques described herein can be implemented without these specific details are provided. Well-known circuits, structures, and techniques are not shown in detail to avoid obscuring the understanding of this specification. Terms such as "an example," "various examples," "some examples," etc., may include features, structures, or characteristics, but not every example necessarily includes these specific features, structures, or characteristics.

[0013] Some examples may have some or all of the features described for other examples, or none of them. "First," "second," "third," etc., describe common elements and indicate different instances of the same element being referenced. Such adjectives do not imply that the element items so described must be in a given order, in time or space, in rank, or in any other way. "Connected" may indicate that elements are in direct physical or electrical contact with each other, and "coupled" may indicate that elements cooperate or interact with each other, but these elements may or may not be in direct physical or electrical contact.

[0014] As used herein, the terms “operation,” “execution,” or “running” are used interchangeably when referring to software or firmware in relation to a system, device, platform, or resource, and may refer to software or firmware stored in one or more computer-readable storage media accessible by the system, device, platform, or resource, even if the instructions contained in the software or firmware are not being actively executed by the system, device, platform, or resource.

[0015] The specification may use the phrases “in an example,” “in examples,” “in some examples,” and / or “in various examples,” each of which may refer to one or more examples of the same or different examples. Furthermore, the terms “comprising,” “including,” “having,” etc., as used in relation to examples of this disclosure are synonymous.

[0016] As described above, intention-based programming represents a shift from traditional, instruction-based computation (see also "Intention-Driven Computing: Reality or Sci-Fi?" available at https: / / www.linkedin.com / pulse / intention-driven-computing-reality-sci-fi-afshin-asli-0e4vc). Existing approaches in this area (such as machine programming systems (e.g., see “The three pillars of machine programming” by Gottschlich, Justin, et al., Proceedings of the 2nd ACM SIGPLAN International Workshop on Machine Learning and Programming Languages ​​(2018)))) may rely on a high degree of user trust in the system, which translates user-defined intents into execution workflows for computational components, the computational components themselves, and the execution environment. In some cases, where the system, execution environment, or computational components are open source, users may be able to inspect the source code to a limited extent. However, due to the complexity and dynamism of such systems, where computational components can be dynamically exchanged during execution, achieving a meaningful level of guarantees for the correctness and security of overall execution may be impractical or infeasible. Existing solutions that provide a high degree of trust (such as those based on confidential computing techniques (see Wikipedia: “Confidential computing”)) may rely on fixed integrity measurements and static combinations of services. In such systems, any self-organizing modifications to services during execution generally require renegotiating prior agreements and contracts with dependents, which limits runtime flexibility and dynamic adaptation.

[0017] The technique described in this paper introduces a novel form of sandbox component, enabling the evaluation of the correctness of self-organizing software or service packages and their execution (dynamically assembled based on user-defined intents). The proposed technique addresses trust issues arising when software components (whether libraries or web services) are dynamically assembled (often by third-party systems and beyond direct user control) to accomplish complex tasks. The importance of this problem has increased with the emergence of new programming paradigms, such as intent-driven programming. In such paradigms, users specify tasks to be performed in the form of high-level intents, which are then processed by a system that analyzes the intents and translates them into an execution plan (in the form of an executable workflow). The workflow can implement the business logic that requires the task to be performed, including interactions with a given set of components or categories of components. Executing the workflow can run within a target execution environment that provides access to all components required to complete the plan.

[0018] The proposed technology introduces a mechanism that allows for the formal evaluation of the correctness of dynamically assembled software or service packages and their execution. The evaluation mechanism can analyze inputs / outputs and anomalous resource usage (e.g., SLA compliance, resource shortages, potential data breach attempts, compliance issues, etc.). If the mechanism detects anomalies (e.g., SLA violations), it may take further action (e.g., prohibiting the execution of the violating software / service) or implement remedial measures (e.g., dynamically replacing the faulty software / service with an alternative version). The mechanism (with direct access to user data and requests) can fully monitor the execution of third-party software / services and create execution certificates (for offline analysis). The proposed technology can take the form of a trusted execution container with a collection of regulator components that have direct access to user data and requests, fully monitor the execution of third-party software / services, and create execution certificates (e.g., which can be checked later and used for billing).

[0019] Figure 1 The figure illustrates a block diagram of an example of a non-transitory computer-readable medium 140. The non-transitory computer-readable medium 140 stores instructions that, when executed by one or more processing circuitry systems 130, cause those systems to perform a method (e.g., method 300). The one or more processing circuitry systems 130 can access the non-transitory computer-readable medium 140 via an interface circuitry system 120. In some examples, the non-transitory computer-readable medium 140 may be included in a device 100, which may also include one or more processing circuitry systems 130. In some examples, the one or more processing circuitry systems 130 may be distributed across multiple devices and may be accessed, for example, via an interface circuitry system 120.

[0020] For example, non-transitory computer-readable media can refer to any tangible physical medium capable of storing instructions, data, or other types of information accessible to a computer, processor, or similar electronic device. Computer-readable media can be non-transitory because the medium can have a persistent or durable form. Non-transitory computer-readable media can include one or more of the following computer-readable media: magnetic storage devices (such as hard disk drives (HDDs) and magnetic tape), which use magnetic modes to store data and are commonly used for long-term data storage in computers, servers, and backup systems. Optical storage media, including compact discs (CDs), digital versatile discs (DVDs), and Blu-ray discs, utilize laser technology to read and write data, providing durability and longevity for storage software, media, and backups. More modern forms include solid-state devices (SSDs), which rely on flash memory technology with no moving parts, such as USB flash drives, secure digital (SD) cards, and internal / external SSDs, valued for their fast read / write speeds and portability. Additionally, non-volatile memory chips such as read-only memory (ROM) and programmable ROM (PROM) store critical firmware or embedded software commonly found in embedded systems and computers. Advanced memory technologies, such as phase-change memory (PCM), magnetoresistive RAM (MRAM), and ferroelectric RAM (FeRAM), provide persistent data storage with high reliability, speed, and power efficiency, making them ideal for applications requiring fast access and data retention, such as in mobile devices, high-performance computing, and industrial systems.

[0021] For example, one or more processing circuitry systems 130 may access non-transitory computer-readable medium 140 via interface circuitry system 120. For example, one or more processing circuitry systems 130 may then execute instructions stored on non-transitory computer-readable medium 140. Execution of the instructions stored on non-transitory computer-readable medium 140 enables one or more processing circuitry systems 130 to perform a method (e.g., method 300). This method includes receiving a user-defined intent specifying a high-level computing objective. For example, one or more processing circuitry systems 130 may receive the user-defined intent via interface circuitry system 120, wherein the user-defined intent may originate from various sources such as storage circuitry system 140 or external sources. Storage circuitry system 140 may store the user-defined intent locally, such as in a database, memory module, or other persistent storage medium, while external sources may include remote servers, user equipment, or networked systems that transmit the user-defined intent via wired or wireless communication channels. User-defined intents may be received from a user via various input methods, such as manual text input via a graphical user interface, voice input processed by a speech recognition system, or other forms of human-computer interaction that allow the user to express a high-level computing objective. The interface circuitry 120 can facilitate the transmission of user-defined intent data to the processing circuitry 130 for further processing and interpretation, regardless of the input method.

[0022] For example, a user-defined intent can be information specifying a high-level computational goal that describes an abstract objective to be achieved by a computing system (such as device 100) without detailing the specific implementation steps. The high-level computational goal can define the expected outcome of the computation, such as generating an output dataset, performing analysis, or performing a series of operations on input data, while leaving the choice of computational components, execution sequences, and infrastructure to the computing system. In some examples, user-defined intents can be represented in machine-readable data formats that enable automatic processing by one or more processing circuitry systems 130, such as JSON, XML, or YAML documents, domain-specific languages, or intent-driven programming models. User-defined intents can also be provided using frameworks such as FAST, as described by Yang, Yao-Hsiang et al. in their paper “Language Support for Adaptation: Intent-Driven Programming in FAST” (arXiv preprint arXiv:1907.08695 (2019)). This paper describes how to supply syntax and structures to formalize high-level computational objectives and related adaptive objectives, such as minimizing latency or optimizing resource usage during execution. Additionally, user-defined intents can specify execution constraints, optimization preferences, or security policies, which are incorporated into the system when generating and executing workflows.

[0023] In some examples, the received user-defined intent includes one or more actions for a computational objective. For instance, actions for a high-level computational objective included in a received user-defined intent can be discrete functional elements, each corresponding to specific steps that must be performed to complete the overall computational objective. These actions can be provided directly within the user-defined intent as part of a structured data representation, such as a JSON array listing the required operations in a sequence, or they can be embedded within natural language input and extracted using intent parsing techniques. Each action can include associated metadata (such as required input and output formats, dependencies on other actions, and applicable execution constraints) that allows the system to correctly interpret the actions and assemble them into an executable workflow that performs the complete computation according to the user's intent. For example, the user-defined intent specifying the computational objective might be "book a flight from Munich to Warsaw," and the actions might be "retrieve available flight data," "filter results by price," "process payment," or "generate confirmation."

[0024] For example, user-defined intents can include high-level computational goals such as "summarize customer feedback," "detect anomalies in network operations," or "convert video streams to an optimized format," which the system can interpret and translate into an executable workflow. In other examples, a user-defined intent could include the high-level computational goal "book a flight from Munich to Warsaw," where the computational system identifies and assembles computational components for querying the flight database, filtering available options, processing payment, and generating booking confirmations. In yet another example, a user-defined intent could include the high-level computational goal "generate a financial report based on quarterly transaction data," where the system selects appropriate components for data aggregation, statistical analysis, and report generation, while adhering to specified constraints regarding processing time and data confidentiality.

[0025] When executing instructions stored on a non-transitory computer-readable medium, the method performed by one or more processing circuitry systems 130 further includes generating an execution workflow based on one or more computing components corresponding to a user-defined intent. The computing components may be discrete computing units designed to perform specific computing tasks or processes. A computing component may expose standardized inputs and outputs (allowing it to receive data), apply its internal logic or algorithms, and produce results. Computing components may be designed to be composable, meaning they can be connected to other components through compatible interfaces to form larger, more complex processes. The computing components may interact with each other within an execution workflow arranged in a defined order according to a user-defined intent, which expresses the overall computing objective.

[0026] In some examples, computational components may include at least one of service categories, scripts, dynamically compiled code, or execution modules. For instance, a service category may be a class of services that provides specific types of functionality required to perform actions aimed at high-level computational goals. A service category may describe the general capabilities of the service, including the type of operations performed, the expected input and output formats, and associated performance or security attributes, without specifying a concrete implementation or instance of the service. For example, a service category could be a PDF reader module that extracts text and metadata from PDF documents, converts them into a structured format, and provides interfaces for further processing within larger workflows, such as document classification or search indexing. For each service category, there may be one or more service instances available in the target environment, each providing a concrete implementation of the service category, allowing the system to select a specific service instance during workflow execution based on factors such as availability, performance, or compliance with execution constraints.

[0027] A script can be a set of instructions written in a high-level scripting language, designed to perform a defined set of operations or to automate specific tasks in a workflow. Scripts can be used to prepare data, trigger processes, or orchestrate interactions between components. For example, a script could be a data cleaning routine written in Python that loads a raw CSV file, removes duplicate entries, applies transformations to standardize values, and then calls a machine learning training component to process the cleaned data.

[0028] Dynamically compiled code can be source code generated and compiled during runtime, allowing task-specific executable logic to be created based on user input or real-time conditions. An example could be an on-the-fly GPU kernel where code is created on demand to process large image datasets, dynamically optimized for current hardware configuration and data size before immediate execution.

[0029] An execution module can be a deployable computing unit designed to perform specific tasks within a workflow and expose standardized input and output interfaces. This can include pre-compiled binaries, containerized services, or callable function packages. For example, an execution module could be a video transcoding service packaged in a Docker container that accepts video files, converts them to different formats, and provides outputs that can be called via API within a larger media processing pipeline for further streaming or storage.

[0030] An execution workflow can be a structured sequence of interconnected computing components arranged to collaboratively execute a computational goal according to user-defined intents. Within an execution workflow, each computing component can perform a specific task, and the output of one component can become the input of another, ensuring a continuous and coordinated data flow from initial input to final result. Execution workflows can define the logical order of execution, data dependencies, resource allocation, and error handling processes. They can support various data formats at each stage, such as JSON for structured data exchange, CSV for tabular datasets, binary formats for media content, or domain-specific formats (such as PDF, XML, or image files), depending on the nature of the computational goal and the requirements of the components involved.

[0031] For example, generating an execution workflow includes parsing the received intent to extract one or more actions for the computational objective. Parsing may include analyzing the structured or unstructured content of the user-defined intent to identify the discrete computational steps required to achieve the specified computational objective. Parsing may include interpreting machine-readable formats (such as JSON, XML, or YAML) or processing natural language input to determine relevant parameters, objectives, and constraints expressed within the user-defined intent. Based on this analysis, the system can decompose high-level computational objectives into individual actions (such as data retrieval, data processing, filtering, validation, or output generation), each representing a specific operation to be performed by the corresponding computational component during execution.

[0032] Furthermore, these extracted actions can then serve as the basis for selecting appropriate computational components and constructing the executable workflow required to achieve user-defined computational goals. That is, each action can correspond to a specific function necessary to achieve the computational goal. For example, appropriate computational components can be selected, where each component is chosen based on its input and output data formats, algorithm efficiency, and resource requirements matching the needs of the corresponding action. The selected computational components can be organized in a logical sequence such that the output of one computational component becomes a valid input to the next. During this process, dependencies, execution logic, and resource allocation between computational components can be automatically managed, resulting in a seamless data flow that achieves the computational goal without requiring manual integration.

[0033] For example, a computational component is a service category. The method further includes, for example, querying a service registry to identify one or more service categories that match the extracted action of the computation target. The service registry may be implemented as a structured database or directory that stores detailed descriptions of available service categories, including the functionality they provide, supported input and output formats, performance characteristics, and applicable constraints. In some examples, the query may involve searching the service registry for service categories whose claimed capabilities correspond to the extracted action, enabling the system to select the appropriate service category for each step of the workflow. For example, if the extracted action specifies "process payment," the service registry may return a list of payment processing service categories that support secure transactions and meet any defined policy requirements.

[0034] For example, the paper "Generating Executable Workflows from Solution Plans" by Khalfallah, Malik, et al. (2015 IEEE International Conference on Web Services (IEEE, 2015)) describes an implementation of execution workflow generation. This paper describes a framework for dynamically orchestrating containerized services in a distributed computing environment. Compute components are provided as containerized microservices exposing standard interfaces. User-defined intents are provided through semantic analysis or predefined templates, and then containerized compute components that match these intents are selected. Execution workflows are then generated by linking the compute components, ensuring data format conversion as necessary and proper management of execution order and resource allocation.

[0035] For example, a user-defined intent could specify a high-level computational objective such as "book a flight from Munich to Warsaw". The user-defined intent can be received as a structured JSON document, including fields such as "Departure_City": "Munich", "Destination_City": "Warsaw", "Departure_Date": "2025-06-15", "Return_Date": "2025-06-20", and "Maximum Price": "200 Euros". The generation of the execution workflow can include analysis of the user-defined intent, where the structured data in the JSON document is parsed to extract relevant parameters for the high-level computational objective. This analysis can map the high-level computational objective to a series of defined actions required to complete the booking, such as querying available flights, applying filtering criteria based on price and route preferences, processing payment, and generating a confirmation receipt. For example, the execution workflow could include computational components specifically chosen to perform the corresponding actions, where a flight search component receives parsed travel parameters as input in JSON format and outputs a list of flight options in XML format. A filtering component can receive an XML list of flights as input, apply sorting and filtering algorithms based on the user's maximum price and route preferences, and output a refined list of flight options in CSV format. The payment processing component accepts selected flight details as input in CSV format, performs secure payment authorization, and generates a payment confirmation in PDF format. Finally, the booking confirmation component compiles the finalized flight details and payment confirmation into a single PDF document, which is delivered to the user. Throughout the execution workflow, dependencies between calculation components are automatically managed, ensuring that the output format of each calculation component is compatible with the input format of subsequent calculation components.

[0036] In some examples, the execution workflow that generates the computational objective can be further based on the obtained execution constraints. For example, execution constraints can be parameters, conditions, or policies that define the operational boundaries within which the execution workflow is executed, ensuring that the execution of the computational objective conforms to specific quality, performance, and / or security requirements specified by user-defined intents or system configurations. Execution constraints can include, for example, Quality of Service (QoS) objectives, such as maximum latency, minimum throughput, or resource consumption limits. Execution constraints can be applied throughout the workflow to control and monitor the behavior of computational components, ensuring that the computational components remain compliant with these constraints, and can be enforced by the isolated execution environment itself or by a dedicated monitoring component operating within a trusted execution environment.

[0037] In some examples, the execution workflow that generates the computational objective can be further based on the obtained execution constraints. For example, execution constraints can define specific operational, performance, and security boundaries within which the workflow must execute to satisfy user-defined intents and system policies. Execution constraints can include, for example, Quality of Service (QoS) parameters or Service Level Agreement (SLA) conditions specifying mandatory thresholds, such as maximum allowable latency, minimum throughput, resource consumption limits (e.g., CPU, memory, or network usage), data privacy requirements, or other execution guarantees. These execution constraints can be integrated into the execution workflow in several ways: they can be statically embedded into the execution workflow during the generation of the user-defined intent, ensuring that the selected computational components and the overall workflow structure are consistent with the specified constraints; or they can be dynamically applied at runtime along with the input data, adjusting the execution behavior according to real-time conditions within the target environment.

[0038] For example, in the context of an execution workflow designed to handle reserved travel bookings, execution constraints may vary due to seasonal demand. During high-traffic periods such as Christmas, execution constraints might specify that services invoked within the workflow must handle at least 100 travel bookings per second to maintain the required service level. In contrast, during off-peak periods, execution constraints might reduce this requirement to 10 bookings per second, reflecting reduced demand. These constraints can be enforced throughout the execution of the workflow, where a monitoring component ensures that the computation component meets the defined performance level and triggers corrective actions (see below) if a violation is detected.

[0039] For example, when generating execution workflows, in addition to extracting actions for high-level computational goals, specific execution constraints can be defined to determine how the workflow must be executed. Execution constraints can influence the selection, arrangement, and configuration of computational components assembled into the execution workflow, ensuring that the overall workflow is optimized to meet requirements such as maximum allowable latency, resource usage limits, security policies, or availability guarantees. For instance, if execution constraints specify that the workflow must complete within a certain response time, the system can prioritize known computational components for efficient execution and reduced processing overhead, or it can structure the workflow to allow certain actions to be executed in parallel to meet timing requirements. In this way, execution workflows are not merely a series of actions to achieve computational goals, but are also influenced by execution constraints to ensure compliant, reliable, and optimized operation during runtime.

[0040] When executing instructions stored on a non-transitory computer-readable medium, the method performed by one or more processing circuitry systems 130 further includes executing an execution workflow according to obtained execution constraints. For example, the execution workflow is executed in a manner that satisfies technical limitations, operational limitations, and / or policy-related limitations specified by the execution constraints. Execution constraints may define requirements such as maximum permissible processing time, limits on resource consumption (including CPU, memory, and network bandwidth), or specific security and compliance rules (such as restricting the use of only authorized computing components or ensuring data processing within a protected environment). The execution workflow can be generated and constructed in a way that allows some or all of the execution constraints to be inherently considered during execution, for example, by selecting computing components with nominally compatible performance characteristics, arranging sequences of actions to optimize processing time, or ensuring that sensitive operations are handled by components that meet required security standards. Furthermore, compliance with execution constraints can be monitored during execution (see below).

[0041] The execution workflow is performed within an isolated execution environment. This isolated execution environment is deployed within a trusted execution environment (TEE). For example, an isolated execution environment can be a computing environment logically and / or operationally separate from the computing system, providing controlled code execution and data processing while limiting interaction with other processes, workloads, or users operating within the same target environment. An isolated execution environment ensures that the workflow's resources, storage, and execution context remain isolated from external systems, protecting execution from unauthorized access, unintentional interference, or data leakage. An isolated execution environment can provide defined boundaries within which the computing components executing the workflow are performed according to specified operational and security requirements, without being exposed to the rest of the computing system. In some examples, the isolated execution environment can be at least one of a virtual machine (VM), a container, or a software application. A VM can be a virtualized instance of a full operating system running on a hypervisor that emulates hardware resources, allowing the workflow to operate as if it were on a dedicated physical machine while remaining logically separate from other VMs and host systems. Containers can be lightweight virtualization mechanisms that package execution workflows with their necessary libraries, dependencies, and runtime environment, executing the workflow as an isolated process on a shared operating system kernel while preventing access to other containers and processes. Software applications can be specifically designed to encapsulate and execute execution workflows within a constrained and controlled user-space environment, using internal sandboxes, resource controls, or policy enforcement to prevent interaction with external systems beyond defined communication interfaces.

[0042] For example, a TEE can be a secure, hardware-supported computing environment that protects code and data during execution, ensuring they remain confidential and preventing unauthorized access or tampering, even from privileged software such as operating systems, hypervisors, or administrators. A trusted execution environment can establish a security boundary within the target environment (using hardware-based mechanisms to encrypt memory), verify the integrity of loaded code, and restrict access to internal state, thereby allowing sensitive workflows to execute securely on other, untrusted infrastructure. In some examples, a trusted execution environment can be at least one of Intel® Software Guard Extension (SGX) or Intel® Trust Domain Extension (TDX).

[0043] In this context, an isolated execution environment can execute within a trusted execution environment, meaning that the complete runtime of the isolated execution environment operates entirely within the security boundaries of the trusted execution environment. This can include the computational components of the workflow, their dependencies, and any dynamically loaded code. For example, this could include... Figure 5 The diagram shows the components of the speed controller, the controlled execution façade, the service quality monitor, the execution certificate authority, and / or the trusted service agent (see Figure 1). Figure 5 By executing an isolated execution environment within a trusted execution environment, the system ensures that the entire workflow, along with all intermediate data and execution state, benefits from the confidentiality and integrity protection provided by the hardware support of the trusted execution environment, while still maintaining the operational advantages of the modular, manageable execution structure offered by isolated execution environments such as virtual machines or containers. In other words, by executing an isolated execution environment within a trusted execution environment, it can be formally proven that a given workflow is executed in a “dominated” manner within the TEE via remote proof.

[0044] In some examples, the TEE can be deployed within a target environment (TE, also known as a computing system). For example, apparatus 100 can be a TE. An TE can be a monolithic computing system that provides the physical and virtual resources necessary to support the execution of workflows, including the infrastructure required to host the trusted execution environment and enable secure and reliable processing. An TE can include hardware resources, networking capabilities, storage systems, and runtime platforms that enable the deployment and operation of the trusted execution environment and the isolated execution environments contained within it. For example, an TE can be a cloud environment, such as a public or private cloud providing scalable computing resources; a local server infrastructure where dedicated servers within a controlled facility manage secure workload execution; or an edge computing environment where distributed and often resource-constrained devices process data closer to their source while still supporting secure execution capabilities.

[0045] In some examples, a TE can provide one or more instances of one or more compute components that may be needed to execute a workflow. Compute components can be available within the TE as deployable services, applications, or code modules. The system can select, configure, and execute these deployable services, applications, or code modules as part of achieving high-level compute goals defined by the user. The availability of compute components within the target environment may depend on the specific capabilities and resources of the environment, such as which services are pre-installed, which APIs are exposed, and which external systems are accessible—all of which influence how the workflow is composed and executed.

[0046] For example, a TE can be a broader computing system providing the underlying infrastructure, such as servers, networks, storage devices, and runtime platforms, where secure execution is required. Within the TE, a TEE can establish a hardware-supported secure zone that protects code and data from unauthorized access or tampering, even if the TE itself may not be fully trusted. The TEE can create a protected boundary within the TE, ensuring that sensitive computations are executed securely with confidentiality and integrity guaranteed. To execute complex workflows within this protected boundary, isolated execution environments (such as virtual machines, containers, or secure applications) can be deployed within the TEE to provide a structured and controlled space for the computing components used to execute the workflow. This architecture allows for explicit separation of responsibilities and layered protection: the TE provides general computing resources and connectivity; the TEE adds a secure foundation to prevent low-level attacks and ensure the trustworthiness of execution; and the isolated execution environment manages the actual execution of the workflow, allowing for modularity, flexibility, and dynamic component disposal. By running isolated execution environments within the TEE, the system combines the security guarantees of hardware-supported isolation with the operational advantages of a flexible, maintainable, and scalable execution runtime. This layered design supports dynamic, secure, and policy-compliant workflow execution, even in environments where some infrastructure or external services may not be fully trusted.

[0047] When executing instructions stored on a non-transitory computer-readable medium, the method performed by one or more processing circuitry systems 130 further includes monitoring the execution of an execution workflow within an isolated execution environment to ensure compliance with execution constraints. For example, monitoring the execution of an execution workflow within an isolated execution environment includes continuously observing, tracking, or inspecting the behavior of the execution workflow as it runs. It may further include collecting information about the status and performance of computing components, data flow between them, and the overall progress of the execution workflow. Monitoring may include measuring key operational metrics such as processing time, resource usage (including CPU, memory, and network consumption), service response time, or successful completion of individual actions. Monitoring may include detecting abnormal, failed, or unexpected behavior during execution.

[0048] Furthermore, compliance with execution constraints can be ensured by assessing whether the actual execution of the workflow adheres to the specific conditions and limitations defined by these constraints. This includes maintaining required performance levels, complying with resource limits, or using only authorized compute components. If monitoring detects a risk of violation or a violation of execution constraints, corrective actions can be triggered. For example, if a compute component is exceeding its maximum allowed response time or is calling an unauthorized service. Corrective actions may include terminating or restarting parts of the workflow, replacing compute components with alternative instances, reallocating resources, or even halting the entire execution if compliance cannot be restored. In this way, monitoring within an isolated execution environment enables the enforcement of constraints and helps maintain the integrity, reliability, and security of the workflow.

[0049] In some examples, when executing instructions stored on a non-transitory computer-readable medium, the method performed by one or more processing circuitry systems 130 may further include modifying the execution of the execution workflow according to an execution policy upon detecting a violation of execution constraints. For example, the execution policy may define predefined rules, conditions, and actions that determine how the system should respond when a violation of execution constraints is detected during workflow execution. The execution policy may specify acceptable operational boundaries, such as maximum resource usage, allowed service instances, or time limits for specific actions, and may specify how the system should handle violations of these constraints to maintain the safety, reliability, and correctness of the workflow. The execution policy may also define escalation procedures, rollback policies, or service replacement criteria to ensure that corrective actions are automatically applied within the TEE without external intervention. In some cases, the execution policy may be directly derived from user-defined intents, organizational guidelines, or regulatory compliance requirements, thereby ensuring that the workflow continues to operate within acceptable parameters.

[0050] For example, modifying the execution of a workflow when a violation of execution constraints is detected can involve dynamically replacing a poorly performing service instance with an alternative service instance that better satisfies the defined execution constraints, restarting a failing component, reallocating additional computational resources to critical actions, or skipping unimportant steps to meet a timed deadline. For instance, if an execution constraint specifies that a flight search operation must be completed within two seconds, and the currently selected service instance exceeds that threshold, the system can switch to a faster alternative service instance or narrow the search to fewer providers. Similarly, if a payment processing component fails to meet required security constraints, the system can automatically replace it with a verified secure instance. These modifications can occur in real-time during workflow execution to maintain compliance with execution constraints while ensuring that high-level computational goals are still achieved.

[0051] In some examples, the method executed by one or more processing circuitry systems 130 when executing instructions stored on a non-transitory computer-readable medium may further include dynamically selecting instances of one or more computing components based on execution constraints. The method may further include dynamically replacing non-compliant computing component instances to ensure compliance with execution constraints. For example, by dynamically selecting instances of one or more computing components based on execution constraints, during workflow execution, a specific implementation of the computing component that best satisfies the defined execution constraints (such as performance requirements, security requirements, or resource usage requirements) is selected. For example, instead of statically assigning component instances during workflow generation, the system can defer selection to runtime, evaluate available options within the TE, and select those that optimize compliance with execution constraints. For example, to ensure ongoing compliance, if a selected computing component instance becomes non-compliant, such as if its performance degrades, if it exceeds allowed resource consumption, or if it no longer meets security policies, the system can dynamically replace that computing component instance during execution. In such cases, it can seamlessly switch to an alternative, compliant instance of the computing component, ensuring the workflow continues to operate without violating the defined constraints.

[0052] For example, when the computation component is a service category, the system can dynamically select a specific service category instance from the available instances within the TE based on execution constraints. If the execution workflow requires an action such as "payment processing," and multiple service category instances exist for that action (such as payment service A or payment service B), the instance that best meets the current constraints can be selected, such as the fastest response time or the highest security level. During execution, if the selected "payment service A" begins to violate execution constraints, such as exceeding the maximum allowed response time or failing to meet the required security level, the system can dynamically replace it with a "payment service B" instance, which is evaluated to meet the constraints defined at that time. This dynamic selection and replacement allows the workflow to adapt in real time to maintain constraint compliance without interrupting the achievement of computational goals.

[0053] By ensuring that execution workflows are executed within an isolated execution environment deployed within the TEE, while continuously monitoring compliance with execution constraints, the technology described above allows for the secure and trustworthy execution of execution workflows dynamically assembled based on user-defined intents specifying high-level computational goals. This enables the automatic selection and replacement of instances of computational components (such as service class instances) during runtime in response to detected constraint violations, ensuring workflow compliance without human intervention. By providing this dynamic and policy-driven control over the execution of workflows in potentially untrusted target environments, this technology allows users to rely on the system to correctly and securely achieve their computational goals, while generating trusted evidence of execution, such as execution certificates (see below).

[0054] The techniques described above can further enable a shift from traditional static trusted execution models to dynamic, behavior-driven approaches. While traditional static trusted execution models focus on validating predefined code prior to execution, dynamic, behavior-driven approaches ensure adherence to user-defined intents throughout the runtime of the execution workflow. Instead of merely validating the integrity of fixed code, the techniques described above enable continuous assurance that actions performed within the execution workflow—including dynamically selected compute component instances, such as service class instances, or dynamically generated code within isolated execution environments—remain consistent with high-level compute objectives and execution constraints. By enabling the monitoring and enforcement of execution workflow behavior as it evolves during runtime, including modifications to execution paths and dynamic replacement of compute components, the techniques described above ensure that the achievement of compute objectives remains trustworthy and compliant with policies, even when specific implementations of the workflow change during execution. Input / Output

[0055] In some examples, the method performed by one or more processing circuitry systems 130 when executing instructions stored on a non-transitory computer-readable medium may further include:

[0056] Monitoring communication of input and / or output data between the isolated execution environment and external entities. For example, an external entity can be any system, service, or user outside the isolated execution environment that provides input data to or receives output data from the execution workflow. These external entities can include users who initiate workflow execution by supplying input data, third-party services invoked during execution, or endpoints that deliver the final results. Monitoring communication with external entities ensures that only authorized data enters or leaves the isolated execution environment, prevents the injection of malicious input, enforces confidentiality requirements, and prevents accidental data disclosure. This monitoring may involve validating the structure, type, and content of incoming data against predefined rules or patterns, and verifying that output data conforms to privacy or integrity constraints before being sent to its destination.

[0057] For example, when a user submits personal information as part of their input data to an execution workflow, monitoring can check whether the data format meets expected standards and whether sensitive fields contain valid values, thus rejecting malformed or potentially harmful input. Similarly, when a workflow is complete and ready to send output data (such as payment confirmation details), monitoring can verify that only necessary information is released, ensuring that internal status data or sensitive execution details are not unintentionally included.

[0058] In some examples, when executing instructions stored on a non-transitory computer-readable medium, the method performed by one or more processing circuitry systems 130 may further include receiving input data that can be utilized during the execution of the workflow. For example, receiving input data that can be utilized during the execution of the workflow may include accepting external data provided by a user, external system, or another process before or during the execution of the workflow, where such data may be necessary to perform computational goals defined by a user-defined intent. The input data may include any relevant parameters, resources, or content required by the computational components of the workflow, such as user credentials, configuration settings, or task-specific information. In this context, input data may be transferred from an external entity to an isolated execution environment via a controlled interface that applies monitoring and verification to ensure that the input data is secure, properly formatted, and conforms to applicable execution constraints before it is available to the workflow.

[0059] For example, if the workflow is designed to book a flight from Munich to Warsaw, the input data could include passenger details such as passport ID, travel dates, and payment information, all provided by the user or another system. Before this data is processed within the workflow, the system can check the input to confirm that the travel dates are valid, the payment information meets security standards, and the overall input does not contain any unexpected or harmful content. By receiving and validating input data in this controlled manner, the system can ensure that only compliant and trustworthy data is used during workflow execution, thereby reducing the risk of execution failures, security breaches, or violations of computational objectives.

[0060] In some examples, the method executed by one or more processing circuitry systems 130 when executing instructions stored on a non-transitory computer-readable medium may further include communicating with service class instances outside the isolated execution environment via a trusted agent. The trusted agent may be configured to enforce compliance with execution constraints. For example, the trusted agent may be a dedicated control component within the TEE or TE responsible for managing and overseeing all communication between the isolated execution environment and external entities, such as external service class instances. The trusted agent may act as a security intermediary, intercepting, inspecting, and regulating outgoing and incoming requests to ensure that only authorized, policy-compliant service class instances are invoked during workflow execution. The trusted agent may enforce compliance with execution constraints by verifying that the external service class instance meets predefined security criteria, operates within specified performance limits, or provides necessary proof (such as execution proof within the trusted execution environment). Additionally, the trusted agent may block, modify, or reroute communication that would otherwise violate execution constraints, thereby maintaining the integrity and trustworthiness of the execution workflow.

[0061] For example, during the execution of a workflow for booking a flight from Munich to Warsaw, the workflow might need to use an external payment processing service. Before allowing the execution workflow to send payment data to a selected payment service category instance, the trusted agent can check whether the selected instance is running within an approved trusted execution environment, whether it meets the required latency defined in the execution constraints, and whether the service has been properly authenticated. If the payment service instance fails any of these checks (e.g., if it does not provide the necessary security authentication or responds too slowly), the trusted agent may block the request and trigger the replacement of the service instance with a compliant alternative service instance, thereby ensuring that the execution workflow continues to operate according to the defined execution constraints. Execution Certificate

[0062] In some examples, the method executed by one or more processing circuitry systems 130 when executing instructions stored on a non-transitory computer-readable medium may further include generating an execution certificate. For example, the execution certificate may be a verifiable, tamper-proof, digitally signed data structure generated within the TEE that records and certifies key aspects of the execution of the workflow, providing trustworthy evidence that the workflow was executed according to user-defined intent and within defined execution constraints. The execution certificate may be automatically created by a dedicated component of the system during or after the execution of the workflow, responsible for monitoring execution, collecting telemetry and compliance data, and securely signing the certificate to ensure its authenticity and integrity. Once generated, the execution certificate may be provided to users or external dependents as part of the workflow output, such as along with the resulting data, and may be used for post-execution analysis, pay-as-you-go billing, service verification, or regulatory audits. In some examples, the execution certificate may be used for refunds in subscription models, for example, if upfront payment has been made and a refund is then requested in the event that no service has been provided or only partially provided. Execution certificates can provide the assurance that dynamically assembled and executed workflows (which may involve third-party service class instances and runtime service replacements) behave as expected, comply with policies, and are executed securely within a trusted execution environment.

[0063] Execution certificates may include at least one of the following: telemetry data of the execution of the execution workflow; compliance verification data based on monitoring of the execution according to execution constraints; integrity verification data of the execution within a trusted execution environment; and communication data of the isolated execution environment during the execution of the execution workflow. For example, telemetry data of the execution workflow may include detailed runtime records, such as timestamps, the sequence of actions performed, resource consumption, and any anomalies or failures encountered during execution, enabling analysis of how the workflow performs in practice. Compliance verification data can provide confirmation that the execution complies with execution constraints, including performance metrics (such as response time), security policies, and other service level objectives, as well as documented evidence of whether constraints are met or violated at each step of the workflow. Integrity verification data may include proof that the isolated execution environment is correctly executed within a TEE (such as Intel® SGX or Intel® TDX), and proof that the TEE is protected throughout the execution, thereby ensuring that the workflow is not tampered with and that sensitive data remains protected. Communication data can record all input and output exchanges between the isolated execution environment and external entities, including details of service class instances invoked during execution, the data transmitted, and whether these communications comply with applicable policies and execution constraints. In combination, these elements of the execution certificate can provide users or external auditors with a complete and trustworthy record of what was executed, how it was executed, and whether its obligations were fulfilled.

[0064] In some examples, when executing instructions stored on a non-transitory computer-readable medium, the method performed by one or more processing circuitry systems 130 may further include outputting the results and execution certificate of the executed workflow from an isolated execution environment after execution. For example, outputting the execution results and execution certificate of the executed workflow from an isolated execution environment after execution, upon completion of the workflow, includes providing the final results generated by the workflow (such as processed data, calculation results, or service confirmation) and the corresponding execution certificate, allowing the recipient not only to use the results but also to verify that the workflow was executed securely and conforms to defined execution constraints. When this output is transmitted from the isolated execution environment to a user or external system, the output can be monitored to ensure that both the results and the execution certificate are protected during transmission and reflect the integrity of the execution. For example, when executing a workflow for booking a flight from Munich to Warsaw, the result might be a flight reservation confirmation along with payment status, while the execution certificate provides cryptographically signed evidence that the workflow followed a specified policy, used authorized services, met service quality requirements, and was executed within a trusted execution environment, thus giving the user confidence in both the validity of the reservation and the credibility of the entire process.

[0065] In some examples, the method executed by one or more processing circuitry systems 130 when executing instructions stored on a non-transitory computer-readable medium may further include executing payments based on an execution certificate. For example, after an execution workflow is completed, the execution certificate can be used as a trusted basis to calculate and authorize financial transactions related to the use of services involved in the workflow. The execution certificate can provide a detailed, verifiable record of the services consumed, resources utilized, and execution constraints enforced during execution, enabling accurate billing in usage-based or pay-per-use models. This ensures that payment is made only for services actually performed in accordance with specified execution constraints, while also providing evidence in the event of disputes or audits. The execution certificate can capture which service class instances were used, their runtime duration, and whether any execution constraint violations occurred, making it suitable as a billing reference to be shared with service providers.

[0066] For example, if executing a workflow involves booking a flight from Munich to Warsaw and uses multiple third-party services (such as a payment processor, a flight booking API, and a customer notification service), an execution certificate can list the usage of each service, their execution time, and confirm whether they meet agreed execution constraints. Based on this certificate, the system can automatically calculate the total cost of the execution and trigger payments to the relevant service providers, such as payments for reserved route booking services, and compensate infrastructure providers for computation time, thereby ensuring transparent and verifiable billing.

[0067] In some examples, the method executed by one or more processing circuitry systems 130 when executing instructions stored on a non-transitory computer-readable medium may further include enforcing penalties based on an execution certificate. For example, if an execution certificate indicates that certain execution constraints have been violated (such as failure to meet guaranteed parameters such as maximum response time or availability), penalties may be automatically imposed on the responsible service provider or environment. This may involve calculating partial refunds, credits, or other compensation for the user based on the recorded violations documented within the execution certificate. In cases such as subscription-based service models, where the user has prepaid for a guaranteed service level, the execution certificate serves as verifiable evidence of non-compliance, enabling the system to enforce financial penalties without requiring manual dispute resolution.

[0068] For example, if a workflow execution is booked under a service level agreement that guarantees all external services will respond within 200 milliseconds, but the execution certificate shows that the payment processing service exceeded that threshold multiple times during the workflow, a proportional refund can be automatically applied to the user's account or an appropriate penalty can be deducted from the service provider's compensation. This ensures transparent and fair enforcement of the service level agreement, with the execution certificate serving as a trusted basis for triggering and calculating such penalties.

[0069] Further details and aspects are mentioned in conjunction with the examples described below. Figure 1 Examples shown may include those in conjunction with the proposed concept or those described below (e.g., Figures 2-5 One or more optional additional features corresponding to one or more aspects mentioned in one or more examples described.

[0070] Figure 2 The diagram illustrates a block diagram of an example of device 200 or apparatus 200. Device 200 includes a circuit system configured to provide the functions of device 200. For example, Figure 2 The second device 200 includes an interface circuit system 220, a processing circuit system 230, and (optionally) a storage circuit system 240. For example, the processing circuit system 230 may be coupled to the interface circuit system 220 and optionally to the storage circuit system 240.

[0071] For example, processing circuitry 230 may be configured to provide the functionality of device 200 in conjunction with interface circuitry 220. For example, interface circuitry 220 may be configured to exchange information, for example, with other components internal or external to device 200, and with storage circuitry 240. Similarly, device 200 may include means configured to provide the functionality of device 200.

[0072] The components of device 200 are defined as component devices that can correspond to or be implemented by corresponding structural components of device 200. For example, Figure 2 The device 200 includes: a processing means 230, which may correspond to or be implemented by a processing circuit system 230; a communication means 220, which may correspond to or be implemented by an interface circuit system 220; and (optionally) a storage means 240, which may correspond to or be implemented by a storage circuit system 240. In the following, the function of the device 200 is illustrated with respect to the device 200. Thus, the features described in connection with the device 200 are also applicable to the corresponding device 200.

[0073] Generally, the functionality of the processing circuitry system 230 or the processing apparatus 230 can be implemented by executing machine-readable instructions. Accordingly, any feature attributable to the processing circuitry system 230 or the processing apparatus 230 can be defined by one or more of a plurality of machine-readable instructions. The apparatus 200 or device 200 may include (e.g., within the storage circuitry system 240 or the information storage apparatus 240) machine-readable instructions.

[0074] The interface circuit system 220 or the communication device 220 may correspond to one or more inputs and / or outputs for receiving and / or transmitting information within a module, between modules, or between modules of different entities. This information may be in the form of digital (bit) values ​​based on specified codes. For example, the interface circuit system 220 or the communication device 220 may include circuitry configured to receive and / or transmit information.

[0075] For example, the processing circuitry system 230 or the processing device 230 may be implemented using one or more processing units, one or more processing devices, or any means of processing, such as a processor, computer, or programmable hardware component that can operate with correspondingly adapted software. In other words, the functionality of the described processing circuitry system 230 or the processing device 230 may also be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components may include general-purpose processors, digital signal processors (DSPs), microcontrollers, etc.

[0076] For example, storage circuitry 240 may include one or more components of non-transitory computer-readable medium 140. For example, storage circuitry 240 may store instructions that, when executed by processing circuitry 230, cause the processing circuitry 230 to perform a method. Storage circuitry 240 or means 240 for storing information may include at least one element of the group of computer-readable storage media, such as magnetic or optical storage media, such as hard disk drives, flash memory, floppy disks, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or network storage devices.

[0077] Processing circuitry system 230 is configured to receive user-defined intents specifying high-level computational goals. Processing circuitry system 230 is further configured to generate an execution workflow for the computational goals based on one or more computational components corresponding to the user-defined intents. Processing circuitry system 230 is further configured to execute the execution workflow according to obtained execution constraints. The execution workflow is executed within an isolated execution environment. This isolated execution environment is deployed within a trusted execution environment. Processing circuitry system 230 is further configured to monitor the execution of the execution workflow within the isolated execution environment to ensure compliance with execution constraints.

[0078] Further details and aspects are mentioned in conjunction with the examples described above or below. Figure 2 The examples shown may include those in conjunction with the proposed ideas or the preceding text (e.g., Figure 1 ) or the following text (e.g., Figures 3-5 One or more optional additional features corresponding to one or more aspects mentioned in one or more examples described.

[0079] Figure 3 The diagram illustrates a flowchart of an example of method 300. Method 300 can be performed by means such as means 100 or 200 as described herein. Method 300 can be performed by means 100 (e.g., one or more processing circuitry systems 130) when executing instructions stored on a non-transitory computer-readable medium (such as non-transitory computer-readable medium 140) as described herein. Method 300 includes receiving 310 a user-defined intent specifying a high-level computational objective. Method 300 includes further generating 320 an execution workflow for the computational objective based on one or more computational components corresponding to the user-defined intent. Method 300 includes further executing 330 the execution workflow according to obtained execution constraints. The execution workflow is executed within an isolated execution environment deployed within a trusted execution environment. Method 300 includes further monitoring 340 the execution of the execution workflow within the isolated execution environment to ensure compliance with the execution constraints.

[0080] Further details and aspects of method 300 are illustrated in conjunction with the proposed technique or one or more examples described above or below. Method 300 may include elements related to the proposed technique or the preceding (e.g., Figures 1-2 ) or the following text (e.g., Figures 4 to 5 One or more additional optional features corresponding to one or more aspects of one or more examples described. Further examples

[0081] Below Figure 4 and Figure 5 The example shown reflects the two phases of intent-based programming techniques as described above. First, in the setup phase 400 (see...) Figure 4 The solver component is responsible for translating user-defined intents into executable workflows (within a trusted execution container) encapsulated from examples. At runtime (phase 500), the trusted execution container is executed in the target environment. For example, the building blocks used by the solver could be web services provided by third-party service providers such as MSFT Azure or AWS. In other examples, they could be software libraries / executables / scripts that execute directly within the container.

[0082] For example, Figure 4 and Figure 5The components and units depicted herein can be understood for illustrative purposes and may represent logical entities, virtual entities, or physical entities. In some examples, the components and units may be implemented using software, hardware, or a combination thereof, and may be appropriately distributed across multiple systems, instances, or environments for a specific implementation.

[0083] Figure 4 The diagram illustrates an example of a setup phase 400 of a programming flow for user-defined intent programming. Setup phase 400 illustrates a flow for generating a trusted execution container 410, which is configured to securely execute a dynamically assembled execution workflow corresponding to user-defined intent 404. Setup phase 400 is divided into two separate parts: part 401A and part 401B.

[0084] In part 401A, user 402 provides a user-defined intent 404 specifying a high-level computational goal to be performed. The user-defined intent 404 can be expressed, for example, using a general, intent-driven programming language such as FAST (see Yang, Yao-Hsiang et al., “Language Support for Adaptation: Intent-Driven Programming in FAST” (arXiv preprint arXiv:1907.08695 (2019))). The user-defined intent 404 is passed to a trusted execution container builder 406, which analyzes the user-defined intent 404 to extract one or more actions of the computational goal and identify the corresponding computational components that may be needed to complete the computational goal. To this end, the trusted execution container builder 406 queries a semantic service registry 420, which stores descriptions of available computational components (such as service categories), including semantic information related to their functionality, input data types, output data types, and other relevant attributes. Based on this analysis, the trusted execution container builder 406 generates a trusted execution container 410 (also known as an isolated execution environment). The trusted execution container 410 includes an execution workflow 416 (also known as an execution plan), an executor 414, and a speed controller component 412. The executed workflow 416 can define the business logic required to achieve the computational goal by orchestrating identified computational components. As described in the paper "Generating Executable Workflows from SolutionPlans" by Khalfallah, Malik, et al., the execution workflow 416 can be generated, for example, in the form of an executable workflow. The executor 414 can execute the execution workflow 416 during runtime, and the speed controller component 412 can monitor execution and ensure compliance with execution constraints, as referenced... Figure 5 As described in further detail, the trusted execution container 410 is configured to operate within a trusted execution environment and can provide confidentiality, integrity, and remote attestation capabilities. The trusted execution container 410 is provided back to the user 402 for deployment in the target environment.

[0085] In part 401B, service provider 424 may publish descriptions of available services to service registry 422. These service descriptions can be defined using machine-readable knowledge representation languages ​​such as Web Ontology Language (OWL) (see the Semantic Web standard definition https: / / www.w3.org / 2001 / sw / #owl) which allow the use of ontology to semantically describe services and organize services in an inclusive hierarchy based on their functionality, input data types, output data types, and other relevant attributes. Service descriptions from service registry 422 can be provided to semantic service registry 420 to support the identification and selection of computational components during the generation execution workflow 416. The services described in service registry 422 may correspond to services available in target environment 426 (such as a cloud computing platform). Therefore, setup phase 400 enables the generation of trusted execution container 410, which encapsulates all elements necessary to securely execute the computational objective corresponding to user-defined intent 404 while ensuring formal assurance and compliance with execution constraints during runtime.

[0086] Figure 5 The diagram illustrates an example of runtime phase 500 of a programming flow for user-defined intent programming. Runtime phase 500 demonstrates how the generated trusted execution container securely executes a dynamically assembled execution workflow according to the user-defined intent, while ensuring formal guarantees, monitoring, and compliance with execution constraints. The trusted execution container 410 includes an execution workflow 416, an actuator 414, and a speed controller component 412.

[0087] Runtime phase 500 includes the following steps: In step 1, user 402 initiates execution of trusted execution container 410 within TEE 530 of the target environment (TE). User 402 provides input data and QoS quality requirements 504 (execution constraints) to trusted execution container 410. The input data and QoS requirements 504 are received and processed by a dominated execution facade 510 (e.g., a portion of regulator 412). The dominated execution facade 510 is configured to validate and filter the input data and QoS requirements 504 to prevent potentially harmful input or data that could compromise the integrity or confidentiality of the execution.

[0088] In step 2, the dominated execution appearance 510 provides the QoS requirements 504 specified by the user 402 to the QoS monitor 512 (e.g., part of the speed controller 412). These QoS requirements define the operational boundaries and objectives to be monitored and enforced during the execution of the execution workflow.

[0089] In step 3, the dominated execution facade 510 provides the executor 414 with verified input data along with QoS requirements 504 (if applicable). The executor 414 is configured to execute an execution workflow 416 embedded within the trusted execution container 410 and defining the business logic necessary to achieve the computational goals specified in the user-defined intent.

[0090] In step 4, executor 414 reads execution workflow 416 embedded within trusted execution container 410, which orchestrates a sequence of computational components required to complete the computational objective. Execution workflow 416 can describe the dependencies and interactions between computational components, as well as their respective input and output data formats.

[0091] In step 5, executor 414 queries service registry 518 via trusted service agent 516 (e.g., part of speed controller 412) to obtain available services required to perform execution workflow 416. Service registry 518 contains descriptions of service category instances deployed in target environment 520 (such as cloud services) that provide the functionality required to perform the workflow.

[0092] In step 6, executor 414 executes execution workflow 416 by invoking the identified service category instance through trusted service agent 516. Trusted service agent 516 acts as a control layer, enforcing external service interactions to comply with execution constraints. Trusted service agent 516 can check the compliance of selected service category instances, such as verifying whether they are part of a confidential computing offering, and can block non-compliant business.

[0093] In step 7, after successfully completing the execution workflow, executor 414 returns the execution result to the controlled execution facade 510. The controlled execution facade 510 can further validate and filter the output data to prevent unintentional data exposure before returning it to user 402.

[0094] In step 8, the execution certificate authority 514 (e.g., part of speed controller 412) retrieves telemetry data from a QoS monitor 512, which monitors the activity of the execution actuator 414 and the trusted service agent 516 throughout the execution process. This telemetry data may include information such as execution events, durations, service calls, anomalies, and compliance with QoS requirements.

[0095] In step 9, the execution certificate authority 514 generates an execution certificate 522 based on telemetry data and QoS requirements. The execution certificate 522 provides a trusted record of the execution, documenting which services were used, whether execution constraints were met, and capturing auditable logs of the execution process. The execution certificate 522 is returned to the controlled execution facade 510.

[0096] In step 10, the controlled execution facade 510 returns the execution result along with the execution certificate 522 to the user 402 as the final output of the execution workflow.

[0097] In step 11, user 402 may use execution certificate 522 for various post-execution purposes, such as payment calculation for billing system 526 using the payment mode, or requesting penalties or refunds from the service provider if a QoS violation is detected.

[0098] Further details and aspects are mentioned in conjunction with the examples described above. Figure 4 and Figure 5 The examples shown may include those in conjunction with the proposed ideas or the preceding text (e.g., Figures 1-3 One or more optional additional features corresponding to one or more aspects mentioned in one or more examples described.

[0099] The following text presents some examples of the proposed ideas:

[0100] Examples (e.g., Example 1) relate to a non-transitory computer-readable medium storing instructions that, when executed by one or more processing circuitry systems, cause the one or more processing circuitry systems to perform a method comprising: receiving a user-defined intent specifying a high-level computing objective; generating an execution workflow of the computing objective based on one or more computing components corresponding to the user-defined intent; executing the execution workflow according to obtained execution constraints, wherein the execution workflow is executed within an isolated execution environment deployed within a trusted execution environment; and monitoring the execution of the execution workflow within the isolated execution environment to ensure compliance with the execution constraints.

[0101] Another example (e.g., Example 2) relates to the foregoing example (e.g., Example 1) or any other example, and further includes: the method further includes: modifying the execution of the execution workflow when a violation of execution constraints is detected, based on the execution policy.

[0102] Another example (e.g., Example 3) relates to the foregoing examples (e.g., one of Examples 1 to 2) or any other example, and further includes: the method further includes dynamically selecting one or more instances of computing components based on execution constraints, and dynamically replacing non-compliant computing component instances to ensure compliance with execution constraints.

[0103] Another example (e.g., Example 4) relates to the foregoing examples (e.g., one of Examples 1 to 3) or any other example, further including: the computing component includes at least one of a service class, a script, dynamically compiled code, or an execution module.

[0104] Another example (e.g., Example 5) relates to the foregoing examples (e.g., one of Examples 1 to 4) or any other example, and further includes: the execution workflow for generating the computational target is further based on the obtained execution constraints.

[0105] Another example (e.g., Example 6) relates to the foregoing examples (e.g., one of Examples 1 to 5) or any other example, and further includes: the method further includes monitoring communication of input data and / or output data between the isolated execution environment and external entities.

[0106] Another example (e.g., Example 7) relates to the foregoing examples (e.g., one of Examples 1 to 6) or any other example, and further includes: the method further includes communicating with a service class instance outside the isolated execution environment via a trusted agent, the trusted agent being configured to enforce compliance with execution constraints.

[0107] Another example (e.g., Example 8) relates to the foregoing examples (e.g., one of Examples 1 to 7) or any other example, and further includes: the method further includes receiving input data utilized during the execution of the workflow.

[0108] Another example (e.g., Example 9) relates to the foregoing examples (e.g., one of Examples 1 to 8) or any other example, and further includes: the method further includes generating an execution certificate that includes at least one of the following: telemetry data of the execution of the execution workflow, compliance verification data based on monitoring the execution according to execution constraints, integrity verification data of the execution within a trusted execution environment, or communication data of an execution environment isolated during the execution of the execution workflow.

[0109] Another example (e.g., Example 10) relates to the foregoing example (e.g., Example 9) or any other example, and further includes: the method further includes outputting the execution results and execution certificate of the execution workflow from an isolated execution environment after execution.

[0110] Another example (e.g., Example 11) relates to the foregoing examples (e.g., one of Examples 9 to 10) or any other example, further including: the method further includes performing a payment based on an execution certificate.

[0111] Another example (e.g., Example 12) relates to the foregoing examples (e.g., one of Examples 9 to 11) or any other example, and further includes: the method further includes executing penalties based on the execution certificate.

[0112] Another example (e.g., Example 13) relates to the foregoing examples (e.g., one of Examples 1 to 12) or any other example, further including: a trusted execution environment deployed in a target environment that provides one or more instances of one or more computing components.

[0113] Another example (e.g., Example 14) relates to a previous example (e.g., Example 13) or any other example, further including: the target environment is at least one of a cloud environment, a local server infrastructure, or an edge computing environment.

[0114] Another example (e.g., Example 15) relates to the foregoing examples (e.g., one of Examples 1 to 14) or any other example, further including: the trusted execution environment is at least one of Intel® Software Protection Extension (SGX) or Intel® Trust Domain Extension (TDX).

[0115] Another example (e.g., Example 16) relates to the foregoing examples (e.g., one of Examples 1 to 15) or any other example, further including: the isolated execution environment is at least one of a virtual machine, a container, or a software application.

[0116] Another example (e.g., Example 17) relates to the foregoing examples (e.g., one of Examples 1 to 16) or any other example, further including: the received user-defined intent includes one or more actions of calculating the target.

[0117] Another example (e.g., Example 18) relates to the foregoing examples (e.g., one of Examples 1 to 17) or any other example, and further includes: the method further includes parsing the received intent to extract one or more actions of the computational target.

[0118] Another example (e.g., Example 19) relates to the foregoing examples (e.g., one of Examples 1 to 18) or any other example, and further includes: the method further includes querying a service registry to identify one or more service categories that match the extracted action of the computation target.

[0119] Examples (e.g., Example 20) relate to an apparatus including an interface circuitry, machine-readable instructions, and a processing circuitry for executing the machine-readable instructions to: receive a user-defined intent specifying a high-level computational objective; generate an execution workflow for the computational objective based on one or more computational components corresponding to the user-defined intent; execute the execution workflow according to obtained execution constraints, wherein the execution workflow is executed within an isolated execution environment deployed within a trusted execution environment; and monitor the execution of the execution workflow within the isolated execution environment to ensure compliance with the execution constraints.

[0120] Another example (e.g., Example 21) relates to the foregoing example (e.g., Example 20) or any other example, and further includes: the processing circuitry system is further configured to execute machine-readable instructions to modify the execution of the execution workflow when a violation of execution constraints is detected, according to the execution policy.

[0121] Another example (e.g., Example 22) relates to the foregoing examples (e.g., one of Examples 20 to 21) or any other example, and further includes: the processing circuitry system is further configured to execute machine-readable instructions to: dynamically select instances of one or more computing components based on execution constraints; and dynamically replace non-compliant instances of computing components to ensure compliance with execution constraints.

[0122] Another example (e.g., Example 23) relates to the foregoing examples (e.g., one of Examples 20 to 22) or any other example, further including: the computing component includes at least one of a service class, a script, dynamically compiled code, or an execution module.

[0123] Another example (e.g., Example 24) relates to the foregoing examples (e.g., one of Examples 20 to 23) or any other example, and further includes: the processing circuitry system is further configured to execute machine-readable instructions to generate an execution workflow for a computational target based on the obtained execution constraints.

[0124] Another example (e.g., Example 25) relates to the foregoing examples (e.g., one of Examples 20 to 24) or any other example, further including: the processing circuitry system is further configured to execute machine-readable instructions to: monitor communication of input and / or output data between the isolated execution environment and an external entity.

[0125] Another example (e.g., Example 26) relates to the foregoing examples (e.g., one of Examples 20 to 25) or any other example, further including: the processing circuitry system is further configured to execute machine-readable instructions to perform the following: communicate with a service class instance outside the isolated execution environment via a trusted agent, the trusted agent being configured to enforce compliance with execution constraints.

[0126] Another example (e.g., Example 27) relates to the foregoing examples (e.g., one of Examples 20 to 26) or any other example, and further includes: the processing circuitry system is further configured to execute machine-readable instructions to: receive input data utilized during the execution of the workflow.

[0127] Another example (e.g., Example 28) relates to the foregoing examples (e.g., one of Examples 20 to 27) or any other example, further comprising: the processing circuitry system is further configured to execute machine-readable instructions to: generate an execution certificate that includes at least one of the following: telemetry data of the execution of the execution workflow, compliance verification data based on monitoring of the execution according to execution constraints, integrity verification data of the execution within a trusted execution environment, or communication data of an execution environment isolated during the execution of the execution workflow.

[0128] Another example (e.g., Example 29) relates to the foregoing example (e.g., Example 28) or any other example, and further includes: the processing circuitry system is further configured to execute machine-readable instructions to perform the following operation: outputting the execution results and execution certificate of the execution workflow from an isolated execution environment after execution.

[0129] Another example (e.g., example 30) relates to the foregoing examples (e.g., one of examples 28 to 29) or any other example, and further includes: the processing circuitry system is further configured to execute machine-readable instructions to perform the following operation: to execute a payment based on an execution certificate.

[0130] Another example (e.g., example 31) relates to the foregoing examples (e.g., one of examples 28 to 30) or any other example, further including: the processing circuitry system is further configured to execute machine-readable instructions to perform the following operation: to execute a penalty based on an execution certificate.

[0131] Another example (e.g., Example 32) relates to the foregoing examples (e.g., any one of Examples 20 to 31) or any other example, and further includes: a trusted execution environment deployed in a target environment that provides one or more instances of one or more computing components.

[0132] Another example (e.g., Example 33) relates to a previous example (e.g., Example 32) or any other example, further including: the target environment is at least one of a cloud environment, a local server infrastructure, or an edge computing environment.

[0133] Another example (e.g., example 34) relates to the foregoing examples (e.g., one of examples 20 to 33) or any other example, further including: the trusted execution environment is at least one of Intel® Software Protection Extension (SGX) or Intel® Trust Domain Extension (TDX).

[0134] Another example (e.g., Example 35) relates to the foregoing examples (e.g., one of Examples 20 to 34) or any other example, further including: the isolated execution environment is at least one of a virtual machine, a container, or a software application.

[0135] Another example (e.g., Example 36) relates to the foregoing examples (e.g., one of Examples 20 to 35) or any other example, further including: the received user-defined intent includes one or more actions of calculating the target.

[0136] Another example (e.g., example 37) relates to the foregoing examples (e.g., one of examples 20 to 36) or any other example, further including: the processing circuitry system is further configured to execute machine-readable instructions to: parse the received intent to extract one or more actions of the computational target.

[0137] Another example (e.g., example 38) relates to the foregoing examples (e.g., one of examples 20 to 37) or any other example, further including: the processing circuitry system is further configured to execute machine-readable instructions to: query a service registry to identify one or more service categories that match the extracted action of the computation target.

[0138] Examples (e.g., Example 39) relate to a method comprising: receiving a user-defined intent specifying an advanced computational objective; generating an execution workflow for the computational objective based on one or more computational components corresponding to the user-defined intent; executing the execution workflow according to obtained execution constraints, wherein the execution workflow is executed within an isolated execution environment deployed within a trusted execution environment; and monitoring the execution of the execution workflow within the isolated execution environment to ensure compliance with the execution constraints.

[0139] Another example (e.g., Example 40) relates to the foregoing example (e.g., Example 39) or any other example, and further includes: modifying the execution of the execution workflow when a violation of execution constraints is detected, based on the execution policy.

[0140] Another example (e.g., Example 41) relates to the foregoing examples (e.g., one of Examples 39 to 40) or any other example, and further includes: dynamically selecting instances of one or more computing components based on execution constraints; dynamically replacing non-compliant computing component instances to ensure compliance with execution constraints.

[0141] Another example (e.g., example 42) relates to the foregoing examples (e.g., one of examples 39 to 41) or any other example, further including: the computing component includes at least one of a service class, a script, dynamically compiled code, or an execution module.

[0142] Another example (e.g., example 43) relates to the foregoing examples (e.g., any one of examples 39 to 42) or any other example, and further includes: the execution workflow for generating the computational target is further based on the obtained execution constraints.

[0143] Another example (e.g., example 44) relates to the foregoing examples (e.g., one of examples 39 to 43) or any other example, and further includes: monitoring communication of input and / or output data between the isolated execution environment and external entities.

[0144] Another example (e.g., example 45) relates to the foregoing examples (e.g., one of examples 39 to 44) or any other example, and further includes: communicating with a service class instance outside an isolated execution environment via a trusted agent, the trusted agent being configured to enforce compliance with execution constraints.

[0145] Another example (e.g., example 46) relates to the foregoing examples (e.g., one of examples 39 to 45) or any other example, and further includes: receiving input data utilized during the execution of the workflow.

[0146] Another example (e.g., Example 47) relates to the foregoing examples (e.g., one of Examples 39 to 46) or any other example, and further includes: generating an execution certificate that includes at least one of the following: telemetry data of the execution of the execution workflow, compliance verification data based on monitoring of the execution according to execution constraints, integrity verification data of the execution within a trusted execution environment, or communication data of an execution environment isolated during the execution of the execution workflow.

[0147] Another example (e.g., example 48) relates to the foregoing examples (e.g., one of examples 40 to 47) or any other example, and further includes: outputting the execution results and execution certificate of the execution workflow from an isolated execution environment after execution.

[0148] Another example (e.g., example 49) relates to the foregoing examples (e.g., one of examples 47 to 48) or any other example, further including: performing payments based on an execution certificate.

[0149] Another example (e.g., example 50) relates to the aforementioned examples (e.g., one of examples 47 to 49) or any other example, further including: enforcing penalties based on execution certificates.

[0150] Another example (e.g., Example 51) relates to the foregoing examples (e.g., any one of Examples 39 to 50) or any other example, further including: a trusted execution environment deployed in a target environment that provides one or more instances of one or more computing components.

[0151] Another example (e.g., example 52) relates to a previous example (e.g., example 51) or any other example, further including: the target environment is at least one of a cloud environment, a local server infrastructure, or an edge computing environment.

[0152] Another example (e.g., Example 53) relates to the foregoing examples (e.g., one of Examples 39 to 52) or any other example, further including: the trusted execution environment is at least one of Intel® Software Protection Extension (SGX) or Intel® Trust Domain Extension (TDX).

[0153] Another example (e.g., example 54) relates to the foregoing examples (e.g., one of examples 39 to 53) or any other example, further including: the isolated execution environment is at least one of a virtual machine, a container, or a software application.

[0154] Another example (e.g., Example 55) relates to the foregoing examples (e.g., one of Examples 39 to 54) or any other example, further including: the received user-defined intent includes one or more actions of calculating the target.

[0155] Another example (e.g., example 56) relates to the foregoing examples (e.g., one of examples 39 to 55) or any other example, and further includes: parsing the received intent to extract one or more actions of the computational target.

[0156] Another example (e.g., example 57) relates to the foregoing examples (e.g., one of examples 39 to 56) or any other example, and further includes: querying a service registry to identify one or more service categories that match the extracted action of the computation target.

[0157] Examples (e.g., Example 58) relate to an apparatus including a processor circuitry configured to: receive a user-defined intent specifying an advanced computational objective; generate an execution workflow for the computational objective based on one or more computational components corresponding to the user-defined intent; execute the execution workflow according to obtained execution constraints, wherein the execution workflow is executed within an isolated execution environment deployed within a trusted execution environment; and monitor the execution of the execution workflow within the isolated execution environment to ensure compliance with the execution constraints.

[0158] Examples (e.g., Example 59) relate to an apparatus including means for processing, the means for processing being configured to: receive a user-defined intent specifying an advanced computational objective; generate an execution workflow for the computational objective based on one or more computational components corresponding to the user-defined intent; execute the execution workflow according to obtained execution constraints, wherein the execution workflow is executed within an isolated execution environment deployed within a trusted execution environment; and monitor the execution of the execution workflow within the isolated execution environment to ensure compliance with the execution constraints.

[0159] Another example (e.g., Example 60) relates to a computer program having program code for performing any of the methods in Examples 39 to 57 when the computer program is executed on a computer, processor, or programmable hardware component.

[0160] Another example (e.g., Example 61) relates to a machine-readable storage device that includes machine-readable instructions that, when executed, are used to implement a method as claimed in any pending example, or to implement means as claimed in any pending example.

[0161] The aspects and features described in relation to a particular example in the foregoing examples may also be combined with one or more of the further examples to replace the same or similar features of the further examples or to additionally introduce these features into the further examples.

[0162] The examples may further be or relate to (computer) programs that include program code for performing one or more of the methods described above when the program is executed on a computer, processor, or other programmable hardware component. Thus, the steps, operations, or processes of the different methods described above can also be performed by a programmed computer, processor, or other programmable hardware component. The examples may also cover program storage devices, such as digital data storage media, that are machine-readable, processor-readable, or computer-readable and encode and / or contain machine-executable, processor-executable, or computer-executable programs and instructions. For example, a program storage device may include or be a digital storage device, magnetic storage media (such as disks and tapes), hard disk drives, or optically readable digital data storage media. Other examples may include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPUs), application-specific integrated circuits (ASICs), integrated circuits (ICs), or system-on-a-chip (SoC) systems programmed to perform the steps of the methods described above.

[0163] It should be further understood that the disclosure of certain steps, processes, operations, or functions in the specification or claims should not be construed as implying that these operations must necessarily be performed in the described order, unless explicitly stated in a separate use case or necessary for technical reasons. Therefore, the preceding description does not limit the execution of certain steps or functions to a particular order. Furthermore, in further examples, a single step, function, process, or operation may include and / or be decomposed into several sub-steps, sub-functions, sub-processes, or sub-operations.

[0164] If aspects have been described in conjunction with an equipment or system, then those aspects should also be understood as descriptions of the corresponding method. For example, a block, device, or functional aspect of an equipment or system may correspond to a characteristic (such as method steps) of the corresponding method. Accordingly, aspects described in conjunction with the method should also be understood as descriptions of the attributes or functional characteristics of the corresponding block, element, equipment, or system.

[0165] As used herein, the term "module" refers to logic that can be implemented using hardware components or devices, software or firmware running on a processing unit, or a combination thereof, for performing one or more operations conforming to this disclosure. Software and firmware can be embodied as instructions and / or data stored on a non-transitory computer-readable storage medium. As used herein, the term "circuit system" can individually or in any combination include non-programmable (hardwired) circuit systems, programmable circuit systems (such as processing units), state machine circuit systems, and / or firmware storing instructions executable by programmable circuit systems. Modules described herein can be embodied collectively or individually as circuit systems forming part of a computing system. Thus, any of the modules can be implemented as a circuit system. A computing system described as being programmed to perform a method can be programmed to perform that method via software, hardware, firmware, or a combination thereof.

[0166] Any method (or part thereof) disclosed herein may be implemented as computer-executable instructions or a computer program product. Such instructions may cause a computing system or one or more processing units capable of executing computer-executable instructions to perform any method disclosed herein. As used herein, the term "computer" means any computing system or device described or mentioned herein. Thus, the term "computer-executable instructions" means instructions executable by any computing system or device described or mentioned herein.

[0167] Computer-executable instructions can be part of, for example, the operating system of a computing system, an application stored locally on the computing system, or a remote application accessible to the computing system (e.g., via a web browser). Any of the methods described herein can be executed by computer-executable instructions, which may be executed by a single computing system or by one or more networked computing systems operating in a network environment. Computer-executable instructions and updates to them may be downloaded to the computing system from a remote server.

[0168] Furthermore, it should be understood that the implementation of the disclosed technology is not limited to any particular computer language or program. For example, the disclosed technology can be implemented by software written in C++, C#, Java, Perl, Python, JavaScript, Adobe Flash, C#, assembly language, or any other programming language. Similarly, the disclosed technology is not limited to any particular computer system or any particular type of hardware.

[0169] Furthermore, any example of the software-based examples (including, for example, computer-executable instructions for causing a computer to perform any of the methods disclosed) can be uploaded, downloaded, or remotely accessed by suitable means of communication. Such suitable means of communication include, for example, the Internet, the World Wide Web, intranets, cables (including fiber optic cables), magnetic communication, electromagnetic communication (including RF, microwave, ultrasonic, and infrared communication), electronic communication, or other such means of communication.

[0170] The disclosed methods, apparatuses, and systems should not be construed as limiting in any way. Instead, this disclosure addresses, individually and in various combinations and sub-combinations with each other, all novel and non-obvious features and aspects of the respective disclosed examples. The disclosed methods, apparatuses, and systems are neither limited to any particular aspect or feature or combination thereof, nor are the disclosed examples required to provide any one or more particular advantages or to solve any one or more particular problems.

[0171] The operational theories, scientific principles, or other theoretical descriptions of the apparatuses or methods described herein are provided for the purpose of better understanding and are not intended to limit the scope. The apparatuses and methods in the appended claims are not limited to those that operate in a manner described by such operational theories.

[0172] The appended claims are thus included in the detailed description, wherein each claim may be considered an individual example. It should also be noted that while a dependent claim in the claims statement refers to a specific combination with one or more other claims, other examples may also include combinations of the subject matter of that dependent claim with any other dependent or independent claim. Such combinations are expressly stated herein unless, in individual cases, it is stated that a particular combination was not contemplated. Furthermore, even if a claim is not directly limited to referencing any other independent claim, the features of that claim should be included with respect to that other independent claim.

Claims

1. An apparatus comprising an interface circuit system, machine-readable instructions, and a processing circuit system, the processing circuit system being configured to execute the machine-readable instructions to perform the following operations: Receive user-defined intents that specify advanced computing objectives; An execution workflow for the computational objective is generated based on one or more computational components corresponding to the user-defined intent. Execute the execution workflow according to the obtained execution constraints; The execution workflow is executed within an isolated execution environment, which is deployed within a trusted execution environment. Monitor the execution of the execution workflow within the isolated execution environment to ensure compliance with the execution constraints.

2. The apparatus of claim 1, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operation: modifying the execution workflow when a violation of execution constraints is detected, according to the execution policy.

3. The apparatus of claim 1, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operations: Instances of one or more computing components are dynamically selected based on the execution constraints; Non-compliant compute component instances are dynamically replaced to ensure compliance with the execution constraints.

4. The apparatus of claim 1, wherein, The computing component includes at least one of a service category, a script, dynamically compiled code, or an execution module.

5. The apparatus of claim 1, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operations: generating the execution workflow of the computational target based on the obtained execution constraints.

6. The apparatus of claim 1, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operations: monitor communication of input and / or output data between the isolated execution environment and external entities.

7. The apparatus of claim 1, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operations: communicating with a service class instance outside the isolated execution environment via a trusted agent, the trusted agent being configured to enforce compliance with the execution constraints.

8. The apparatus of claim 1, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operations: receiving input data utilized during the execution of the execution workflow.

9. The apparatus of claim 1, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operations: generate an execution certificate, the execution certificate including at least one of the following: telemetry data of the execution of the execution workflow, compliance verification data based on monitoring the execution according to the execution constraints, integrity verification data of the execution within the trusted execution environment, or communication data of the isolated execution environment during the execution of the execution workflow.

10. The apparatus of claim 9, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operations: after execution, outputting the execution result of the execution workflow and the execution certificate from the isolated execution environment.

11. The apparatus of claim 9, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operation: to execute a payment based on the execution certificate.

12. The apparatus of claim 9, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operation: to impose a penalty based on the execution certificate.

13. The apparatus of claim 1, wherein, The trusted execution environment is deployed in the target environment, which provides one or more instances of the one or more computing components.

14. The apparatus of claim 13, wherein, The target environment is at least one of a cloud environment, a local server infrastructure, or an edge computing environment.

15. The apparatus of claim 1, wherein, The trusted execution environment is at least one of Software Protection Extension (SGX) or Trust Domain Extension (TDX).

16. The apparatus of claim 1, wherein, The isolated execution environment is at least one of a virtual machine, a container, or a software application.

17. The apparatus of claim 1, wherein, The received user-defined intent includes one or more actions of the computation target.

18. The apparatus of claim 1, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operations: parse the received intent to extract one or more actions of the computational target.

19. The apparatus of claim 1, wherein, The processing circuitry is further configured to execute the machine-readable instructions to perform the following operations: query the service registry to identify one or more service categories that match the extracted action of the computation target.

20. A non-transitory computer-readable medium storing instructions, said instructions, when executed by one or more processing circuitry systems, causing said one or more processing circuitry systems to perform a method comprising: Receive user-defined intents that specify advanced computing objectives; An execution workflow for the computational objective is generated based on one or more computational components corresponding to the user-defined intent. Execute the execution workflow according to the obtained execution constraints; The execution workflow is executed within an isolated execution environment, which is deployed within a trusted execution environment. Monitor the execution of the execution workflow within the isolated execution environment to ensure compliance with the execution constraints.

21. The computer-readable medium of claim 20, wherein, The method further includes: modifying the execution of the execution workflow when a violation of execution constraints is detected, according to the execution policy.

22. The computer-readable medium of claim 20, wherein, The method further includes: dynamically selecting instances of the one or more computing components based on the execution constraints; Non-compliant compute component instances are dynamically replaced to ensure compliance with the execution constraints.

23. A method comprising: Receive user-defined intents that specify advanced computing objectives; An execution workflow for the computational objective is generated based on one or more computational components corresponding to the user-defined intent. The execution workflow is executed based on the obtained execution constraints; The execution workflow is executed within an isolated execution environment, which is deployed within a trusted execution environment. Monitor the execution of the execution workflow within the isolated execution environment to ensure compliance with the execution constraints.

24. The method of claim 23, further comprising: According to the execution policy, the execution of the execution workflow is modified when a violation of execution constraints is detected.

25. A computer program product having program code for performing the method as described in any one of claims 23 to 24 when the computer program is executed on a computer, processor, or programmable hardware component.

Images