Ship AI safely: virtual keys, guardrails, and full observability
The last post covered the features that keep AI apps online and cheap. This one covers the other half of production readiness: the controls that let you run AI safely — knowing who's spending, controlling what goes in and comes out, and being able to prove exactly what happened.
Three features carry this: virtual keys, guardrails, and observability.
Virtual keys: stop handing out raw provider keys
In post one we described how a single raw provider key ends up copied across three services and a Slack thread, with no rotation and no per-team limit. Virtual keys fix that at the root.
A virtual key is a vk-… slug that stands in for a real provider credential. The actual provider key is stored encrypted with AES-256-GCM and never leaves the gateway. What you hand out is the slug, and the slug carries policy:
Spend and credit limits — a hard budget per key. When it's exhausted, the key stops working instead of quietly running up a bill. No more runaway-loop surprises.
Model allowlists — a key can be restricted to specific models, so a team can't accidentally (or expensively) call something it shouldn't.
Lifecycle and audit — keys have status (active, exhausted, revoked) and an audit log. Give a key to a team, watch its usage, and revoke it in one click. If it leaks, you scope the blast radius to that one key instead of your entire account.
No provider key? Use platform keys
Not every team wants to bring their own provider account just to get started. Platform keys let you run on VectorAxis's own platform credits — you top up credits, and calls are billed against them (with a transparent markup). It's the fastest path from zero to a working, budgeted AI call, and the same limits and audit trail apply.
Guardrails: checks on the way in and the way out
Once real users are typing into your product and real model output is going back to them, "the model usually behaves" isn't a safety strategy. Guardrails put an actual control in that path.
A guardrail is a named policy you apply per request with the x-guardrail header, and it can run on inputs, outputs, or both. Inside a guardrail you compose checks:
PII detection — catch emails, phone numbers, and other personal data before it's sent to a provider or before it's returned to a user.
Regex matching — block or flag patterns you care about (internal identifiers, banned terms, secret formats).
JSON-schema validation — enforce that model output actually matches the structure your app expects, so a malformed response fails the guardrail instead of crashing downstream.
LLM-judge checks — use a model to evaluate content against a policy you describe in plain language, for the judgment calls that regex can't make.
Two concrete uses:
On input — a request containing a prompt-injection attempt or a chunk of PII is caught before it ever reaches the provider.
On output — a response that leaked an email address or drifted off-policy is caught before it reaches your user.
Guardrails are defined and versioned in the platform (under Guardrails), so you can build a policy once and apply it across every request that needs it.
Observability: every request, traced
The third wall from post one was the blindfold — a customer reports something weird and you have nothing. Observability is the answer, and it's on by default.
Per-request logs
Every request is logged with what you need to actually debug it: the provider and model that served it, cost, latency, cache status, whether it retried or fell over to a fallback, and the guardrail outcome. When someone asks "what happened on this call?", you have the record.
Analytics and metrics
Beyond individual logs, you get the aggregate picture:
Cost tracking — attributed by provider, model, and organization, so the "where did the money go?" question has an answer.
Latency percentiles — p50, p95, and p99, so you're measuring the tail your users actually feel, not just the average.
Prometheus metrics at
/actuator/prometheus— request counts, durations, token counts, cost, and cache hits, ready to drop straight into your existing dashboards and alerts.
Exports for audits
When you need the raw records — for a finance reconciliation or a compliance review — logs export asynchronously so you can pull the history without hammering the live path.
Putting it together
These three features divide the job of running AI responsibly:
Virtual keys control who is calling and how much they can spend.
Guardrails control what goes in and what comes out.
Observability proves what actually happened — per request, in aggregate, and on demand.
Keys, checks, and receipts. That's the gap between a demo that works on your laptop and an AI feature you can defend in production.
What's next in the series
We've now walked the core control plane — reliability, cost, and safety. From here the series goes one feature per day into the rest of the platform:
Prompt management — a versioned prompt library with draft/publish workflow, labels, test suites, and analytics, so prompts stop living in scattered string literals.
Coding agents — native support for Cursor, Continue, and any OpenAI-compatible tool, so your dev tooling runs through the same gateway.
Documents & media — audio, images, files, batches, and the Responses API — the same gateway for every modality, not just chat.
Teams & access control — organizations, workspaces, roles, and
va_platform keys for team-wide governance.
Start free — no credit card, free tier included.