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 access governance

AI access governance means controlling who — person or agent — can use which models and data, with credentials that stay hidden and an audit trail of every use. This guide details the four mechanisms: access as a role rather than a loose key, per-organization isolation, credentials kept in a vault with writes protected by a second factor, and the trail that answers "who did what".

Role-based access

Role-based access means giving each person or agent a profile with defined permissions — not a loose API key that opens everything the same way.

When access to AI is an API key scattered through the code or the environment variables, everyone reaches anything with the same credential: there's no difference between whoever should provision the platform and whoever should only check their own usage. Worse, when that key leaks, everything leaks at once, and there's no way to say afterward who did what. Role-based access flips this: each person or agent operates under a profile whose permissions are scoped to what that profile needs, nothing more. What can be done stops being a property of the key and becomes a property of who's acting.

In practice this organizes into a few clear roles. A platform role reaches configuration that spans organizations — provider keys, catalog. An administration role governs one organization: cost centers, spend, model approval, always filtered by that very organization. And a common-usage role stays restricted to self-service, seeing only what concerns it. Three levels are enough so that each action lands with the right person without giving anyone more reach than their function requires.

At Horse Labs, access control is RBAC with three roles: operator (platform, spanning organizations), admin (one organization) and member/viewer (self-service) — each with permissions scoped to its own function.

Per-organization isolation

Per-organization isolation means ensuring one client's data is never reachable from another's context — everything is filtered by the organization of whoever is acting.

In an operation serving many clients on the same infrastructure, the gravest risk isn't someone seeing what they shouldn't within their own organization — it's one client's data leaking to another. Without a boundary, a request made under one contract could, through a missed filter, return information from a neighboring contract, and that kind of leak is hard to notice and impossible to undo. Per-organization isolation closes that boundary by making it part of every query: spend, requests, cost centers, secrets — everything carries the organization of whoever is acting and is filtered by it before any response.

The key point is that this boundary can't depend on the developer remembering to apply it on each query; it has to be embedded in the access layer and checked automatically. An attempt to reach another organization's data doesn't return partially — it's refused. And because that behavior is a security promise, it has to be proven, not assumed: the isolation is covered by integration tests that exercise precisely the boundary crossing and confirm it's barred.

At Horse Labs, everything is scoped by organization and isolation between organizations is validated by integration tests — one client's data stays isolated from another's.

Credentials in the vault

Provider credentials live in a secrets vault, delivered to services on demand and never embedded in the agents or models — and writing a secret requires a second factor.

The most dangerous credential in an AI operation is the provider key, because it costs money and opens the model to whoever holds it. Leaving it inside the code, in a config file, or embedded in the agent itself is inviting a leak: all it takes is an exposed repository, a careless log, a published container image. The structural alternative is to keep these keys in a secrets vault and deliver them to services only at the moment of use, under an identity of their own — the service authenticates to the vault and receives the secret, instead of carrying it along. That way the key never lives in the artifact that consumes it, and whoever inspects the code or the agent finds no credential at all.

Keeping it safe isn't enough if anyone can rewrite the secret. That's why writing is treated as a privileged action: changing a credential requires a momentary step-up with a second factor (2FA via TOTP), so that not even an already-authenticated session modifies a secret without confirming again, right there, who is acting. Reads by services are routine and automatic; writes are a deliberate, protected exception. The separation between the two is what keeps the vault trustworthy.

At Horse Labs, provider credentials live in HashiCorp Vault, delivered to services via AppRole and never embedded in the agents, with writing any secret protected by 2FA (TOTP).

Audit trail

An audit trail is the record of every sensitive action — the basis for answering "who did what" without having to reconstruct anything afterward.

Controlling who reaches what reduces risk, but it doesn't remove the question that comes after any incident or audit: who, exactly, took that action, and when? If the answer depends on reconstructing the past from scattered logs and people's memory, it arrives late, incomplete and contestable. The audit trail exists so that answer is already ready: each sensitive action — revealing a secret, approving a model, changing a governance setting — is recorded the moment it happens, with the actor and the context, in a record that serves as a single source.

That record is what turns access governance into a verifiable promise rather than an intention. Without it, everything else — roles, isolation, vault — has no accountability: you'd have the controls but not the evidence they worked. With the trail, every sensitive use leaves an auditable trace, and answering an investigation, a client, or a compliance requirement becomes a query, not an excavation. It's the layer that closes the loop: access is defined, access is enforced, and access is recorded.

At Horse Labs, every sensitive action lands in the audit trail — revealing a secret, approving a model, changing governance — so that "who did what" is a query, not a reconstruction.

FAQ

What is AI access governance?

It's the set of controls that defines who — person or agent — can use which models and data, with role-based access, per-organization isolation, credentials kept in a vault, and an audit trail of every use, all at the infrastructure layer.

How do I keep one client's data from leaking to another?

By scoping everything to the organization and filtering every query by it, embedded in the access layer — a boundary covered by integration tests that confirm cross-organization access is barred.

Talk about access governance