Securing the gateway every prompt passes through

A gateway concentrates risk, so it deserves its own review. It holds credentials for many providers. It sees prompts that may contain customer data, source code or secrets. It decides which model, and therefore which third party, receives each request. And it can be abused, by a leaked key or a runaway loop, to spend money quickly.

The controls below answer those four risks in order: credential theft, data exposure, wrong-destination routing and cost abuse. A fifth section covers how you can see what happened afterwards.

• Encrypted storage. A workspace's own provider keys are kept in a secrets manager, not in application configuration or the browser.
• Decrypted at call time. The key is decrypted when a request needs it and cached only briefly.
• Never sent to the client. Applications authenticate to Connect with their own API keys; they never receive provider keys.
• Order of use. A workspace's key is used first, then platform access, so a customer's key is never silently replaced.
• Your boundary. In a self-deployed Connect, keys live in your own secret store and are used from your network.

Every gateway call is authenticated and tied to a workspace. Reading audit data requires an explicit workspace read permission. Permissions are scoped to the workspace so one team's activity and credentials are not another's. For self-deployed environments, the license model includes single sign-on, and audit logging is a licensed capability as well. These controls are part of the Identity and Access facets of the Trust and Governance Fabric that runs through the platform.

Content policies evaluate a request body against rules. Built-in detectors cover common secrets, including cloud access keys, repository tokens, private-key blocks, signed tokens and API keys, and common personal-data patterns such as email addresses, phone numbers and identifier formats. You can add your own patterns. A matching rule can redact the content, replacing it with a placeholder, before the request is forwarded, and can raise an alert.

Pattern-based detection is a safety net, not a guarantee. It will not catch every sensitive value, and it does not replace deciding which data a workload may send at all. Treat it as one layer alongside provider choice and, for sensitive workloads, self-hosted models.

• Rate limits. A per-workspace limit on concurrent requests prevents one client from exhausting the gateway or a provider.
• Usage caps. Daily token and monthly spend caps, per workspace or per model.
• Automatic downgrade. When a cap is reached the gateway can switch to a cheaper model instead of failing the request.
• Alerts. Email and webhook notifications when thresholds are crossed.

Usage is metered per workspace, and action audit events are recorded and readable through an authenticated API. Together with the per-model analytics in the Connect dashboard, they let a reviewer reconstruct who called which model, when and at what cost. For the chain from data to model to agent to action, see the AI audit trail guidance on the SecOps pages.

API traffic uses TLS 1.2 or later, with TLS 1.3 preferred. Databases are encrypted and object storage is encrypted. Customer data in the managed service is stored in AWS eu-west-1 (Ireland). Where isolation is the requirement, a self-deployed Connect runs inside your network, and the dedicated cloud provides private capacity run for you.

Swfte does not hold a SOC 2 report or an ISO 27001 certificate and does not sign HIPAA Business Associate Agreements today. A SOC 2 Type I audit is in preparation; the trust page has the current status. The trust centre is the source of record and lists anything still in progress.

• Zero-data-retention agreements with model providers are in progress. A provider you route to processes requests under its own terms.
• Customer-managed encryption keys are designed for dedicated deployments and are not generally available today.
• This page describes controls, and makes no uptime or latency commitment.
• Swfte does not claim end-to-end encryption of prompts. The gateway must read a request to route it.

Swfte provides the technical controls, governance mechanisms and evidence required to deploy AI within an organization's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration.

• Self-deploy Connect

  Keep keys and traffic inside your network.

• EU-first routing

  Provider choice and data handling.

• Providers

  BYOK and the providers Connect routes to.

• AI audit trail

  Traceability from data to action.

• Is ChatGPT private?

  What OpenAI says it does with your data, by plan.

• Models and routing layer

  Connect as the model gateway and routing layer of the platform.

• Sovereign infrastructure

  Where AI runs, from managed to dedicated.

• Dedicated cloud

  Private capacity operated for you.

• GPU and inference

  GPU capacity for the models Connect routes to.

• Deploy open-source models

  The catalogue of open-weight models you can host.

• LLM API guides

  Provider and model reference pages.

• Trust centre

  What Swfte can show today.

• Sub-processors

  Providers and services Swfte itself relies on.