Ciralgo security whitepaper (public summary)

LLM proxy security architecture is what separates a routing convenience from an audit-defensible piece of critical enterprise infrastructure. This page is the public summary of Ciralgo's approach. It describes the trust boundaries, tenant isolation model, data residency posture, and where audit records live, in enough detail for a security team to decide whether the full whitepaper is worth requesting.

The full whitepaper covers the specific control implementations, third-party audit evidence, and incident response commitments. It is available under NDA to prospects with an active procurement conversation. Consequently, this page focuses on the design decisions a security architect can evaluate before signing an NDA.

If you are the person expected to sign the security questionnaire for a procurement round, this page tells you whether Ciralgo is worth deeper diligence. If you are the person who has to design a workaround because the answer is no, this page tells you where the gaps would be.

What LLM proxy security architecture actually protects

Every LLM proxy sits between three things a regulated organisation cares about: the application code that generates prompts, the external provider that runs the model, and the records that prove what happened. Consequently, the security architecture has to protect all three surfaces at once.

Ciralgo's LLM proxy security architecture defines three protection domains, each with its own trust boundary.

• The request path protects the confidentiality and integrity of prompts and responses in transit. Nothing in the request payload is written to durable storage in its original form.
• The tenant isolation domain protects one customer's data, records, and configuration from being read, modified, or observed by another customer, even through side-channel signals.
• The records plane protects the audit records described in AI audit logging under the EU AI Act from tampering, backdated modification, or unauthorised export.

These three domains have separate failure modes, so we operate them as separate concerns. In practice, an incident in one does not automatically compromise the others.

Trust boundaries

The LLM proxy security architecture assumes that the network between your application and Ciralgo is hostile. It also assumes that the network between Ciralgo and provider endpoints is hostile. Furthermore, it assumes that the storage layer behind Ciralgo is subject to the same threats as any commercial cloud storage service.

Under those assumptions, three trust boundaries carry cryptographic protection:

• Application to Ciralgo ingress.
• Ciralgo to provider egress.
• Ciralgo internal service mesh, between control plane and data plane.

Each boundary uses transport-layer encryption with modern cipher suites and mutually-authenticated identity where the counterparty supports it. The public whitepaper deliberately does not name specific ciphers, key lengths, or protocol versions on this page. Instead, the full whitepaper does, and lists them alongside the audit evidence that verifies each choice.

Tenant isolation

Every customer has an isolated logical tenant. Consequently, requests, records, keys, and policies for tenant A are never physically colocated with tenant B in a way that permits either read-through or timing-based inference.

Isolation is enforced in four places:

• The API layer authenticates every request to a specific tenant before any downstream call is made.
• The records store partitions data by tenant at the storage-engine level, not at the application-query level.
• The policy engine evaluates rules against a tenant-scoped snapshot of the provider surface, so tenant A's policy never sees whether tenant B has a provider outage.
• The observability plane redacts tenant identifiers from any operational log that leaves the tenant boundary, so on-call engineers can debug incidents without inadvertently reading customer content.

The full whitepaper includes the specific control identifiers, the SOC 2 CC-series controls each maps to, and the independent audit evidence for each.

Data residency

Ciralgo's LLM proxy security architecture treats data residency as a first-class control, not an operational detail. Specifically, every piece of customer content routed through Ciralgo has an assigned jurisdiction, and every persistence step in the request path enforces that assignment.

The default jurisdiction is EU. Records, policies, keys, and observability data for a tenant tagged EU never leave EU regions. Furthermore, the underlying cloud infrastructure runs on providers with independently-audited EU data-processing certifications. The Regulation (EU) 2024/1689 requirements around data governance under Article 10 are satisfied at the infrastructure layer, not just as a contractual commitment.

Where a customer's LLM provider routing policy permits US or other jurisdictions for specific workloads (typically under an explicit override), the routing decision is recorded in the audit trail and the exception is bounded in time. In no case does a customer inadvertently leave the EU because Ciralgo chose a cheaper region.

Where the audit records live

The records described in AI audit logging under the EU AI Act are stored in a WORM-shaped (write-once, read-many) records store with a retention class attached at write time. The records store is deliberately not the same system as the operational transactional store. As a result, an incident on the transactional path does not risk record integrity.

Records are exportable to the customer's own SIEM at any time. Customers who prefer to keep records in their own infrastructure can opt for streaming export as the primary destination, with Ciralgo holding a rolling operational cache only.

Access to the records store is scoped to the customer's own roles: auditor (read-only), compliance officer (read-only, may export), and platform administrator (may query for operational purposes, cannot modify content). Ciralgo staff have no default read access. Any Ciralgo staff read requires an explicit customer-signed break-glass, which itself produces a governance event on the customer's own log.

What we can and cannot tell you on a public page

The design decisions above are the shape of the LLM proxy security architecture. However, the specific implementation choices (algorithms, key lengths, protocol versions, patch cadence, HSM vendor, and the identities of the third-party auditors) live in the full whitepaper.

We keep the specifics behind an NDA for two reasons.

First, published algorithm and version details become a threat-model artefact. Every algorithm rotation forces a document update, and every stale artefact becomes a false positive in a public bug bounty. Consequently, we would rather have the current facts available on request than stale facts in the wild.

Second, publishing a full control set signals to every determined attacker exactly where to look for our weakest surface on any given day. Instead, we prefer to have that conversation with a named security lead who has signed an NDA.

If you need the specifics before you can move forward, request the whitepaper and we will send it within one working day.

Frequently asked questions about LLM proxy security architecture

Where is Ciralgo hosted?

Ciralgo's LLM proxy security architecture runs on EU-region infrastructure by default. Specifically, we use a mix of AWS eu-west (Ireland), OVHcloud (Gravelines and Strasbourg), and Scaleway (Paris) for different concerns. The full jurisdictional breakdown lives in the sub-processor list.

Do you hold SOC 2 or ISO 27001?

The underlying controls are in place today. Independent attestation is in progress. Meanwhile, we can share the internal control matrix and the auditor engagement letter under NDA.

Can we run our own encryption keys?

Yes, via customer-managed keys held in your KMS. Ciralgo never sees the raw key material. The full whitepaper documents the key envelope model.

How do you handle penetration test findings?

Every finding classified as high or critical is remediated within an agreed window with the reporter. Furthermore, we run continuous internal red-team exercises against the same threat model. Reports are shareable with prospects under NDA.

What happens if a provider we route to has a security incident?

Ciralgo can push a tenant-scoped or global blocklist entry within minutes, refusing all further requests to that provider until you lift it. Consequently, this containment path is documented in the incident response section of the full whitepaper.

Is there a bug bounty programme?

Yes. Details are available on request. In practice, most reports come from named researchers under a coordinated-disclosure agreement rather than an open programme, because the customer surface is too regulated for a fully public programme.

Related reading

• AI audit logging under the EU AI Act
• Provider routing governance
• Connecting to the Ciralgo proxy
• What is an EU-hosted LLM proxy?

Last refreshed: 9 July 2026. This page is reviewed quarterly.