Cloud.ru open-sources a data filter for AI models

On 20 July 2026, Cloud.ru published the source code of Guardrails Filter, an intermediary service designed to protect sensitive information in large-language-model workflows. It can be deployed within an organisation’s own infrastructure and used with models from different providers.

The filter checks both the request and the model response. Before a request is sent, it replaces personal data, passwords, API keys and other confidential values with synthetic substitutes. When the response returns, the original values are restored. This layer can reduce accidental disclosure, but it does not replace access control or application security.

Where the filter sits

Guardrails Filter is placed between a corporate application and a model API. This is a useful control point: every integration does not need its own collection of regular expressions and policies, and security events can be gathered centrally.

The open-source version supports standard and custom rules. An organisation can add formats for internal contracts, customer identifiers or project code names. Cloud.ru also describes security-event logging and Ghost Mode, which detects matches without modifying production traffic.

Ghost Mode is particularly useful before enforcement. It reveals which data actually passes through an integration, how many false positives a policy would create and which business flows require an explicit exception.

How to interpret the benchmark

Cloud.ru reports an F1 score of 93.1 and precision of 99.9% on the public pii-bench dataset. These figures apply to a specific version, configuration and test set. They provide a useful starting point but do not guarantee the same outcome on an organisation’s documents.

Internal data has its own language, abbreviations and formats. A contract number may resemble a date, while a project name may resemble a surname or technical term. A pre-production evaluation therefore needs a representative set containing:

• real but anonymised user prompts;
• variations of identity and payment data;
• secrets embedded in code, tables and attached documents;
• prompts without sensitive information;
• edge cases that must not be blocked.

Recall matters alongside precision. A low false-positive rate supports usability, but a missed secret creates a direct disclosure risk.

Risks that masking does not address

Masking protects request content, but several other threat classes remain:

1. An application may send an unnecessary document in full.
2. A user or external source may inject a malicious instruction.
3. A model response may contain an incorrect or unsafe recommendation.
4. The filter’s own logs may become a sensitive-data store.
5. Compromise of the restoration service can expose the mapping between original and synthetic values.
6. An AI agent with tools may obtain a secret through a later API call.

The filter therefore belongs alongside data classification, least privilege, segmentation, secret management and action controls. Agentic use cases also need a separate secure AI-agent architecture.

How to integrate it into an enterprise environment

A practical pilot begins in observation mode, then enables masking for one non-critical flow and expands only after measurement. Every rule should have an owner, a version and automated tests.

Production requirements include:

• a resilient filter deployment so it does not become a single point of failure;
• encrypted traffic on both sides of the service;
• application authentication and separate policies for separate systems;
• restricted, sanitised log storage;
• latency, error and match-rate metrics;
• an explicit safe behaviour when the filter is unavailable;
• controlled rule updates without interrupting the integration.

The API contract and responsibility boundary should be documented before development. Our guide to API integration architecture covers the same foundation: contracts, timeouts, idempotency, observability and degradation paths.

Practical conclusion

Publishing the source code makes the mechanism inspectable and allows it to run close to corporate data. That matters to organisations that cannot rely on a remote filter without visibility into its implementation and audit trail.

Guardrails Filter’s value still depends on the quality of its policies, a representative internal test set and the security of the complete request path. The right starting point is a data inventory and a measured pilot, not a broad claim that every AI request is now safe.

Source: official Cloud.ru blog.