Skip to content
Global
Request access
Documentation sectionsGovernment & Defense
Access status
INDUSTRY ARCHITECTURE

Sovereign Mode: AI Security for Government and Critical Infrastructure

Important

Sovereign Mode is a target architecture: Spectorn entirely inside the customer's isolated perimeter, with no internet access and no external cloud services. It is meant for critical information infrastructure (CII), defense organizations and bodies subject to the requirements of FSTEC of Russia. It is not part of the current release. Today Spectorn runs as a cloud service in two separate contours, RU and Global. Below, what works now and what belongs to the target architecture are stated separately.

In government deployments, AI autonomy, no dependency on external cloud APIs and cryptographic data protection become regulatory requirements. A cloud service does not meet them in full, and this page separates what Spectorn does today from what needs an installation inside the customer's perimeter.

🛑 AI risks in the public sector

Embedding generative models and AI agents into government processes introduces a class of threats that standard WAFs and DLP systems do not parse: they cannot see the meaning of a prompt or of a model's response.

1. Data-residency violations and leakage of state secrets

Risk: When Western enterprise models (OpenAI, Anthropic, Google) are used, confidential data inevitably travels to foreign servers. Even with domestic Russian models (Yandex, GigaChat), there is still a risk of sensitive logs being sent to external networks. What Spectorn does today:

  • Inline content inspection: in gateway mode Spectorn checks the content of requests and model responses with the injection, pii, exfiltration and output_scanner engines. In enforce mode a request that breaks policy is rejected, and a blocked model response is withheld (HTTP 403 spectorn_output_blocked). PII masking is not enabled in the cloud contours.
  • Separate contours: the RU and Global contours are kept apart; accounts and data of one do not reach the other. Spectorn's logs keep no request content.

What belongs to the target architecture:

  • A fully local installation with no external dependencies: in the cloud contour a request goes to Spectorn and, in gateway mode, on to the model provider.
  • Encryption of backups and logs to GOST standards (for example, Kuznyechik, GOST R 34.12-2015) is not implemented in Spectorn. Today it is provided by certified cryptographic tools in your infrastructure.

2. Targeted sabotage via a RAG attack (Data Poisoning)

Risk: A poisoned document planted in the knowledge base (vector DB) makes an AI agent produce distorted reports for leadership or run destructive commands in IT systems (RCE). What Spectorn does today:

  • The rag_corpus_guard engine checks the RAG fragments you pass in a request for embedded injections and anomalies before they reach the model.

Risk: The opacity of neural-network decisions makes FSTEC inspections and legal investigation of incidents impossible. What Spectorn does today:

  • Every verdict is written to a hash-linked SHA-256 chain without request content, so a later edit to a record shows. Findings can be exported to your SIEM as JSON events over HTTPS (spectorn.ai-finding.v1).

🛠️ Sovereign Mode target architecture

This is an architecture design, not a description of a delivery: installation inside the customer's perimeter is not part of the current release.

In the target architecture Spectorn is installed on the customer's hardware inside an isolated perimeter. The choice between physical servers and virtualization follows the customer's threat model: physical hardware lowers the risk of a container breakout.

Diagram
graph TD
    User([Public-sector employee / Operator]) -->|HTTPS| Gateway[Customer NGFW / WAF]
    Gateway --> SC[Spectorn gateway]
    
    subgraph Isolated CII perimeter
        SC -->|mTLS| Core(Spectorn engines in Rust)
        Core -->|Content inspection| LLM[Local LLM]
        Core -->|Content inspection| VectorDB[(Customer vector DB)]
    end
    
    Core -->|Findings, JSON| SIEM[Customer SIEM]
    
    style User fill:#f9f,stroke:#333,stroke-width:2px
    style SC fill:#FF3D72,stroke:#333,stroke-width:2px
    style Core fill:#3D72FF,stroke:#333,stroke-width:2px,color:#fff
Tip

Latency Spectorn's engines are written in Rust and run on CPU. Measure latency on the specific deployment and your own load profile.

🛠️ Policy settings

There is no configuration file to deploy: the platform operator sets your tenant's policy at your request, including the scan mode (enforce, or shadow to see what would be blocked without blocking it), allow and deny lists, the block threshold and category weights. Start in shadow mode on your own traffic, review what would have been blocked, then enforce.

📜 FSTEC requirements (Russia)

Spectorn is not FSTEC-certified, and conformity with FSTEC Order No. 239 (on the protection of critical information infrastructure) has not been assessed. Below is how Spectorn's mechanisms relate to its requirements; the CII operator assesses the facility's conformity with an accredited organization.

Meeting assurance requirements

  1. Domain Separation Language models run without direct access to the server's file system and network — enforced by OS-level sandboxing / container isolation inside the customer's isolated perimeter (not by Spectorn). Spectorn inspects the content of prompts and responses at the gateway.
  2. Vulnerability analysis The code is checked in CI by static analysis and tests; no independent vulnerability assessment for certification has been done. Rust rules out buffer overflows in safe code, not in unsafe blocks or C dependencies.
  3. Tamper-evident decision registry (Decision Audit Log) Decisions are recorded in a tamper-evident SHA-256 chain without the content of requests, so a later edit of a record shows; findings can be delivered to your SIEM. Interpreting this evidence against FSTEC requirements remains the work of your auditor and your organisation.
Warning

Whether autonomous LLMs may run inside a CII network is decided by the CII operator from its categorization and threat model. Spectorn is one control here: it lowers risk, but it does not replace that assessment.

❓ Frequently asked questions (FAQ)

What is Sovereign Mode and who needs it?

It is a target architecture: Spectorn inside the customer's isolated perimeter, with no internet access. It is meant for CII, defense organizations and bodies that must meet the requirements of FSTEC of Russia, such as Order No. 239. It is not part of the current release; today Spectorn is available as a cloud service in the RU and Global contours.

How is "no data leaves" achieved in an isolated deployment?

In the target architecture, by the network isolation of the perimeter itself: Spectorn and the local LLM run with no outbound internet access. That is a property of the deployment and the customer's network, not a filter in the engines. Spectorn does not perform GOST encryption today; the customer's certified cryptographic tools provide it. In the cloud contour a request goes to Spectorn and, in gateway mode, on to the model provider.

Can Spectorn defend a government RAG pipeline against data poisoning?

In part. The rag_corpus_guard engine checks the RAG fragments passed in a request for embedded injections and anomalies before they influence the model's output. That lowers the risk from poisoned documents, but control over the corpus's provenance and over write access to it stays with you.

How does Spectorn make AI decisions auditable for FSTEC?

Every verdict is written to a hash-linked SHA-256 chain without request content, so a later edit to a record shows. Findings are exported to your SIEM as JSON events over HTTPS (spectorn.ai-finding.v1); there is no CEF or syslog export. This does not establish that the log meets FSTEC requirements.

Sovereign AI Security for Government and CII | Spectorn