ARPaCCino: Automated Policy-as-Code System

• ARPaCCino is an agentic system that automates the transformation of natural language policies into formal, machine-enforceable Rego rules for IaC compliance.
• It integrates LLMs, Retrieval-Augmented Generation, and tool-based validation in a modular architecture to iteratively refine and verify policy accuracy.
• ARPaCCino improves syntactic and semantic correctness in policy generation and extends to various IaC frameworks, enhancing overall compliance.

ARPaCCino is an agentic system designed to automate generation and compliance verification of Policy as Code (PaC) artifacts in Infrastructure as Code (IaC) environments. It integrates LLMs, Retrieval-Augmented Generation (RAG), and tool-based validation within a modular architecture, facilitating the transformation of natural language policy descriptions into formal, machine-enforceable representations. ARPaCCino’s design addresses the challenges posed by the complexity of policy languages and the high risk of misconfiguration inherent in PaC adoption, providing an extensible framework supporting policy validation across a diverse array of IaC technologies (Romeo et al., 11 Jul 2025).

1. System Architecture and Agentic Composition

ARPaCCino adopts an agentic RAG structure wherein a central LLM-based “reasoning engine” orchestrates a series of specialized agents in a coordinated iterative workflow. The architecture comprises the following principal components:

• Core LLM Engine Maintains conversational context, receives user input (natural language policies and IaC files), and delegates tasks to downstream agents.
• RAG Tool (Retrieval Agent) Provides domain-specific knowledge retrieval from an embedded corpus containing documentation such as Open Policy Agent (OPA) references, Rego specifications, and provider manuals. It processes free-text queries and returns top-ranked, contextually relevant passages.
• Infrastructure Tools (Pre-processors) Framework-specific parsers and converters (e.g., for Terraform: terraform plan –out=plan.json) generate structured output (such as plan JSON) suitable for compliance assessment.
• Rule Checker Tool (Semantic Validator Agent) Invokes an external oracle (human or automated) for validating the syntactic and semantic correctness of generated Rego rules, returning a binary accept/reject verdict.
• Policy Validation Tool (Compliance Agent) Applies the verified Rego rules against the IaC plan using OPA or a similar engine, reporting compliance status and policy violations.

Agents communicate in an iterative loop in which the system autonomously refines policy rules or IaC configurations until conformance is achieved (Romeo et al., 11 Jul 2025).

2. Retrieval-Augmented Generation (RAG) Pipeline

The RAG Tool underpins ARPaCCino’s contextual inference by embedding retrieval into the generation process. The pipeline operates as follows:

• Offline Indexing: The knowledge corpus is segmented into ~200-token chunks, each transformed into an embedding vector $e_i = \mathrm{Embed}(d_i)$.
• Query-Time Retrieval: When the LLM issues a query $q$, the retriever computes $e_q = \mathrm{Embed}(q)$, calculates cosine similarity

$$\mathrm{score}(q,d_i) = \frac{e_q \cdot e_i}{\|e_q\| \;\|e_i\|},$$

and retrieves the top-%%%%4%%%% relevant chunks $\{d_{i_1},...,d_{i_k}\}$.

The LLM then prepends these retrieved passages to its generation prompt, allowing for context-rich code synthesis or explanation. Because the RAG Tool operates as an agent, the LLM determines invocation dynamically within the reasoning loop (Romeo et al., 11 Jul 2025).

3. Formal Policy Generation

ARPaCCino formalizes natural language policy specifications into Rego policies through a structured prompt-engineering sequence:

• The LLM fetches relevant documentation and examples from the RAG Tool.
• Constructs a composite prompt comprising retrieved context and an explicit instruction to generate a Rego deny[msg] rule, with requirements for package declaration and violation messages.
• The LLM outputs a syntactically and semantically structured Rego policy.

Example

Natural language input: “Allow only virtual machines with 4 cores in Terraform.” Generated Rego:

package terraform deny[msg] { resource := input.planned_values.root_module.resources[_].values cpu := resource.cpu[_].cores cpu != 4 msg := "VM must have exactly 4 cores" }

This cycle yields policies ready for validation by downstream agents (Romeo et al., 11 Jul 2025).

4. Compliance Assessment and Iterative Correction

Policy enforcement and infrastructure repair are realized through an agentic refinement loop, described by the following algorithmic structure:

Input: IaC_file.tf, NL_policies Output: Verified_IaC.tf, Generated_Rego.rego opa_know ← RAG_tool.query("OPA + Rego reference") rego_rules ← GenerateRegoPolicy(NL_policies) ok ← RuleCheckerTool.verify(rego_rules) if not ok: goto POLICY GENERATION # Refine Rego plan.json ← TerraformTool.preprocess(IaC_file.tf) compliant, violations ← PolicyValidationTool.check(plan.json, rego_rules) if not compliant: tf_know ← RAG_tool.query("Terraform ProxMox provider examples") IaC_file.tf ← LLM.apply_corrections(IaC_file.tf, violations, tf_know) goto INFRASTRUCTURE VALIDATION # Re-validate return IaC_file.tf, rego_rules

The system iteratively alternates between refining policies and updating IaC files, repeatedly invoking agents as needed until all policy conditions are satisfied, or an iteration cap is reached (Romeo et al., 11 Jul 2025).

5. Framework Extensibility and Technology Coverage

Although experimentally evaluated on Terraform with the ProxMox provider, ARPaCCino’s modular pipeline supports integration with arbitrary IaC frameworks under two conditions:

• Existence of a preprocessing agent capable of outputting a structured plan (e.g., JSON).
• Inclusion of framework-specific documentation in the RAG knowledge base.

Consequently, ARPaCCino can be extended to work with Ansible, Pulumi, CloudFormation, Kubernetes YAML, or any emerging IaC tool provided the above are satisfied. The RAG Tool’s knowledge retrieval capability enables the LLM to propose valid corrections in the respective domain-specific languages (Romeo et al., 11 Jul 2025).

6. Evaluation and Empirical Results

A case study with a fixed Terraform configuration and five benchmark policies demonstrates the comparative performance of LLM-only, LLM+RAG, and Agentic RAG settings with three models: Qwen3 30B (open), GPT-4o (closed), and Claude Sonnet 4 (closed). Metrics encompass:

• Syntax: Number of policies passing OPA syntax check.
• Semantics: Number fulfilling policy intent.
• Detection: Ability to flag actual violations.
• Repair: Success at fixing non-compliant infrastructure.

Key Experimental Results

Model	Setting	Syntax/Semantics (out of 5)
Qwen3 30B	LLM-only/RAG	0 / 0
Qwen3 30B	Agentic RAG	4 / 4
GPT-4o	LLM-only/RAG	0 / 0
GPT-4o	Agentic RAG	5 / 5
Claude Sonnet 4	LLM-only	5 / 5
Claude Sonnet 4	Agentic RAG	5 / 5

Efficiency Metrics (Averaged Calls per Success)

Model	RAG Calls	Tool Calls
Qwen3 30B	4.4	11.4
GPT-4o	3.8	9.0
Claude Sonnet 4	3.2	7.8

Findings indicate that agentic RAG architectures, by combining retrieval and deterministic tool-based feedback, substantially improve syntactic and semantic correctness of policy generation and enable smaller, open-weight LLMs to match performance of advanced closed models. Pure LLMs or LLM+RAG without tool-based validation fail to robustly generate correct policies (Romeo et al., 11 Jul 2025).

7. Limitations and Prospects for Further Development

Limitations acknowledged include:

• Absence of fully automated semantic verification for Rego policies beyond reliance on human oracles.
• Potential for non-termination in edge cases if the iteration cap is exhausted without policy satisfaction.
• Empirical focus remains on Terraform; evaluation for complex, heterogeneous multi-cloud environments is pending.

The authors propose several directions to enhance ARPaCCino’s capabilities:

• Incorporation of self-RAG to enable autonomous knowledge base expansion.
• Development of automated semantic verifiers for Rego (e.g., using SMT solving or symbolic execution) to obviate the need for oracle validation.
• Extension to real-time CI/CD integration and comprehensive support for polyglot, multi-framework deployments.

These avenues reflect ongoing challenges in both reliable policy synthesis and holistic, cross-framework compliance automation (Romeo et al., 11 Jul 2025).