What is a corporate AI governance layer?

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.

How does HorseLabs stop sensitive data from reaching the LLM 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.

Does using HorseLabs solve my LGPD compliance?

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.

Do I need to replace the tools my team already uses?

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.

What happens if the data detector goes down?

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.

How does AI cost control work?

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.

Which providers and models are supported?

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.

How is access isolated between departments and companies?

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.

How much does it cost?

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.

AI data governance

AI data governance means keeping sensitive information — PII, secrets, customer data — from leaving your operation for the model provider or for uncontrolled logs. This guide details what leaks in a prompt, how to mask or block before sending, why the control must be fail-closed, and how to keep sensitive data out of logs — all at the gateway layer.

PII and secrets

PII and secrets leak when sensitive data pasted into a prompt goes straight to the provider — it isn't an attack, it's normal usage with no barrier.

Sensitive data rarely leaks out of bad intent: it leaks because the shortest path is to paste everything into the prompt. A tax ID for the model to check, an API key inside a snippet of code someone wants explained, a customer secret embedded in context that looked harmless — each of these becomes a token sent outside your operation. And it doesn't stop at the provider: the same content is usually recorded in request, monitoring or debug logs, many of them beyond your control. The problem isn't someone circumventing a protection; it's that there is no protection at all between what the user types and the model that receives it.

Because it's normal usage, you can't fix it with training or a written policy: no one remembers to scrub the prompt in a hurry, and a single lapse already exposes the data. The difference between an operation that controls this and one that doesn't is where the inspection happens. If every call crosses a single point before reaching the provider, that point can look at the content and act on what's sensitive. Without that point, the data is already gone by the time anyone notices — and what left doesn't come back.

At Horse Labs, every call passes a SecOps guardrail at the gateway before reaching the provider — the single point where PII and secrets can be detected before they're sent.

Mask or block

On detecting sensitive data, the gateway can mask the snippet or block the whole call — per the policy, in Off, Monitor or Block mode.

Detecting the sensitive data works on two complementary fronts. The first is deterministic: known patterns — API keys, secrets, document formats — recognized by regex executed under Google RE2, which is ReDoS-immune and therefore safe to run on every call. The second is NLP, with Microsoft Presidio, which recognizes what has no fixed format, such as a person's name. Together they cover both the secret that matches a rigid pattern and the PII that's only identifiable from context. On a hit, there are two possible responses: mask the snippet, letting the call proceed without the sensitive data, or block the request entirely.

Which response to use is a policy decision, set per organization and with three modes. In Off, the check doesn't run; in Monitor, the hit is recorded but the call proceeds, which is useful to measure exposure before tightening; in Block, the sensitive data stops the send. So each organization calibrates the rigor to its own risk — start by observing, understand what shows up in the prompts, and only then move to blocking — without switching tools or rewriting the integration at every adjustment.

At Horse Labs, the guardrail combines deterministic detection (regex under RE2, ReDoS-immune) with an NLP tier (Presidio) for PII, masking or blocking per the per-organization policy in Off, Monitor or Block mode.

Fail-closed

A DLP that fails open is no DLP: if the PII tier is set to Block and Presidio is unreachable, the call is blocked, not let through.

Every security control faces the same question at the moment of failure: what happens when the check can't run? There are two answers, and they're opposites. Failing open means letting the call through when the detector is down — convenient, but that's exactly the instant sensitive data slips out unseen. Failing closed means blocking the call when verification isn't possible. A DLP that fails open offers protection only while everything works, meaning it stops protecting precisely when it would be needed; in practice it isn't protection, it's a false sense of it.

That's why the failure behavior has to follow the policy's intent. If the organization set PII detection to Block, it declared that this data may not leave without a check — and that rule must hold even when the NLP tier is unavailable. In that case the call is blocked, not let through: the worst outcome becomes a refused request that can be retried, instead of a silent, irreversible leak. Choosing to fail closed is what separates a real control from an ornament that gives way at the first pressure.

At Horse Labs, the guardrail is fail-closed: with the PII tier set to Block and Presidio unreachable, the call is blocked, so sensitive data doesn't leave without a check even during a failure.

Data in logs

Sensitive data must not land in uncontrolled logs — a single pre-call point solves it once, instead of every developer scrubbing by hand.

The leak through logs is the most insidious because it's silent. Even if the provider discards the content, the prompt usually passes layers that record everything — proxies, observability tooling, debug files — and any of them can keep the sensitive data indefinitely, in places no one reviews. Unlike a wrong answer, which someone notices, data sitting in a log stays invisible until the day that log is exposed. The information left the control boundary with no decision ever made about it.

The alternative of having each developer scrub the prompt by hand doesn't scale and isn't reliable: it depends on everyone remembering, always, in every piece of code. The effective control is structural — intercept the content at a single point, before the call leaves, and there mask or block what's sensitive. Solved pre-call, the data is no longer present when the rest of the chain logs the request: what wasn't sent can't be logged. One control point replaces dozens of scattered manual scrubs, and the guarantee no longer hinges on individual discipline.

At Horse Labs, the guardrail runs pre-call at the gateway, so sensitive data is masked or blocked before the call proceeds — and never reaches the logs further down the chain.

FAQ

What is AI data governance?

It's the set of controls that keep sensitive information — PII, secrets, customer data — from leaving for the model provider or for uncontrolled logs, by inspecting every call at the gateway layer before it's sent.

Does DLP at the gateway replace manual prompt review?

Yes — instead of each developer remembering to scrub the prompt by hand, a single pre-call point masks or blocks the sensitive data, consistently and auditably, without depending on individual discipline.

Talk about data governance