Introduction

About Inferada

Inferada is a managed AI gateway from Servada. Your application uses one base URL and one bearer token; the gateway routes requests and applies the controls configured for your organisation.

Use Inferada to give applications a consistent interface to models and supporting AI services. Teams can change providers, add locally hosted models, and apply shared policy without rebuilding those concerns in every client.

What Inferada handles

  • Model and service routing. Configure locally hosted and external upstreams, then address the resulting models and services through the same API. Clients do not need provider-specific credentials or request code.
  • PII detection and redaction. Detect personal data directly, or replace detected values with placeholders before an external model call and restore matching placeholders in the response. Detection is best-effort; see the PII documentation for its limits.
  • Request policy. Processors can reject a request when they detect PII, a suspected prompt-injection attempt, or a route that is not classified as local. They provide defence in depth, not a substitute for application-level security controls.
  • Tool execution. Attach gateway-managed tools to a model and let Inferada execute the calls, or send your own function definitions and execute the returned calls in your client.
  • Usage controls and audit data. Attribute requests to organisations, users, and tokens; apply rate, concurrency, and spending limits; and inspect request history in the portal.
  • Managed applications and agents. Provision supported applications or run scheduled and webhook-triggered TypeScript agents with their own credentials and usage attribution.
  • Organisation boundaries. Models, upstream credentials, tools, limits, applications, and request history are configured in an organisation context.

Request flow

Your applicationInferada gateway (Servada)• Auth + per-org scoping• PII redact → restore• Configured service + model routing• Function-calling tools + processors• Spend + usage tracking• Audit log (PII-redacted)Local modelswhen configuredExternal providerswhen configured

When it helps

  • You need one application interface for models from several providers, including local deployments.
  • Several teams need the same authentication, policy, usage, and audit controls.
  • Some workloads must use locally classified upstreams, while others may use external providers.
  • Your application needs configurable PII handling, prompt-injection checks, or tool execution around a model call.
  • You want to provision supported chat or workflow applications without operating each application stack yourself.