Security and compliance

How the API Platform protects requests and keys: TLS in transit, hashed single-purpose API keys, checks that fail closed, an audit trail, and where to find Safeguard's compliance reports.

In transit

The API accepts requests only over HTTPS. Plain HTTP connections and TLS versions older than 1.2 are refused. The gateway calls third-party providers over HTTPS.

API keys

A key is sg-api- followed by 64 hexadecimal characters, made from 32 random bytes.
The full key is shown once, when you create it. Safeguard stores only its SHA-256 hash, and from then on the Console shows the key masked, as its start and end. A lost key can't be recovered: revoke it and create a new one.
A key has one scope, inference. It works only with the API Platform, and nothing else in Safeguard accepts it.
A key belongs to the member who created it. On API keys, the owner can rename it, change its monthly spend limit and its requests-per-minute limit, or revoke it.
Requests with a revoked key are refused within 30 seconds.
Keys can be created only while the API Platform is switched on for the workspace. Auditors, whose access is read-only, can't create them.
Send the key as Authorization: Bearer followed by the key. A missing, malformed, unknown, revoked or expired key gets the same 401 invalid_api_key, which doesn't say which of these it was.

Checks that fail closed

If the gateway can't confirm something it needs, it refuses the request instead of guessing:

If the gateway can't check	The request
The API key	Is refused with `503 auth_unavailable`.
Your credit	Is refused with `503 billing_unavailable`. It is never served unmetered.
Whether the API Platform is on for your workspace	Is treated as off: `403 gateway_disabled`.
The providers' launch checks	Is refused with `503 model_unavailable`: no model is served until the checks can be read.
The model catalog, for more than ten minutes	Is refused with `503 model_unavailable`.

The gateway is kept apart from the rest of Safeguard. It never routes requests through the AI provider chain behind Safeguard's own product features, and it reads none of your workspace's security data. Automated tests enforce that boundary.

Provider error messages are never copied into responses. A provider failure is reported by its status code only, so a provider that echoes your request back can't leak it through Safeguard. Safeguard's credentials for each provider are held by the gateway and are never logged or returned.

Launch checks for each provider

Before a third-party model is served, Safeguard records three checks for its provider: the provider's terms allow resale at list price, the provider is on the Trust Center subprocessor list, and Safeguard's DPA, privacy notice and AI disclosure cover it. Each change to a check needs a note and is recorded with who made it and when. The model also needs a successful end-to-end test call on its current route. The gateway applies all of this on every request.

Audit trail

Event	Where it is recorded
A key is created, changed or revoked	Safeguard's audit trail, with the key's ID. The key itself is never recorded.
A request	Your request log: metadata only. See Privacy and data.
Credit is added or used	The credit ledger, with the balance after each entry.
A provider's launch check changes	With who changed it, when, and the note explaining why.
A model in the catalog changes	Every create, update, archive and restore, with the values before and after.

Compliance

Safeguard publishes the status of its compliance frameworks, including SOC2 Type 1 and SOC2 Type 2, on its Trust Center. Restricted documents such as audit reports are released there through Request access, after Safeguard reviews the request.

The API Platform is new and in early access. Before you rely on a report for it, check that the report's scope covers it.

Report a security issue

Email security@safeguard.sh, and see the responsible disclosure policy.