Sovereign AI infrastructure for regulated industries

Pendra provides managed AI inference — chat, embeddings, image generation, and audio — to platforms that build for organisations handling sensitive, regulated, or classified data. The infrastructure exists specifically to eliminate the legal and technical risks of routing that data through foreign-owned cloud platforms.

The Pendra platform (the API, control plane, databases, and operations) is hosted in the United Kingdom, owned by a Welsh-incorporated company, and operated by vetted UK personnel. Inference runs on GPU workers in the location you choose. Choose the UK and your prompts and responses stay in the UK. Also require a UK-owned operator (UK Sovereign) and that capacity is run only by UK-owned, UK-domiciled companies, with no exposure to foreign intelligence legislation such as the US CLOUD Act, FISA Section 702, or equivalent frameworks.

These guarantees describe Pendra-managed inference. Customers who run self-hosted workers keep inference entirely within their own infrastructure and jurisdiction — see §3, Deployment Models.

Pendra is built for the platforms behind NHS trusts, government bodies, legal firms, and financial services — wherever "probably compliant" is not an acceptable posture.

Data sovereignty is the founding principle of Pendra. Our platform, including the API that receives your requests and the databases that hold your account and usage metadata, runs in the United Kingdom. Inference runs where you choose, and we keep to that choice: choose the UK and your prompts, completions, embeddings, image inputs, and audio inputs are never processed in or transmitted to any other jurisdiction.

Because no US company owns Pendra or holds the data stored on its platform or on UK Sovereign capacity, the US CLOUD Act cannot be used to compel Pendra, or the UK companies that host it, to hand that data over. The one US provider in the request path is Cloudflare, which carries traffic but stores no prompts or completions. A provider that carries traffic can still be ordered to assist with collection under FISA Section 702, Executive Order 12333 or equivalent frameworks. Where that exposure is unacceptable, use end-to-end encryption, so that anything Cloudflare could be compelled to produce is ciphertext.

On-Demand GPU Capacity

Where you need additional GPU capacity on demand, you can rent dedicated workers through Pendra and choose where they run: the UK, Europe, or anywhere. Within the UK you can also require a UK-owned operator. With it (UK Sovereign), the workload runs in a UK data centre operated by a UK-owned, UK-domiciled company. Without it (UK Hosted), the data centre is still in the UK and your data stays in the UK, but the operator may be foreign-owned. Your choice is enforced at the point of placement — if no capacity meeting it is available, the request is refused rather than placed on infrastructure that does not meet it. It is never silently downgraded.

Every provisioned rental carries an immutable audit record documenting the operator's legal entity and country of domicile, so you can independently verify the jurisdiction you were provisioned. Organisations can also set a contractual minimum standard that no placement is permitted to fall below.

Pendra supports two deployment topologies. Both share the same orchestration layer, API surface, and zero-retention guarantees, but they differ in where inference physically executes.

Self-hosted workers connect outbound to the Pendra API over WebSocket — no inbound ports need to be exposed from your network. Workers authenticate with rotating Ed25519 JWTs (30 second TTL, 60 second maximum clock skew) verified against a per-organisation public-key registry.

Pendra operates dedicated GPU workers within Tier 3+ UK data centres. Workers are isolated at the process and container level, with no shared inference state between organisations.

Physical Security

• 24/7 on-site security with biometric access controls
• CCTV monitoring with 90-day retention
• Mantrap entry systems with dual-authentication
• Environmental controls: redundant power (N+1), fire suppression, flood detection

Network Security

• All API traffic encrypted with TLS 1.2 (minimum)
• Network segmentation between inference workers, management plane, and public endpoints
• DDoS mitigation at the network edge, provided by Cloudflare (§2)
• No inbound SSH. Management access via hardened bastion with MFA and audit logging

Workload Isolation

• Each worker runs inference in a dedicated process with no shared state across organisations
• Requests are dispatched atomically to prevent cross-tenant request leakage
• Prompts and completions are held only in process memory for the duration of a single request

Logging & Monitoring

• Production system access and administrative actions are logged
• Logs are retained in a tamper-resistant store for at least 90 days
• Automated alerting on anomalous activity and security events

Secure Development

• Code review required for all changes affecting production systems
• Static and dependency analysis integrated into the development pipeline
• Separation of development, staging, and production environments

Pendra operates a strict zero-retention policy for inference data: we do not store, log, or inspect the content of prompts, completions, embeddings, image inputs, or audio inputs. The GPU worker that serves a request may cache conversation state locally to speed up follow-up messages — see the worker prompt cache below. If you call the moderation endpoint, or turn on content filtering for your API keys (it is off unless you do), the moderation model you choose checks the content on one of your organisation’s workers, which may not be the one that answers the request, and Pendra records the verdict (outcome and categories) with the usual usage metadata for the check, never the content. Like any worker, the one that runs the check may keep the checked text in its prompt cache.

Worker prompt cache. To answer follow-up messages faster, the GPU worker keeps the working state of recent conversations — including the prompt tokens — in memory between requests, and by default also on its own disk, where it can outlive the request and a restart. These copies never leave the worker host: they are not sent to Pendra or to any other worker. Disk use is capped and entries are removed least-recently-used first, and the worker’s operator can turn the on-disk tier off per worker. State from a request sent with end-to-end encryption (§7) is never written to disk. See KV cache for the controls.

We log only operational metadata: timestamp, model ID, token counts, latency, request type, and HTTP status, plus the verdict (outcome and categories) of each moderation check. This metadata contains no prompt or completion content and is used solely for billing, capacity planning, and system health monitoring, and to show you the result of each moderation check.

We never use customer data for model training, fine-tuning, evaluation, or any purpose beyond fulfilling the immediate inference request.

All API access is authenticated using API keys with the prefix pdr_sk_. Keys are hashed with SHA-256 before storage. Pendra never stores plaintext API keys.

Key Management

• API keys are generated with cryptographically secure random bytes
• Keys can be scoped with optional expiration dates
• Key usage is tracked (last used timestamp, request counts)
• Keys can be revoked instantly via the dashboard
• The full key is shown only once at creation time

Dashboard Authentication

• Dashboard access requires email-based authentication with HS256-signed JWTs
• Session tokens are short-lived and non-persistent
• Optional Google OAuth for organisations that prefer SSO

Worker Keys

GPU workers authenticate to the Pendra API using Ed25519 keypairs registered against a single organisation. Only the public half is ever transmitted to or stored by Pendra; the private key never leaves the worker host.

• Keypairs generated locally; private half never leaves the worker
• Public keys scoped to a single organisation
• Workers sign short-lived JWTs — 30s TTL, 60s clock skew
• Instant revocation via the dashboard
• Connect, disconnect, and health events audited per worker

Worker Approval

Pro and Enterprise organisations can require every worker to be explicitly approved by an operator before it can serve any traffic. The setting is off by default and is controlled per organisation.

• Until approved, a newly connected worker is visible and observable in the dashboard but is excluded from request routing and receives no customer traffic
• An unapproved worker is never issued the organisation's end-to-end encryption key
• Approving a worker both admits it to routing and provisions it the organisation's workload encryption key; rejecting it leaves the worker connected but serving nothing

Rate Limiting

Per-key rate limiting prevents abuse and ensures fair resource allocation across customers. Rate limit responses use standard HTTP 429 status codes with Retry-After headers.

In Transit

• TLS 1.2 or higher enforced on all API endpoints. TLS 1.1 and below are rejected
• HSTS headers with long max-age to prevent protocol downgrade attacks
• Certificate transparency logging enabled
• Worker-to-API WebSocket connections are wrapped in TLS and gated by Ed25519 JWT

At Rest

• Inference data is not stored at rest (zero-retention policy)
• The worker holds conversation state in host memory while it serves a request. An operating system may page memory to swap, and a machine that hibernates writes memory to disk; neither is something an application can prevent. Run workers with encrypted swap (FileVault and BitLocker do this by default; use an encrypted swap device on Linux) and disable hibernation on hosts that serve sensitive traffic
• Operational metadata and account data encrypted with AES-256
• API key hashes stored using SHA-256 one-way hashing
• Database backups encrypted and stored within UK jurisdiction

End-to-End Encryption (Private Inference)

On the Pro and Enterprise plans, requests can be end-to-end encrypted so that only your own GPU workers can read them. Your client encrypts the entire request — messages, parameters, tools, and any uploaded audio — and the worker encrypts its response back to you. Pendra's API only ever handles ciphertext together with the routing metadata needed to deliver the request; it never sees your prompts or completions in plaintext.

• Hybrid public-key encryption (HPKE, RFC 9180) using X25519 key agreement, HKDF-SHA256, and ChaCha20-Poly1305
• Both requests and responses are encrypted, including streamed responses, where each chunk is sealed individually
• Content is decrypted only in worker process memory, and no state derived from an encrypted request is ever written to disk — the worker’s on-disk prompt cache is never written to for an encrypted request
• The worker's private key exists only in memory and is never transmitted to Pendra or persisted; Pendra stores only the corresponding public keys
• Available across chat, completions, embeddings, reranking, image generation, and file-based audio transcription, as well as the OpenAI Responses and Anthropic Messages endpoints
• Organisations can optionally require end-to-end encryption across their fleet, so any plaintext request is rejected

Operational metadata (model, token counts, timing, the identifier of the key a request was sealed to, and, if you turn on content filtering, the outcome and categories of each check) remains visible to Pendra for billing and routing, exactly as described in §5 — it never includes prompt or completion content.

Pro customers are covered by our standard Data Processing Agreement. Enterprise customers receive a custom DPA and Data Protection Impact Assessment (DPIA) support tailored to their deployment.

Pendra maintains a documented Incident Response Plan (IRP) with defined severity levels, escalation paths, and communication procedures.

• Detection: Automated monitoring and alerting across all infrastructure components
• Classification: Incidents triaged by severity (P1–P4) within 15 minutes of detection
• Notification: Affected customers notified within 72 hours of a confirmed data-related incident on a best-endeavours basis, in line with our standard DPA and UK GDPR Article 33
• Remediation: Root cause analysis and remediation documented for every incident
• Review: Post-incident reviews conducted within 5 business days with published findings

All Pendra engineers with logical access to production infrastructure are:

• UK nationals or residents with right to work in the United Kingdom
• Background checks aligned with BS 7858 principles
• Bound by confidentiality agreements and acceptable use policies
• Required to use hardware security keys for all production access
• Subject to quarterly access reviews and principle-of-least-privilege enforcement

No third party has logical access to customer inference data held by Pendra. Where a worker runs on infrastructure you or Pendra rent, that provider operates the physical host: conversation state in the worker’s prompt cache is held in that host’s memory and, unless the cache’s on-disk tier is turned off, on its disk. This applies equally to workers Pendra operates and to ones you run yourself, including GPUs you rent through Pendra, which only your organisation uses; the cache stays on that host and you can turn it off per worker.

For security inquiries, vulnerability reports, or to request a copy of our Data Processing Agreement, please contact:

We acknowledge all security reports within 24 hours and aim to provide an initial assessment within 72 hours.