Enterprise AI Governance and RBAC
Ferro Labs gives platform teams a single control plane for enterprise AI governance across providers, projects, teams, and API keys.
Centralize LLM RBAC, teams, project access grants, API keys, and audit trails across every model provider.
Buyer Problem
AI adoption spreads faster than governance. Security teams need LLM RBAC, project isolation, audit logs, and API key controls without forcing every app team to rebuild access checks.
Target Outcome
Approved teams get fast model access while platform owners keep project-scoped permissions, key lifecycle controls, and audit-ready visibility in one enterprise AI gateway.
Capabilities
Gateway controls for this solution
These are the gateway-level capabilities this solution depends on.
Proof Points
Evaluation evidence to review
RBAC, teams, project access grants, and audit logs are live today.
Governance is enforced at the gateway layer, so apps keep using OpenAI-compatible APIs.
Virtual keys can be scoped by project, model, provider, budget, and usage policy.
Sensitive administrative activity is recorded for compliance review and incident response.
Status note
Live: RBAC, teams, project access grants, key governance, and audit logs. Future: custom roles and SCIM.
Related Features
Feature deep dives
Rate Limiting & Access Control
Rate limiting works in three independent layers: per-IP HTTP middleware, a global token bucket applied before traffic reaches a provider, and per-API-key and per-user limits. Checks run in order — global, then per-key, then per-user — and the first exceeded limiter rejects the request with a distinct reason string.
Real-time Observability
Four observability layers ship in the gateway: Prometheus metrics at /metrics, opt-in OpenTelemetry tracing, structured JSON logs, and a deep /health endpoint. The OTel trace ID, the log trace_id, and the X-Request-ID header are all the same value, so you can jump from a log line straight into your tracing backend.
Built-in Plugins
Plugins extend the request pipeline at three lifecycle stages — before_request, after_request, and on_error. Six ship built in, covering content filtering, token limits, response caching, request logging, rate limiting, and spend control. Each is declared in config.yaml and can be toggled independently.
Model Aliases & Hot-Reload
Define semantic aliases like 'fast', 'smart', or 'cheap' and map them to concrete models in config. The gateway watches the config file and reloads on change, so you can migrate models at runtime — your application keeps calling the same alias while the target changes underneath it.
Related Links
Next resources
FAQ
Common evaluation questions
Can Ferro Labs enforce LLM RBAC across multiple providers?
Yes. Ferro Labs applies workspace, team, project, API key, provider, and model controls before traffic reaches the upstream provider.
Are custom roles and SCIM available?
Not yet. Core RBAC, teams, project access grants, and audit logs are live. Custom roles and SCIM are future roadmap items.
Do applications need to change provider SDKs?
No. Applications can continue using OpenAI-compatible request patterns while governance is centralized in the gateway.
Validate this solution against your deployment model
Start with the open-source gateway, review the docs, or scope a managed deployment with Ferro Labs.