DocsRoles Overviewdevops
PROFESSIONAL PLAYBOOK

Implementation Guide for: DevSecOps / ML Engineer

Integrating security should not require hardcoding interceptors into your Python ML pipeline or slowing down CI/CD. Spectorn uses a gateway-first rollout: point your OpenAI-compatible client at Spectorn, configure providers, and keep policy as code where useful.

Measured
LATENCY
Measure latency on your provider, region, prompt size, and stream mode before committing to any formal availability terms.
YAML
CONFIG-AS-CODE
Declarative `spectorn.yaml` easily versioned in Git alongside ML code.
Binary
DEPLOYMENT
Static binaries (Go/Rust/C) with no massive Python dependencies.

Gateway-first integration

Your application sends OpenAI-compatible traffic to Spectorn. The gateway authenticates the tenant, scans request and response content, and routes safe requests to configured providers.

  • Reproducible CI/CD BuildsRun `spectorn scan --ci` inside GitHub Actions or GitLab CI to automatically execute red-team scans against staging models before production release.
  • Metrics & ObservabilityNative Prometheus metrics export and syslog integration out of the box. Easily plug Spectorn telemetry into Grafana and your existing centralized logging stacks.

DevSecOps / ML engineer playbook

Note

On the RU paid gateway Spectorn works as an OpenAI-compatible gateway: the application points base_url at https://api.ru.spectorn.ai/v1, and Spectorn authenticates the tenant, scans the input, selects a provider, forwards the safe request and scans the response. On Global only protection is available — /v1/scan works, routed chat/completions is rejected server-side.

1. Minimal integration

Python
from openai import OpenAI import os client = OpenAI( base_url="https://api.ru.spectorn.ai/v1", api_key=os.environ["SPECTORN_API_KEY"], ) response = client.chat.completions.create( model="openrouter/deepseek/deepseek-chat", messages=[{"role": "user", "content": "Say ok."}], max_tokens=64, )

A real chat/completions call needs an upstream provider. You can:

  • store it in the dashboard on the Providers page;
  • add it through PUT /v1/providers;
  • pass it as BYOK via X-Provider-Key, if the route is configured for a default upstream.

/v1/scan is the fastest gateway smoke test: it only needs a Spectorn key and never calls an external model. It is also the only one of these paths available on Global.

2. Providers as code

Shell
curl -X PUT https://api.ru.spectorn.ai/v1/providers \ -H "Authorization: Bearer $SPECTORN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "openrouter", "base_url": "https://openrouter.ai/api/v1", "api_key": "'$OPENROUTER_API_KEY'", "is_default": true }'

Keep provider settings as part of tenant bootstrap. Provider keys are encrypted on the gateway side and are never returned to the UI or API in cleartext.

3. CI/CD checks

Before releasing your application, run:

  1. GET /v1/health — the gateway is alive and reports its build.
  2. POST /v1/scan with a benign and a malicious payload — verifies the fail-closed path.
  3. POST /v1/chat/completions against a short cheap model — verifies provider routing and the billing path (RU only).
  4. A check that X-Spectorn-Session is only used where gateway memory is wanted.

4. Observability

Watch more than latency:

  • the share of blocked and shadow verdicts;
  • provider route, model and fallback;
  • the errors no_provider, model_blocked, provider_unreachable;
  • usage and cached tokens for the economics;
  • the tenant scan-mode policy: enforce or shadow.

Latency is not a universal network promise: measure it for your own region, provider, model, prompt size and stream/non-stream mode.

5. What we do not claim

  • There is no requirement to point the application at a local sidecar port on the hosted path.
  • There is no blanket latency promise for a network API.
  • There is no "magic" protection without a provider or model: scan is available immediately, chat needs an upstream and is not part of Global Free.
DevSecOps / ML engineer playbook | Spectorn