Platform

Bring AI usage into focus

See every AI service your people and workloads talk to, then set policy per identity — allow, block, or log. No browser agents, no key sprawl, no surprises on the invoice.

Policy gate metering data streams toward an AI core

Visibility and auditability for every AI interaction

Everyone is adopting AI — now it's time to understand what it's used for, who is using it, and what it costs. Every request is logged and attributed to an identity: know exactly who called which model, when, and how many tokens it burned. Audit trails exist on day one, not after the first incident review.

ai-audit — live
mei@corpllm-xl · summarize ticket1.2k tokALLOW
ci-botembed-v3 · nightly index84k tokALLOW
sam@corpllm-xl · prompt matched PII rule6.1k tokLOG
unknown-devimg-2 · bulk generation210k tokDENY
mei@corpllm-mini · quick rewrite0.8k tokALLOW
Every row attributed to an identity — humans, agents, and CI jobs alike.

Cut through the blur of fragmentation

Rapid AI adoption leaves a sprawl of tools, providers, and copied credentials — no central inventory, no consistent controls, no single place to make a change. OpenVLAN gives you one gateway endpoint per provider, a live inventory of everything in use, and access tied to identity instead of keys you hand out and hope for the best.

endpoints — one gateway
provider:alphaone key, held by gatewayrotated 2h agoLIVE
provider:betaone key, held by gatewayrotated 2h agoLIVE
self-hosted:gpu-ano key — mesh identityprivate endpointLIVE
provider:gammanot yet connected—ADD
Adding a provider is a config change. Revoking one is a single policy line.

Develop with the agents you already use

OpenVLAN meets your workflows where they are. Terminal agents, IDE plugins, CI pipelines, and notebook runtimes all work through one gateway — anything that can point at a custom base URL is supported, with no SDK to adopt and no vendor lock-in. Self-hosted open-weight models and hosted endpoints sit behind the same policy.

agents — bring your own
Terminal agent IDE plugin CI pipeline Notebook runtime MCP tool host Custom base URL
Anything that can set a custom base URL works — no forked clients, no lock-in.

AI governance without a separate identity system

The same identities, groups, and devices you already manage become the trust boundary for every AI call.

Model access policy

Decide which teams may call which models, from which devices, during which hours. Everyone else gets a clean 403.

Prompt & payload audit

Sampled or full request logging, with PII-pattern alerts, streamed to the SIEM you already run.

Vendor isolation

Each provider sits in its own ACL scope, so a leaked token never becomes lateral movement.

Data-path audit

Per-identity egress logs show exactly which teams sent bytes to which provider, and when.

Agent identity

Every automated workload gets its own node identity and policy scope — not a borrowed human login.

Egress allow-lists

Model runtimes reach exactly the hosts they need — vector stores, registries, telemetry — and nothing else.

Same policy, dev to prod

One identity, one rule everywhere. No environment-specific credentials to manage or forget.

Rate & spend guards

Per-team request and token ceilings catch runaway agents and prompt loops before the invoice does.

Shadow AI inventory

A live inventory sorted by users, traffic, and department — not a survey you email around once a year.

SSO-based access

Users authenticate with the identity provider you already run. No new accounts to create or sync.

One endpoint per provider

Provider credentials live in one place. Adding one is config; revoking one is a policy line.

Instant offboarding

Disable the account in your IdP and AI access — like network access — dies with it, in seconds.

Questions and answers

Do users still need provider API keys?
No. One key per provider lives at the gateway; callers authenticate with their network identity. Keys stop being something you distribute, rotate by hand, and eventually find committed to a repo.
Does it work with our coding agents and frameworks?
Anything that can point at a custom base URL works out of the box — terminal agents, IDE plugins, CI pipelines, and notebook runtimes. No forked clients, no SDK lock-in.
What about self-hosted or open-weight models?
Proxy them like any other service. The endpoint stays private on the mesh with no public listener, and callers reach it under the same identity policy as hosted providers.
Can we ship logs to our SIEM?
Yes — stream or batch export to S3-compatible sinks, every record attributed to an identity, a model, a provider, and a token count.
Do we have to adopt the whole network to use this?
It runs standalone, but it's strongest on the mesh — where identity is already proven at connect time and policy applies before the first byte moves.
Does it work in CI and containerized environments?
Yes. Agents run in containers or CI jobs and reach the gateway over the mesh, with neither the agent nor the endpoint exposed to the public internet.
How fast do policy changes apply?
Immediately. One edit, versioned and reversible — no redeploy, no agent update, no waiting for the next release train.
Can we shut off one provider for the whole company?
One policy line. Approved providers pass; everything else is blocked or logged per group — and the change itself lands in the audit trail.

AI governance, without the hassle

Turn on OpenVLAN, watch the inventory populate, then decide what stays. Your first answers arrive in about ten minutes.