CORPORATE AI GOVERNANCE LAYER

Your company runs on AI.
Are you governing it?

One layer between your teams and any LLM: block sensitive data, control cost, approve models, isolate access — without switching tools.

5 FRONTS · 1 KEY · ANY PROVIDER
PULSE CONSOLE · DLP SHIELDPRE-CALL
MODE4 violations intercepted — in this test
TRAIL RECORD · MASKED
Summarize the customer record: card [CARD MASKED], CPF [CPF MASKED], contact . Use key [SECRET REMOVED] to pull the history.
VIOLATION LOGGED · PROMPT PROCEEDS
DETECTS: CARD (LUHN) · CPF (CHECKSUM) · API KEY · E-MAIL1 of 5 controls · runs in your browser — nothing is sent
— WHERE IT HURTS
5 FRONTS · 1 LAYER

Governance has 5 fronts. Start with yours.

SCROLL TO FLY THROUGH THE 5 FRONTS
01 · DATAIs bank data leaving in prompts?Real-time DLP: masks or blocks before the provider.02 · COSTHow much does your company spend on AI — and who spends it?Per-team budgets, threshold alerts, cut-off on overrun.03 · ACCESSWho can use what?Multi-tenant, RBAC and credentials that never leak.04 · MODELSWhich model is approved for use?Governed catalog, default-OFF; non-approved → 403.05 · CONNECTIVITYAnd when AI leaves the chat window?WhatsApp, IDEs and agents behind the same layer.
— THE LAYER
BETWEEN THE COMPANY AND THE MODEL

One layer between your company and any LLM.

Nobody talks to the provider directly. Every request crosses the layer — and that is where your rules apply: data inspected, cost counted, model checked, access verified, everything logged. Your team keeps its tools; the company gains control.

YOUR COMPANY
teams · apps · agents · IDEs
HorseLabs.
GOVERNANCE LAYER
DATACOSTMODELSACCESSCONNECTIVITY
governed requestresponse
LLM PROVIDERS
Anthropic · OpenAI · Google · xAI
— THE 5 FRONTS
HONEST STATUS · PER FEATURE

What the layer governs.

PILLAR 01 · DATA GOVERNANCE

What stops bank data from leaving in a prompt?

Every prompt that leaves your company crosses the layer first — and that is where sensitive data stops. The DLP Shield inspects the content before the request reaches the provider: deterministic rules detect credit-card numbers (with Luhn checksum), CPF, e-mails and credentials; an NLP layer catches person names and PII that rules can't reach. The policy is yours, per team: monitor, mask or block. When the policy is set to block and the detector becomes unavailable, the request is stopped — fail-closed, because protecting the data is the default. Every exposure attempt becomes an audit record with user, data class and timestamp, without ever persisting the data in the clear. You discover the Shadow AI that already exists, lock down what must not leave, and keep proof of every decision.

  • DLP Shield (deterministic + NLP)
  • Real-time Exposure Alert
  • Protection Policies (Off · Monitor · Block + regex)
  • Violation Trail (masked)
  • Exportable Compliance ReportCOMING SOON
PILLAR 02 · COST GOVERNANCE

How much does your company spend on AI — and who spends it?

Each team gets a virtual key — and the key carries the budget. AI spend becomes visible per user, per key, per team and per cost center, in real time, whatever the provider. You set the budget; the layer alerts when consumption crosses the threshold (webhook into your workflow) and cuts off when it overruns — the brake is enforcement, not a report. Every request is logged: who called, which model, how many tokens, how much it cost. It is the end of the surprise invoice and of invisible spend scattered across personal accounts: a single point of passage, a single statement, and the AI bill becomes a budget line someone actually governs.

  • AI Cost Center (spend per user · key · team)
  • Budget Brake (threshold + webhook + cut-off)
  • Request Log
  • Calendar ResetCOMING SOON
PILLAR 03 · ACCESS & IDENTITY

Who can use what — and with which key?

Governance starts with who can do what. The layer isolates each organization and each department in its own tenant, with strictly scoped roles — operator, administrator, member: one department's admin cannot see another's, and nobody sees what they don't govern. Provider credentials live in a vault and never reach the end user: whoever uses AI gets a virtual key, not the provider's key. Sensitive actions require a second factor (step-up 2FA), login is protected by MFA and rate-limiting, and every access and every secret reveal lands in the audit trail. You can roll AI out to the whole company without handing out secrets, without mixing departments, and without losing the record of who did what.

  • Multi-tenant Isolation (RBAC)
  • Credentials Vault (Vault + step-up 2FA)
  • Hardened Access (MFA + rate-limit + audit)
PILLAR 04 · MODEL GOVERNANCE

Who decides which model your team can use?

Today, each employee decides alone which model to use — and the company finds out later. In the layer, the model catalog is governed: everything starts off (default-OFF), and only what an administrator approves goes into use, per organization and per cost center. A team calls a non-approved model? The answer is a 403 — before a single token is spent. And because the layer speaks the OpenAI-compatible standard with every provider, approval creates no lock-in: Claude, GPT, Gemini and Grok sit behind the same key, and switching models becomes a governance decision, not a migration project. The catalog stays current with each provider's live models — you approve in the console, enforcement happens at the gateway.

  • Governed Catalog (default-OFF allowlist)
  • Universal Gateway (Claude · GPT · Gemini · Grok)
PILLAR 05 · CONNECTIVITY

And when AI leaves the chat window?

Governance only works if it reaches where AI actually operates — and less and less of that is a chat window. The layer exposes the gateway through the OpenAI-compatible standard: the tools your team already uses (IDEs, agents, scripts, internal tools) point to it by swapping one URL, and inherit DLP, budget and allowlist on every call. Operations leave the dashboard too: budget and violation alerts arrive on WhatsApp, where the manager actually is. This is the platform's newest front — the labels below say exactly what already runs and what is in validation.

  • WhatsApp Operations (alerts · reports)BETA
  • Works in your IDE (OpenAI-compatible standard)IN VALIDATION
— HOW IT WORKS
1 REQUEST · 5 CONTROLS

The path of one request.

The 5 fronts are not 5 products — they are one cycle. Every AI call your company makes crosses all of these controls, in this order, in milliseconds.

Pipeline of a request through HorseLabsThe request leaves the app, is authenticated by the virtual key, passes the model allowlist, the DLP shield and the budget brake, reaches the LLM provider and is recorded in the audit trail.01APPyour tool02VIRTUAL KEYsk-hl-…03ALLOWLISTapproved?04DLP SHIELDpre-call05BUDGETwithin limit?06PROVIDERanthropic/…07TRAILauditable
  1. 01APPyour tool
  2. 02VIRTUAL KEYsk-hl-…
  3. 03ALLOWLISTapproved?
  4. 04DLP SHIELDpre-call
  5. 05BUDGETwithin limit?
  6. 06PROVIDERanthropic/…
  7. 07TRAILauditable

One URL, one key — and every request becomes governed.

— INSIDE THE DATA PILLAR
DETECT → MASK → AUDIT

Sensitive data stops before it leaves.

01 · DETECT

Two detection layers

Deterministic rules catch bank data — credit-card numbers (Luhn) — plus CPF (with checksum), e-mails and credentials. The NLP layer catches person names and PII that rules can't reach. All pre-call — the prompt hasn't left yet.

02 · MASK

Mask or block, by policy

The data becomes a placeholder before the provider — or the request is refused (HTTP 400 · content_blocked). If the detector goes down while the policy says block, the call doesn't pass: fail-closed.

03 · AUDIT

A trail without a second leak

Every violation recorded with user, data class, model and timestamp — with the data already masked inside the trail itself. You prove control without creating another clear-text copy of the data.

— NO ILLUSIONS
THE HONESTY CONTRACT

What we are. And what we are not.

What we deliver

  • A control layer in the request path: blocking, masking, budgets and allowlists applied in real time — enforcement, not recommendations.
  • Visibility: who uses AI, with which data, on which model, at what cost — at a single point of passage.
  • A trail: every violation, every cut-off and every approval recorded, with sensitive data already masked.

What we don't promise

  • Governance is not compliance-solved. No tool — ours included — makes you "compliant" on its own: compliance involves process, legal and people.
  • Every relevant LLM provider is foreign. International data transfer is intrinsic to using AI — we deliver control, reduction and proof over what leaves, not the illusion that nothing does.
  • We don't replace your DPO, your legal team or your policy. We give them the technical layer and the evidence they were missing.
— TIME TO CONTROL
3 STEPS · NO MIGRATION

Three steps to your first governed request.

STEP 01

Point the base_url

The layer speaks the OpenAI-compatible standard. Your tools stay the same — they just start pointing at the gateway.

STEP 02

Create the virtual key

Each team gets its own. The provider's key stays in the vault — nobody hands out secrets anymore.

STEP 03

Set budget and allowlist

Budget per cost center, approved models per department. From then on, every call is governed.

SETUP · TERMINAL
# 1 · point your tool at the layer
export OPENAI_BASE_URL="https://gateway.horse-labs.dev/v1"  # URL provided at onboarding

# 2 · use your team's virtual key (not the provider's)
export OPENAI_API_KEY="sk-hl-sales-…"

# 3 · done — DLP, budget and allowlist apply to EVERY call
— FREQUENTLY ASKED QUESTIONS
WHAT THE COMMITTEE ASKS

What they ask before starting.

It is a software layer that sits between the company's tools and the LLM providers and applies the organization's rules to every request: it blocks or masks sensitive data, controls spend through budgets, restricts which models can be used, isolates access per department and records everything in an audit trail. HorseLabs implements this layer across 5 fronts — data, cost, models, access and connectivity — behind a single key, for any provider.

Every prompt passes through the gateway before the model. The DLP Shield inspects the content pre-call: deterministic rules detect bank data — credit-card numbers (Luhn) —, CPF, e-mails and credentials; an NLP layer detects person names and PII that rules can't reach. Depending on the team's policy, the data is masked or the request is blocked before it leaves — and the violation is recorded in the trail, with the data already masked.

Not on its own — and be wary of anyone who promises that. Compliance involves process, legal basis, contracts and people; no tool "solves" it. What HorseLabs delivers are the technical controls that sustain your posture: blocking and masking of personal data before the provider, a violation audit trail and access isolation. And let's say it plainly: every relevant LLM provider is foreign, so international data transfer is intrinsic to using AI. We give you control, reduction and proof over what leaves — not the illusion that nothing does.

No. The layer speaks the OpenAI-compatible standard: anything that already works with that standard — IDEs, agents, scripts, internal tools — starts pointing at the gateway by swapping the base_url and using the team's virtual key. The employee keeps their workflow; the company gains control.

Fail-closed. When the team's policy is set to block and the detector becomes unavailable, the layer stops the request instead of letting it through. Protecting the data is the architectural default — not a setting someone forgets to turn on.

Each team uses a virtual key with its own budget. Spend shows up in real time per user, key, team and cost center. When consumption crosses the threshold you set, the layer fires an alert (webhook into your workflow); when it overruns, it cuts off. And every request is logged: who, which model, how many tokens, how much it cost.

Claude (Anthropic), GPT (OpenAI), Gemini (Google) and Grok (xAI), behind the same key and the same API standard. The catalog is fed by each provider's live models and governed by an allowlist: everything starts off, and only what an administrator approves goes into use. A non-approved model gets a 403.

Each organization and each department lives in its own tenant, with strictly scoped roles (operator, admin, member). Provider credentials live in a vault and never reach the end user. Sensitive actions require a second factor, and every access lands in the audit trail.

It depends on scope — operation size, number of departments/tenants and request volume. The investment structure is at horse-labs.dev/pricing; scope and metric are defined before we start, with no surprises.

By requesting access through the form on this page — a corporate e-mail and your team size are enough. We are in a validation phase with selected companies: the founder replies within 1 business day.

Go deeper: enterprise AI governance guide →

— GLOSSARY
8 TERMS · NO EMPTY JARGON

The terms that show up in your meeting.

Shadow AI
Employees using AI tools outside the company's control — personal accounts, extensions, unapproved agents. It is the blind spot the governance layer makes visible and governable.
DLP (Data Loss Prevention)
The set of controls that keeps sensitive data from leaving the perimeter. For AI, it means inspecting every prompt before the provider and masking or blocking CPF, cards, credentials and PII.
AI governance
A company's ability to apply its rules to AI usage — over data, cost, models, access and channels — with real-time enforcement and an audit trail, not just a policy on paper.
Multi-tenant
An architecture where each organization or department operates in an isolated space (organization), with data, keys, budgets and permissions that never mix.
Fail-closed
An architectural decision: if the security control becomes unavailable, the request is stopped rather than passed through uninspected. The default protects the data, not the convenience.
International data transfer
Sending personal data outside the country. Since the relevant LLM providers are foreign, it is intrinsic to using AI — governance's job is to control, reduce and prove what leaves.
Virtual key
A credential issued by the layer to each team or person, in place of the provider's real key. It carries the access profile: allowed models, budget and identity for the trail.
Model allowlist
The list of models approved for use, per organization and cost center. Default-OFF: anything not explicitly approved is refused with a 403, before tokens are spent.

See the full glossary →

— REQUEST ACCESS

Ready to govern?

We are opening access to companies in our validation phase. Tell us your scenario — the founder will reach out to understand where it hurts first.

VALIDATION WITH SELECTED COMPANIES
No spam · no commitment
Request access →