AI Guardrails for PII and Prompt Injection
Ferro Labs lets platform and security teams apply AI guardrails at the gateway before risky prompts, responses, or tool flows spread across applications.
Enforce AI guardrails for PII, prompt injection, moderation, consent, external evaluators, and CEL policies.
Buyer Problem
Every new AI feature creates another place for PII leakage, unsafe content, prompt injection, and policy drift. App-by-app guardrails are hard to audit and easy to bypass.
Target Outcome
Teams can enforce consistent policy for AI requests and responses with OSS plugins, Pro evaluators, CEL rules, PII controls, prompt injection checks, moderation, and policy simulation.
Capabilities
Gateway controls for this solution
These are the gateway-level capabilities this solution depends on.
Proof Points
Evaluation evidence to review
OSS plugins and Pro guardrail evaluators are implemented.
PII, prompt injection, moderation, external providers, consent checks, CEL, and policy simulation are supported.
Policies can run before or after provider calls depending on the control being enforced.
Policy decisions are visible in logs and traces for audit and debugging.
Status note
Live: OSS plugins, Pro evaluators, CEL, PII, prompt injection, moderation, external providers, consent, and policy simulator. Future: compliance templates.
Related Features
Feature deep dives
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.
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.
Semantic Caching
Semantic caching compares the meaning of a request, not its exact bytes, so near-duplicate prompts are served from cache. Queries are embedded and matched against an HNSW index in PostgreSQL with pgvector; a hit above the similarity threshold returns instantly without a billable provider call.
Related Links
Next resources
FAQ
Common evaluation questions
Does Ferro Labs support PII redaction?
Yes. PII controls are implemented as Pro guardrail evaluators and can be combined with gateway policies, logging, and audit workflows.
Can it detect prompt injection?
Yes. Prompt injection detection is implemented through Pro evaluators and can be enforced alongside moderation, consent, and CEL policies.
Are compliance templates available?
Not yet. Guardrail engines, evaluators, CEL policies, consent controls, external providers, and the policy simulator are implemented. Compliance templates are future roadmap items.
Validate this solution against your deployment model
Start with the open-source gateway, review the docs, or scope a managed deployment with Ferro Labs.