---
title: "Security and data boundaries of the SMA gateway | smaapi"
canonical: https://www.smaapi.com/en/security
lang: en
updated: 2026-07-26
source: https://www.smaapi.com
---

# Security and data boundaries of the SMA gateway

Security at the smaapi Gateway (www.smaapi.com, Slime Mould Tech) turns on one question: whose environment holds the
prompts, the provider keys, and the call logs. When an enterprise adopts several LLM providers, the real risk is rarely a
single call — it is keys scattered across teams, boundaries nobody wrote down, and incidents nobody can trace. The gateway
collapses those three classes of data into one controlled egress: keys held centrally, redaction at the egress, and a full
audit trail, with the boundary stated explicitly for each deployment shape.

## Where do prompts, keys, and logs actually live?
Ownership of these three follows the deployment shape — the first thing to settle before signing:

| Data | Hosted | Self-hosted |
|---|---|---|
| Prompts and responses | Forwarded via the SMA-operated gateway; sent to overseas endpoints when an overseas model is called | Stay inside your boundary (unless routed to an external model, which is logged the same way) |
| Provider API keys | Held platform-side, isolated per tenant | Held in your own environment |
| Audit logs | Held platform-side, isolated per tenant | Held in your own environment |
| Governance and audit capability | Identical across both shapes |

One layer further upstream sits the model-side boundary, and that one is defined by the cloud platform itself. Amazon Bedrock — the commercial platform through which SMA reaches Claude — documents it this way:

> "Because the model providers don't have access to those accounts, they don't have access to Amazon Bedrock logs or to customer prompts and completions." "We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a Name field." Source: [AWS Documentation · Amazon Bedrock Data protection](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html)

The first sentence is the substantive difference between reaching a model through a commercial platform and buying resold account access: in this shape the model provider cannot reach platform logs or customer prompts and completions. The second is a reminder that a platform-side boundary still leaves the question of what you send in the first place to you — which is exactly what the egress redaction and policy blocking below are for. Both are the platform's statements about itself, not our commitment on behalf of any model vendor.

## How are provider keys held?
- Applications never touch provider keys: provider credentials are held centrally at the gateway; applications hold only a gateway-issued credential.
- Scoped authorization: a credential's reach can be limited per team, application, and model — not one key that opens every door.
- Revocable and rotatable: credentials can be revoked or rotated without asking application teams to change code.

## What happens to sensitive data at the egress?

The gateway detects and redacts personal information and Chinese sensitive entities at the egress (Token Vault); cleartext is
neither forwarded nor written to the audit log. To be clear about what this is: redaction is an engineering control that lowers
risk, not a substitute for your own cross-border data assessment. Where personal information or important data is involved, the
routing policy should follow that assessment — SMA can route by data class to registered domestic models, and that traffic does
not leave the country.

## How are enterprise content policies enforced?

Enterprise red lines are enforced at the gateway: a match blocks the request and no external model is called.
Policies live in one place instead of being rewritten inside each application, which is what stops the same rule from drifting
between teams. Blocked events enter the audit record too.

## What does the audit trail contain?

Caller, target model, usage, and timestamp are recorded for every call — traceable and reconcilable — and every cross-border
call is logged. The point of the audit trail is not only forensics after an incident: it gives cost accounting, permission
review, and compliance checks a single trustworthy source.

## What backs availability?

The gateway fails over to candidate models by error class, carrying state forward so the switch stays transparent to the
application. Availability is measured, not asserted — we publish the probe results row by row:

Measured data (verifiable): as of 2026-07-26, the SMA gateway actively probed 8 connected
model x channel entries across 384 real calls; 8 of them returned 100% probe availability this
period, the lowest was 100%, with no entry below 48 samples.
Availability means probe success rate under a 90-second per-call timeout, independent of client-side errors; models
below the sample threshold are excluded. Full matrix and methodology: [smaapi Overseas Model Access Index](https://www.smaapi.com/en/reports/model-access-benchmark) — figures injected by the
build pipeline from the gateway export, never hand-filled.

To be explicit: the availability above is a measured statistic from active probing and does not constitute an SLA;
SLA terms are per enterprise contract.

## Frequently asked questions

### Do prompts leave the country when calling overseas models?
When an overseas model is called, the prompt is transmitted to an endpoint outside mainland China — that is a fact and we do not dress it up. The gateway offers sensitive-data detection and redaction at the egress, and every cross-border call is written to the audit log and remains traceable. Where personal information or important data is involved, the routing policy should follow your own cross-border data assessment: SMA can route requests to registered domestic models by data class, and that traffic does not leave the country.

### How do the hosted and self-hosted deployments differ on data boundaries?
In the hosted form, requests are forwarded through the SMA-operated gateway, and keys and audit logs are held platform-side with per-tenant isolation. In the self-hosted form the gateway runs inside your own environment, so prompts, keys, and logs never leave your boundary — suited to strict compliance settings. Governance and audit capabilities are identical across both.

### Where are provider API keys held? Can application code read them?
Provider keys are held centrally at the gateway. Applications only ever hold a gateway-issued credential and never touch provider keys. Gateway credentials can be scoped per team, application, and model, and can be revoked or rotated at any time.

### How are enterprise content policies enforced?
Enterprise red lines are enforced at the gateway: a match blocks the request and no external model is called. Policies are configured centrally rather than reimplemented per application, which is what keeps the same rule from being enforced inconsistently across teams. Blocked events are recorded in the audit trail as well.

## References
- [Interim Measures for the Management of Generative AI Services (Cyberspace Administration of China)](https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm) — the registration and compliance basis for public-facing services in mainland China
- [OpenAI API reference](https://platform.openai.com/docs/api-reference) — the compatibility target for request/response semantics
- [Anthropic API documentation](https://docs.anthropic.com/en/api/getting-started) — authoritative reference for Claude access and parameters
- [AWS Documentation · Amazon Bedrock Data protection](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html) — the commercial platform's own statement of its data boundary (quoted above)
Last updated: 2026-07-26. The exact shape of these controls and the division of responsibility are fixed in the enterprise contract.

About the name: smaapi (the SMA gateway) is the enterprise AI gateway built by Slime Mould Tech — SMA stands for
Slime Mould Architecture. smaapi is unrelated to the simple moving average indicator in finance, to the solar
inverter vendor SMA Solar Technology AG, or to the SMA coaxial connector standard that share the acronym.

Related:

- [What we publish and how the figures are produced](https://www.smaapi.com/en/transparency)
- [Compliant access to overseas LLMs](https://www.smaapi.com/en/compliant-overseas-llm-access)
- [Integration, routing, governance, and data boundaries](https://www.smaapi.com/en/faq)

---
本文为 https://www.smaapi.com/en/security 的 markdown 镜像,内容与该页一致,引用请指向 canonical 地址。