Log in Sign up
How it works

One gateway in front of every model

Your applications talk to one familiar API. The gateway does the rest, in the same order every time.

How a request flows through LyfeAI Firewall Applications send requests to LyfeAI Firewall, which authenticates, scans, optimises and routes them to AI providers. Responses return through the same firewall where they are scanned, restored and logged. YOUR APPS Copilots and chatInternal toolsAI agentsScripts and SDKs LyfeAI Firewall llmfw.peritusdigital.com.au/v1 1 Authenticate, policy, budget2 Scan: PII, secrets, injection3 Optimise, cache, route4 Scan response, restore, log Audit log, spend tracking and OpenTelemetry export AI PROVIDERS OpenAIAnthropicAzure AI FoundryAWS BedrockGoogle GeminiMistral and self-hosted request response
  1. Your app sends a request

    Any OpenAI or Anthropic SDK, with a gateway key instead of a provider key.

  2. Authenticate and apply policy

    Key, team, model permissions, budget and rate limit are checked first.

  3. Scan the request

    PII, secrets and prompt-injection checks run. Content is redacted, tokenised, blocked or just monitored.

  4. Optimise and route

    Safe prompt clean-up, cache lookup, then the best model for the job, with failover ready.

  5. Provider responds

    The gateway holds the provider keys. Your apps never do.

  6. Scan the response and restore

    Response DLP runs, tokens are restored, and spend and audit records are written.

Stage 1

Authenticate and apply policy

The gateway key identifies the application, team and user. The policy attached to it decides which models are allowed, what the budget and rate limit are, and which protections are on.

Stage 2

Scan the request

Detectors look for personal information (including Australian identifiers), secrets and credentials, and prompt-injection patterns. Each finding is handled by the mode you chose: monitor, redact, tokenise or block.

Stage 3

Optimise

Safe normalisation trims wasted tokens. The cache is checked: exact match first, and similarity matching only if you have enabled it.

Stage 4

Route

The router picks the model within what the key is allowed to use and records a plain-language reason. If the provider fails, retries and failover take over.

Stage 5

Scan the response

Output is checked with the same detectors. Tokens swapped in earlier are restored so your application receives a natural answer.

Stage 6

Record

Usage, cost, savings and policy actions are attributed to the key, team, user, model and provider, written to the audit log and exported over OpenTelemetry if configured.

Getting started

Live in three steps

  1. Request access

    We set up your organisation and Microsoft Entra sign-in.

  2. Choose a policy preset

    Start in monitor mode, review what would be caught, then enforce.

  3. Swap the base URL

    Give each app a gateway key and point your SDK at the gateway.

Designed to fail safe

If a provider is unavailable, approved failover models take over. If a request breaks a blocking rule, your application receives a clear error rather than silence.

Detection is probabilistic. We recommend running in monitor mode against representative data before turning on blocking.

Developer docs

Put a firewall between your people and AI

Request access and we will help you set up your first policy, key and budget.

Request access Talk to us