Technical walkthrough
How Gateway works – from purchase to AI response
Gateway is a container that runs in your environment, between your applications and the AI services you approve. This page explains the product boundaries, integration options and division of responsibility. Detailed installation, configuration and operations guidance is included in the customer delivery.
First: these are two separate systems
The customer portal and Gateway have different jobs and different data. An account at app.maskera.dev gives you access to the delivery; it is not where text is masked.
Maskera customer portal
app.maskera.dev
This is where you manage your organization, account, purchases, license and available releases. The portal builds the installation package in your browser, but never receives text, restoration keys or AI responses from your Gateway.
Gateway in your environment
Your Docker or Kubernetes cluster
This is where requests are authenticated, policy is applied and text is masked in memory. The container has no database and does not need to contact Maskera during operation.
Maskera customer portal
downloaded during installation
- Your browser
- Customer portal
- Installation package
runtime traffic
At your chosen provider
Maskera's servers are never in the path between your application and your AI provider.
From purchase to a running Gateway
The delivery is designed to keep runtime secrets and processed text in your environment.
Access in the customer portal
The organization's owner gets access to the agreed pilot or annual license and the approved Gateway release.
Version-pinned delivery
The portal gives the organization access to a signed, version-pinned delivery with a software bill of materials (SBOM).
Package for your environment
The installation package contains startup files, a license and baseline configuration. Runtime secrets are not shared with Maskera.
You deploy it
Start the ZIP package with Docker Compose or use it as the basis for Helm. You add secrets to your own secret manager and place TLS in front of the service.
The complete installation sequence, configuration, verification, update and rollback procedures are documented in the customer delivery.
What “company identity” means here
Gateway has no sign-in page, user session or employee directory of its own. It is an internal API, so identity accompanies every API request.
No additional sign-in for the user
Your application continues signing users in through services such as Microsoft Entra ID, Okta or Keycloak. The application then sends the user's OIDC token to Gateway as a Bearer token.
Two authentication options
Local API key
A local key authenticates service-to-service requests without Maskera handling the key.
- Suitable for installation tests, service-to-service requests and smaller environments
- Permissions and policy are linked to the key's configuration
- The plaintext key only needs to exist in your environment
OIDC and company identity
Gateway verifies the token against your identity provider and maps roles to permissions and policy.
- Support for Entra ID, Okta, Keycloak and other OIDC-compatible providers
- Identity and roles are controlled by your existing directory
- No user database or sign-in session in Gateway
The OIDC flow, step by step
The user signs in with you
Your application obtains a signed access token from your normal identity provider.
The token accompanies the request
The application sends Authorization: Bearer with the request to Gateway.
Gateway verifies the token
The token is verified against the identity provider and constraints you configured.
Role becomes permission and policy
Your chosen role claim is mapped to mask, proxy or metrics and to exactly one named policy. Conflicting policies are rejected.
Exact role mapping, key rotation and network configuration are documented in the customer delivery and adapted to your identity environment.
Two ways to integrate Gateway
Choose the proxy for an OpenAI-compatible chat flow. Use the masking API when you want to control forwarding yourself or use another model API.
The interface is translated, but example text and API payloads remain in Swedish because Maskera is built to mask Swedish text; it does not translate it.
1. Mask and handle the response yourself
POST /v1/mask returns masked text and, if policy allows it, a restoration map. Your application then decides where the text is sent and whether anything is restored.
Your app → /v1/mask → masked text + optional map → the rest of your code
curl -s https://maskera-gateway.ert-natverk.internal/v1/mask \
-H "Authorization: Bearer $MASKERA_GATEWAY_KEY" \
-H "Content-Type: application/json" \
-d '{
"text": "Lars Svensson ringde om fakturan.",
"return_map": true
}'2. Let Gateway protect the complete AI request
Change the base URL in an OpenAI client to Gateway. It masks text fields, calls only the exact approved HTTPS address and restores placeholders in the AI response before returning it.
Your app → Gateway → approved AI service → Gateway → your app
const client = new OpenAI({
apiKey: process.env.MASKERA_GATEWAY_KEY,
baseURL: "https://maskera-gateway.ert-natverk.internal/v1/openai",
})
const answer = await client.chat.completions.create({
model: "gpt-4o-mini",
messages: [{ role: "user", content: "Sammanfatta: Lars ringde om fakturan." }],
})The built-in proxy currently supports the OpenAI Chat Completions format. Other providers and formats can still be used through /v1/mask, with your application making the AI request.
What happens in a proxy request
Every request follows the same main sequence. An error stops the chain; Gateway never forwards unmasked text as a fallback.
Identity and policy
The request is authenticated and receives the policy linked to that identity by the server configuration.
Masking in memory
Allowed text fields are read, personal data is detected and replaced with stable placeholders. The restoration map is held in memory.
Approved AI service
The masked request is sent only to the AI service you approved.
Response to your application
Gateway restores known placeholders when required by policy and returns the response without logging the payload.
Policy is the control point
A named policy determines the same rules for every request from an identity. Among other things, it can control:
- which types of personal data should be detected
- text and request size limits
- whether a restoration key may be returned and whether the AI response should be restored
- which text fields are supported; disallowed fields are blocked instead of passing through unprotected
The policy is selected server-side. A field in the customer's request therefore cannot disable a protection required by policy.
Data, logs and network
Gateway is stateless between requests. That makes the boundary clear, but your surrounding infrastructure is still part of the system.
In memory
Original text, masked text, restoration maps and AI responses exist only while a request is processed and are not written to a Gateway database or log. Gateway has no database.
On the network
When using the proxy, only the masked request goes to your approved AI service. Gateway does not contact Maskera. Company identity can use the identity source you explicitly configured.
In logs and metrics
Gateway does not log payloads, Authorization headers or restoration maps. Operational data is limited to information such as status code, response time and text volume.
What you operate around Gateway matters too
An ingress, load balancer, APM agent or AI provider may have its own logging. You must configure these as well so they do not retain original text, headers or restored responses in ways you did not intend.
License, releases and updates
Gateway is designed to run without a continuous connection to Maskera and to let you control when your production environment changes.
Locally verified license
The license is verified in your environment. No activation server is contacted during operation.
Signed and pinned release
The container is referenced by an immutable digest, signed and published with an SBOM so the delivery can be reviewed and pinned in your change process.
You choose when to update
New approved releases become available in the customer portal. You test and deploy them when it suits your environment.
Procedures for replacing licenses, updating, verifying and rolling back are included in the customer delivery's operations guide.
What you actually buy
The Gateway license is an enterprise delivery of the masking layer in your environment. It is not a hosted AI service and does not transfer responsibility for operating your infrastructure.
Included
- Gateway container with the Swedish model built in
- Docker Compose files and Helm values
- Support for local API keys and OIDC
- Policies, OpenAPI specification and functional test
- Offline license for the agreed environments
- Signed, immutable releases with an SBOM
- Security updates and email support according to the offer
- Documentation for installation, operations and troubleshooting
Not automatically included
- Servers, Kubernetes, networking, TLS or operational monitoring
- An account, agreement or API key with your AI provider
- Configuration of Entra ID, Okta, Keycloak or your internal roles
- Changes to your applications and your own text flows
- A guarantee that automated masking finds every piece of personal data
- Legal assessment or a guarantee that your overall solution complies with every regulation
- A custom service-level agreement, installation engagement or on-call support unless separately agreed
Before production, you still need to test your real text types, choose a policy and validate identity, networking, logging and the AI provider. Those choices are customer-specific, but the product's technical boundary and delivery remain the same.
Continue at the right level of detail
This page explains the complete system. The API reference shows exact requests and errors, the data page describes the processing boundary and the pricing page shows the commercial terms.