DEV Community: saaro

Agentic RAG 2026: When the AI Decides How It Searches

saaro — Sun, 13 Sep 2026 11:46:46 +0000

In spring 2026, the world of Retrieval-Augmented Generation (RAG) is facing a fundamental change. While RAG in 2023 was still a simple pipeline – embed query, fetch top-K chunks, stuff into prompt, generate – the architecture has since split into three independent directions: Agentic RAG, Graph RAG, and Long-Context approaches. In particular, the approach called Agentic RAG marks a qualitative leap: instead of a passive retrieval pipeline, an LLM-driven agent now controls the entire retrieval process – planning, iterating, self-correcting.

From Pipeline to Agent Loop

The core difference between classic and agentic RAG lies in the control logic. Traditional RAG is a linear function: one pass, one result. Agentic RAG, on the other hand, is a state machine that works in loops. An agent receives a question, breaks it down into sub-questions, decides which sources to call (vector database, SQL, web search, MCP server), evaluates the results, and if quality is insufficient, starts a new pass – until the answer meets a confidence threshold or an iteration limit is reached (typically 5–6 passes).

Production systems standardly use LangGraph as the orchestration framework for this, supplemented by LlamaIndex for the retrieval layer. LangGraph's checkpointing makes every step of the agentic loop traceable, pausable (for human approvals), and repeatable – an essential property for compliance and debugging.

The Three Central Patterns: Self-RAG, CRAG, and Adaptive RAG

Three dominant architectural patterns have emerged from research and practice.

Self-RAG (Asai et al., 2023) lets the model output special reflection tokens: Should it read at all? Are the retrieved passages relevant? Is the generated answer supported by the evidence? Is the answer useful? These self-critique loops significantly reduce hallucinations – ideal for regulated areas like legal, medical, or finance.

Corrective RAG (CRAG) (Yan et al., 2024) adds a separate retrieval evaluator that assesses the quality of the retrieved documents and, for weak evidence, takes alternative retrieval paths – such as a web search instead of the vector database. In production, CRAG is often combined with knowledge graph queries.

Adaptive RAG places a query classifier before the pipeline, sorting each request by difficulty: Simple fact questions skip retrieval entirely, moderate ones get a single-hop vector search, and complex multi-step questions receive the full agentic loop. Since 60–70% of all production queries are simple, this approach saves significant costs without sacrificing quality on challenging questions.

The 2026 Production Stack

The standard stack for agentic RAG systems has largely solidified by 2026: Hybrid Search (dense vectors + sparse BM25 keywords, fused via Reciprocal Rank Fusion) is the foundation – pure vector search is considered an architectural mistake. A Cross-Encoder Reranker (Cohere Rerank 3.5, Voyage AI rerank-2.5) re-evaluates the relevance of each retrieved passage before passing to the LLM, yielding measurable precision gains. Additionally, Knowledge Graphs (Neo4j, LazyGraphRAG) are used for relation-rich queries.

Evaluation is no longer an optional step: Ragas provides automated metrics (Faithfulness ≥ 0.9, Answer Relevancy ≥ 0.85, Context Precision ≥ 0.8), supplemented by observability tools like Arize Phoenix and Langfuse.

Costs and Latency: Realistic Expectations

Agentic RAG is not a free upgrade. Token costs per query increase by a factor of 3–10x compared to simple RAG, and latency goes from 1–2 seconds to 4–15 seconds (p95). A team that routes expensive queries (e.g., "Compare clause 4.2 from the last five contracts") through a FAQ bot with simple fact questions wastes budget. Therefore, Adaptive RAG – the routing logic before the agent – is the de facto architectural decision for mixed workloads.

At the same time, building such systems has become more efficient: what cost two engineers six weeks in 2024, one engineer achieves in four weeks in 2025/26 – with higher runtime quality thanks to standardized patterns and a more mature tooling landscape.

Conclusion

In 2026, Agentic RAG is no longer an experimental gimmick, but a mature architecture for all cases where simple RAG reaches its limits. The decisive question is not "Should I use agentic RAG?" but rather "For which query class is the extra effort worthwhile?". Those who route their queries by complexity, use Self-RAG or CRAG for challenging cases, and evaluate with Ragas will fare better than with a one-size-fits-all architecture. RAG is not dead – it has been broken down into its components, and those who understand that build the cheaper and more accurate systems.

Sources

localreview: Local AI Code Reviews with Claude Code – GDPR-compliant and Cloud-independent

saaro — Sun, 13 Sep 2026 11:46:09 +0000

Your code never leaves your machine – and yet you get a structured AI code review. With localreview, you can get a second opinion on your diff in Claude Code based on a locally running model. No cloud provider, no data leak, no dependency on external APIs.

Why localreview?

Claude Code is a powerful tool – but anyone reviewing sensitive codebases faces a dilemma. The built-in AI review leaves the local machine and is sent to cloud APIs. For many companies, this is a deal-breaker, especially with proprietary code, before publication, or in GDPR-regulated environments.

The existing solution from OpenAI (Codex CLI with Codex-Plugin-CC) pointed the way: a plugin that adds a second AI review. But it was tied to Codex – a cloud service.

localreview takes the same approach, but cloud-independent. It sends your diff to a locally running, OpenAI-compatible model – for example, oMLX on your MacBook, or in the future LM Studio.

How it works

The plugin is implemented as a Claude Code plugin and provides five slash commands:

Command	Function
`/localreview:review`	Starts a review of the current diff (with options for scope, branch, model)
`/localreview:status`	Shows running and completed review jobs
`/localreview:result`	Shows the result of a completed review
`/localreview:cancel`	Cancels a running review
`/localreview:setup`	Checks if the local server is reachable and lists available models

The review runs fully asynchronously – large models take several minutes. With --background, you keep working while the review runs in the background.

Local models as the review engine

In the first step, localreview supports oMLX – an LLM inference server specialized for Apple Silicon with continuous batching, SSD caching, and multi-model management. oMLX runs on the MacBook and provides an OpenAI-compatible API at http://127.0.0.1:8000/v1.

The extension to LM Studio is already built into the architecture – since LM Studio also offers an OpenAI-compatible API, only minor adjustments in the configuration are needed.

The crucial difference: data protection

Unlike cloud-based review solutions, with localreview your code never leaves your machine. Communication runs exclusively over localhost:

No data transfer to the cloud
No dependency on external APIs
No storage on third-party servers
Fully GDPR-compliant

The plugin even explicitly warns you if you accidentally configure an external address – your security is built in, not optional.

Installation

# In Claude Code:
/plugin marketplace add mjochum64/localreview
/plugin install localreview@localreview

After that, a simple /localreview:setup checks whether your local server is running.

Configuration

You have three ways to configure the server and model (in this order):

CLI flag: --model <id> on the review command
Environment variables: LOCALREVIEW_BASE_URL, LOCALREVIEW_MODEL
Config file: ~/.config/localreview/config.json

By default, localreview connects to http://127.0.0.1:8000/v1 and selects the first available model.

What makes localreview special

Read-only: The plugin never changes code, never applies suggestions, and runs only on your explicit request
Structured output: Findings are sorted by severity (via JSON schema)
Sensitive files excluded: .env, .pem, SSH keys, and similar files never even make it into the diff
German interface: Commands, error messages, and the review itself are in German
Open source: Apache-2.0 license – viewable, extensible, auditable

Outlook

localreview is the first step in a direction I believe represents the future of code review: local AI as a second pair programmer, independent, data‑protection‑compliant, and always available. Integration of LM Studio, more model backends, and an English interface are the logical next steps.

Anyone who wants to get involved: the repository is open for issues, pull requests, and ideas.

Sources

Supply Chain Security 2026: SBOM, Sigstore/SLSA, and Admission Control as DevOps Standard

saaro — Sun, 13 Sep 2026 11:45:14 +0000

Software supply chain attacks are estimated to cost the global economy 80.6 billion US dollars in 2026 – an increase of 76 percent compared to 2023. The Jaguar Land Rover attack alone in August 2025 caused 1.9 billion pounds in damage and halted production for five weeks. Attacks on container images, CI/CD pipelines, and build systems are no longer future scenarios but the new reality for DevOps teams. With the first EU Cyber Resilience Act (CRA) reporting obligations taking effect in September 2026, supply chain security is shifting from nice-to-have to regulatory requirement.

SBOM: The Digital Table of Contents for Software

A Software Bill of Materials (SBOM) is the foundation of any supply chain security. It lists all components, libraries, and dependencies of an application – similar to the ingredient list on food products. The EU CRA mandates, starting September 2026, an SBOM in machine-readable format for products with digital elements, capturing at least the most important dependencies.

The two dominant SBOM formats are CycloneDX and SPDX. For containerized applications, CycloneDX has established itself as the de facto standard since it is specifically designed for container environments. In the CI/CD pipeline, the open-source tool Syft can generate SBOMs automatically:

syft ghcr.io/myorg/myapp:v1.2.3 -o cyclonedx-json > sbom.cyclonedx.json

An SBOM alone, however, does not protect against attacks – it only documents the attack surface. Actual security is achieved through signing, verifying, and enforcing policies.

Sigstore: Keyless Signing for Container Images

Sigstore is an open-source project by the Linux Foundation that enables cryptographic signing without managing your own GPG keys or PKI infrastructure. The underlying tool Cosign uses OIDC tokens from CI platforms such as GitHub Actions or GitLab CI as identity – so-called keyless signing.

The practical application is remarkably simple:

cosign sign --yes ghcr.io/myorg/myapp:v1.2.3

For verification, this suffices:

cosign verify \
  --certificate-identity=ci@myorg.com \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  ghcr.io/myorg/myapp:v1.2.3

Since the identity comes directly from the CI context, the problem of key management is eliminated. No secrets that can be rotated, secured, or leaked.

SLSA: Maturity Model for Build Integrity

The SLSA framework (Supply-chain Levels for Software Artifacts, pronounced "salsa") defines four levels of build integrity:

Level 1: The build process is documented and not manual.
Level 2: The build runs hosted and versioned; provenance is recorded as an attestation.
Level 3: The build platform itself is hardened – isolated, immutable build environments prevent manipulation.
Level 4: Two-person review and hermetic builds (fully reproducible).

Most organizations should aim for at least SLSA Level 3. This ensures that an attacker who has gained access to the CI system cannot deliver manipulated artifacts without it being detectable. SLSA Level 4 is currently only realistic for particularly critical infrastructure components.

Kubernetes Admission Control: The Enforcement Layer

Signed images are of little use if the signature is not enforced. This is where Kubernetes admission controllers come into play. With Kyverno or OPA/Gatekeeper, you can enforce that only signed images run on a cluster:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: enforce
  rules:
  - name: verify-cosign-signature
    match:
      resources:
        kinds: ["Pod"]
    verifyImages:
    - imageReferences:
      - "ghcr.io/myorg/*"
      attestors:
      - entries:
        - keyless:
            subject: "ci@myorg.com"
            issuer: "https://token.actions.githubusercontent.com"

This policy blocks any pod whose container image lacks a valid Cosign signature with the expected identity. Unsigned or manipulated images are automatically rejected – before they are even executed.

The Complete DevOps Pipeline

In practice, a six-step security workflow has become established:

Build – Reproducible, hermetic builds in isolated CI environments
Scan – Vulnerability scanning with Trivy or Grype immediately after the build
Sign – Keyless signing with Cosign and Sigstore
Attest – Attach SBOM and scan results as verifiable attestations
Verify – Admission controllers (Kyverno/OPA) enforce signed images in the cluster
Monitor – Continuously scan running containers for new CVEs

Organizations implementing this workflow report 76 percent fewer security incidents in the supply chain and save an average of 1.76 million US dollars per prevented breach.

Conclusion

Supply chain security is no longer an optional DevSecOps add-on in 2026. With the EU Cyber Resilience Act, SBOMs and verifiable build integrity are already regulatory requirements for many companies. The good news: The tools are mature, open source, and production-proven. Sigstore/Cosign, the SLSA framework, and Kubernetes admission controllers form a triad that effectively prevents attacks on the software supply chain. DevOps teams that start today with SBOM generation, keyless signing, and Kyverno policies are not only more secure – they are also on the safe side regulatory-wise.

Sources

Container Supply Chain Security 2026: Why 67% Can't Detect the Threat — Gheware DevOps AI Blog
Supply Chain Security in 2026: SLSA, Sigstore, and Cosign — Luca Berton
CRA SBOM Requirements 2026 — CycloneDX vs SPDX — sota.io Blog
Software Supply Chain Security: The 2026 Threat Landscape — Medium / DevOps AI Decoded
Supply Chain Security 2026: Sigstore and SLSA 3 Guide — Tech Bytes

Kubernetes v1.37 Garhwal: Rootless Kubelet, Gang Scheduling, and Native Pod Certificates

saaro — Sun, 13 Sep 2026 11:45:13 +0000

On August 26, 2026, Kubernetes v1.37 "Garhwal" was released – with 67 enhancements, including 16 stable and 23 beta features. While the release builds on the foundations of its predecessors, it sets a clear focus on operational security, resource efficiency, and the growing importance of AI/ML workloads. Which changes really matter for cluster operators.

Rootless Kubelet: A New Level of Security

The kubelet has historically run as a root process on the node – an attack vector that exposes the entire machine if compromised. With v1.37, the rootless kubelet (feature gate KubeletInUserNamespace) reaches beta status. The entire node stack – kubelet, kube-proxy, CRI and OCI runtime – can now run in a user namespace as an unprivileged user.

The practical consequence: code execution in the kubelet no longer ends with root privileges on the host. Combined with the stable user namespaces from v1.36, the trust boundary of a Kubernetes node shifts fundamentally – particularly relevant for edge deployments with physical access or multi-tenant clusters. The feature is disabled by default; cluster operators should pilot it on edge and scenarios with heightened security requirements.

Pod Certificates and KYAML: Stability for Daily Operations

Two long-awaited innovations reach stable status in v1.37:

Pod Certificates and Cluster Trust Bundles enable native mTLS certificates for pods directly from the cluster. The kubelet requests a certificate via a PodCertificateRequest object, an integrated signer issues it, and via a projected volume it lands directly in the pod's filesystem. Management via ClusterTrustBundle objects distributes the trust anchors. This makes external solutions like cert-manager unnecessary in many scenarios – certificate rotation happens natively through the kubelet.

KYAML – a safer, ambiguity-free YAML subset specifically for Kubernetes – is now stable after graduating from alpha (v1.34) to beta (v1.35). Every KYAML file is valid YAML, but not every YAML is KYAML. Anyone who has ever experienced "NO" being interpreted as boolean false knows why that matters. The command kubectl get -o kyaml is now ready for production use.

Also after nine years of beta: the Metrics API (metrics.k8s.io) is stable. CPU and memory data for pods and nodes, which power features like kubectl top and the HPA, are now available via a GA API.

Gang Scheduling and DRA: AI/ML Workloads in Focus

Kubernetes is increasingly becoming the orchestrator for AI training and HPC simulations. This release addresses exactly that: Gang Scheduling (beta behind the feature gate GenericWorkload) allows an "all-or-nothing" strategy – a group of pods (a PodGroup) is only scheduled if the cluster has enough resources for the entire group. Previously, the scheduler could spread individual pods while others waited for capacity, leading to deadlocks.

The Workload and PodGroup APIs reach v1beta1, the minCount field is now mutable, and the scheduler only enqueues the PodGroup object – no longer each member individually. The new CompositePodGroup API (alpha) enables hierarchical scheduling structures for complex, heterogeneous workloads such as those managed by JobSet and LeaderWorkerSet (LWS).

In the area of Dynamic Resource Allocation (DRA), four features become stable, including ResourceClaim status with standardized network interface data and Device Taints/Tolerations – crucial for GPU workloads where fine-grained control over resource allocation is needed.

HPA Scale-to-Zero and Other Highlights

The HorizontalPodAutoscaler feature Scale-to-Zero (beta, now enabled by default) allows workloads to scale down to zero pods when there is no load – for example, queue consumers, batch jobs, or GPU workloads during idle periods. The metric must be based on object or external metrics, since CPU/memory metrics require active pods.

Other relevant innovations: Manifest-based Admission Control (beta) allows loading admission webhooks and CEL policies directly from disk, independent of etcd. The Storage Version Migration API (storagemigration.k8s.io/v1) is stable – data can be automatically migrated to the new storage version after API upgrades. And with Memory QoS (beta, enabled by default), cgroups-v2-based nodes get more effective memory isolation mechanisms.

Conclusion

Kubernetes v1.37 "Garhwal" continues the trajectory of previous releases: security and resource efficiency become first and foremost meaningful. The rootless kubelet, native pod certificates, and Memory QoS make the cluster more resilient, while Gang Scheduling and the DRA improvements pave the way for AI/ML workloads on Kubernetes. For operators, a closer look at the beta features is worthwhile – and those relying on edge nodes should put piloting the rootless kubelet on the agenda.

Preparations for v1.38 are already underway; the shadow team is looking for contributors.

Sources

Presidio 2026: PII Detection and Anonymization for GDPR-Compliant AI Pipelines

saaro — Sun, 13 Sep 2026 11:41:11 +0000

Anyone using AI systems like ChatGPT, Claude, or their own Large Language Models (LLMs) in business processes faces a fundamental problem: Personally Identifiable Information (PII) unintentionally ends up in the prompt text box, in log files, or in fine-tuning datasets. However, the GDPR requires data minimization and a clear legal basis for every processing activity. This is where Presidio comes into play – an open-source framework that detects PII in text and images and automatically redacts it before the data reaches an AI system.

What is Presidio?

Presidio (Latin praesidium – protection, garrison) was originally developed by Microsoft and released as open source in 2018. Since 2026, the project has been in transition to a community-led organization under the umbrella of the Data Privacy Stack on GitHub (github.com/data-privacy-stack/presidio) – Microsoft supports this step. This is not a fork, but rather the continuation of the same project under new, independent governance. The source code remains available under the MIT license.

The framework consists of five modules:

presidio-analyzer – detects PII in text using regular expressions, Named Entity Recognition (NER), checksums, rule sets, and context analysis
presidio-anonymizer – replaces, masks, hashes, encrypts, or redacts the detected entities
presidio-image-redactor – redacts PII in images, including medical DICOM scans
presidio-structured – searches tabular data (DataFrames) column by column for PII
presidio-cli – enables command-line scans for CI/CD pipelines

The current version 2.2.364 from July 2026 shows active development: Python 3.14 compatibility, new country recognizers (Philippines, Germany), and batch deanonymization were recently added.

How does PII protection work?

The typical workflow is two-stage: First, the AnalyzerEngine analyzes the text and returns a list of detected entities with text position and confidence score. Then the AnonymizerEngine takes these results and applies the desired operators.

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

text = "Mein Name ist Max Mustermann, Tel: 0170-1234567"

# Step 1: Detect PII
results = analyzer.analyze(text=text, language="de")

# Step 2: Anonymize PII
anonymized = anonymizer.anonymize(
    text=text,
    analyzer_results=results,
    operators={"DEFAULT": OperatorConfig("replace")}
)

print(anonymized.text)
# Output: "Mein Name ist <PERSON>, Tel: <PHONE_NUMBER>"

The analyzer currently supports over 100 predefined recognizers for various countries and entity types: from email addresses, IBANs, and credit card numbers to country-specific ID documents. spaCy, Stanza, or Hugging Face Transformers can serve as the NLP engine. Language detection is extensible – while English is configured by default, additional languages can be added by swapping the NLP model and adjusting context words.

Presidio in front of AI pipelines: Working GDPR-compliant

The most important use case for companies is deployment as a protective layer in front of LLMs. Before a prompt reaches an AI service, it passes through Presidio: email addresses, phone numbers, names, and other personal data are replaced with placeholders. The risk of unintentional data disclosure drops dramatically.

From a GDPR perspective, however, an important nuance must be noted: Presidio typically performs pseudonymization, not complete anonymization. Since the encrypted or hashed values can be restored under certain circumstances (e.g., via the built-in decrypt operator), the data continues to qualify as personal data under GDPR Recital 26 – but the risk is significantly reduced. For true anonymization, the data would need to be irreversibly deleted or aggregated in such a way that no re-identification is possible.

Presidio can be operated in various ways: embedded as a Python library in existing applications, as a Docker container for microservice architectures, via PySpark for batch processing on data pools, or in Kubernetes clusters.

Limitations and honesty

The developers of Presidio are transparent: "Presidio can help identify sensitive/PII data in un/structured text. However, because it is using automated detection mechanisms, there is no guarantee that Presidio will find all sensitive information." PII detection is never 100% accurate – NER models can produce false positives, miss unusual formats, or misinterpret context. Presidio is a powerful tool, but not a substitute for legal advice or a comprehensive Data Protection Impact Assessment (DPIA).

Conclusion

Presidio has evolved from a Microsoft-internal tool into an independent community project and is today the most mature open-source building block for PII detection and anonymization. For companies that want to operate AI systems GDPR-compliant, it is one of the most practical solutions: it is self-hostable, auditable, extensible, and covers text, images, and tabular data. Anyone looking to add a PII protection layer to their AI workflow will find a solid, actively maintained entry point in Presidio.

Sources

Representative documentation homepage – Presidio by Data Privacy Stack: https://presidio.dataprivacystack.org
GitHub repository (README, license, architecture): https://github.com/data-privacy-stack/presidio
Project Transition – Microsoft → Community project: https://github.com/data-privacy-stack/presidio/blob/main/docs/project_transition.md
Releases – Version 2.2.364 (July 22, 2026): https://github.com/data-privacy-stack/presidio/releases
Analyzer documentation (architecture, recognizers, API): https://presidio.dataprivacystack.org/analyzer/
Anonymizer documentation (operators, hash, encrypt): https://presidio.dataprivacystack.org/anonymizer/
Multi-language support in Presidio: https://presidio.dataprivacystack.org/analyzer/languages/
Pasquale Pillitteri (June 19, 2026, updated July 15, 2026) – Presidio & GDPR: https://pasqualepillitteri.it/en/news/5538/microsoft-presidio-pii-data-protection-ai