Secure AI Gateway & Guardrails One governed path to every model you approve

No. Guardrails reduce these risks, measure them and record them; they do not eliminate them, and you should be wary of anyone who says otherwise. So we layer the controls: input filtering for known injection patterns, redaction before data leaves, output checks, least-privilege access for each application, and logs that show what happened. Because new injection techniques keep appearing, the gateway is tested before go-live and after significant changes, preferably by a team separate from the one that built it, through AI Security Assessment & Red Teaming. Data that must never leave your control belongs on a private platform rather than depending on redaction.

The difference is who calls the model: that service covers your employees using public AI tools, this one covers your own applications. Generative AI Data Protection uses DLP and web security to block or warn when staff paste or upload sensitive data, and to discover unapproved AI tools. The gateway gives your applications one governed path with identity-based access, policies, redaction, audit logs and cost limits. Many organisations need both, and we align the protected data categories so the same definitions apply in each.

It depends on the provider's enterprise terms and the settings we configure, and we show you the configuration rather than ask you to take it on trust. With open-weight models you run locally, prompts and answers stay on the platform you control. With a commercial model through its enterprise API, they pass to that provider under its terms; we switch on the settings that stop training on your data and limit retention where the provider offers them, and redact what must not leave. If the provider processes data outside the Kingdom and the prompts carry personal data, that is a transfer question under the Regulation on Personal Data Transfer outside the Kingdom. The gateway's own logs go where the design puts them, usually your SIEM, with retention and access agreed with your data protection officer.

Yes, it adds some processing time, and how much depends on which checks run. Routing and pattern-based checks add little compared with the time a model takes to answer; model-based detectors and output checks add more. When answers are streamed as they are generated, you choose per application between holding text back until it is checked and showing it straight away, in which case output checks can stop an answer only after part of it has appeared. We measure the effect before go-live on requests representative of your real use and set the checks per application, so a low-risk internal tool need not carry the same checks as an application that handles personal data.

In most cases, yes: applications call the gateway's single interface, so changing or adding a model is a configuration change. Features that only one provider offers, such as particular tool-calling or file-handling options, may still need application changes, and we list them in the design. A different model also answers differently, so before you switch, the application's prompts are reviewed and it is re-evaluated against the tests you rely on. Application credentials, quotas, policies and logs stay in place across the change.

Spend is controlled by quotas, rate limits and budgets set at the gateway for each user, application and team, and allocated from a usage record of every call. Each record carries the application, team and token counts, so cost goes to the cost centre that incurred it. Alerts warn before a budget is reached, and you decide whether the gateway then blocks, throttles or routes requests to a lower-cost approved model. Lower-cost routing is used only where it has been tested for that use case, because limits protect budget, not answer quality. Models you run locally have no per-call invoice, but the same records show each team's share of the capacity.

Through standard protocols and log formats, without replacing either system. Users sign in through your identity provider with single sign-on (SSO) over a standard protocol such as OpenID Connect or SAML, applications use their own service identities or short-lived credentials instead of shared keys, and groups in your directory map to gateway permissions. Logs reach your SIEM in a structured format through a collection method it supports, and we agree with your security operations team which events raise alerts, such as repeated policy blocks or unusual usage. If your identity platform itself needs work first, that is our Identity & Access service.

Yes, for the patterns we define and the detectors we configure or train, tested on samples of your data, and with limits. Structured identifiers such as national ID and iqama numbers, Saudi IBANs, medical record numbers in the formats you use, and classification markings are found by patterns, including numbers typed in Arabic-Indic digits. Names, addresses and free-text descriptions are harder, especially in mixed Arabic and English or where the same word is spelled several ways, so model-based detectors are measured on your samples in monitor-only mode before any policy blocks anything. We report what the detectors catch and miss, you set the sensitivity, and data that must never leave stays on a private platform.