Securing LLM-Integrated Apps with Abstract-Concrete-Execute Architecture

The core of the ACE architecture is the separation of the planning phase into two distinct steps. First, a specialized LLM generates an abstract execution plan based solely on the user query and trusted system information. This abstract plan uses a restricted subset of Python to define the logic, preventing the LLM from generating arbitrary or malicious control flows.

By establishing this abstract boundary, the system creates a hard constraint on possible execution traces. This prevents the system from being tricked by malicious app descriptions or unexpected outputs that might otherwise alter the intended logic.

Once the abstract plan is generated, the system maps it to concrete, installed apps. This process uses similarity scores between abstract and concrete app descriptions to find valid matches. A compatibility layer resolves type discrepancies, ensuring that the concrete implementation aligns with the abstract requirements.

Before execution, the concrete plan undergoes static verification against security policies. The system models information flow as a bounded lattice, rejecting any plan that violates defined privilege or data access rules. If no secure assignment exists, the system terminates, preventing the execution of potentially compromised logic.

The final execution phase follows an orchestrator-worker architecture. The orchestrator manages resource allocation and enforces strict privilege boundaries. Each app runs within an isolated runtime environment, and communication between components is restricted to well-defined network sockets.

This isolation ensures that even if a single app is compromised, it cannot access data or capabilities outside its assigned scope. By enforcing these barriers, ACE maintains the integrity of the entire system, even when interacting with third-party tools.

Sources