WitnessAI just raised $58M to police enterprise AI traffic, and the timing makes sense

WitnessAI has raised $58 million to build what it calls a “confidence layer” for enterprise AI. Under the branding, the pitch is simple enough: put a control plane between enterprise apps and large language models, then inspect, redact, log, and enforce policy on everything going in and out.

It’s a less flashy business than shipping another agent framework. It may also be a better one.

The company, led by CEO Rick Caccia and backed by Ballistic Ventures partner Barmak Meftah, is going after a problem that has moved well past security-team anxiety. Enterprises are wiring LLMs into support workflows, internal search, procurement, code review, and sales ops. Every one of those integrations creates a new egress path for sensitive data, another opening for prompt injection, and another audit problem.

Security teams have seen this movie before. Developers ship. Governance lags. Then everyone scrambles to bolt controls onto a system that already has API keys in production and access to documents it probably shouldn’t.

Why this market showed up now

The strongest part of WitnessAI’s pitch is the timing.

For the past year or two, cloud providers and model vendors have pushed built-in guardrails. Useful, to a point. But large companies rarely run one model in one cloud for one use case. They use OpenAI for one workflow, Anthropic for another, an open-weight model on-prem for regulated data, and maybe Azure OpenAI because procurement or residency rules say so.

That’s where the tidy provider-native story falls apart.

A separate enforcement layer starts to look appealing when the stack is messy, compliance wants consistency, and developers are tired of rebuilding the same filtering logic for every vendor. WitnessAI’s model-agnostic position is the whole argument. If the product works, enterprises get one place to define policy across multiple model providers, tools, and agents.

It’s a familiar enterprise pattern. API gateways won because companies needed one choke point for auth, rate limiting, observability, and routing. Service meshes grew for similar reasons. AI traffic is heading in the same direction.

WitnessAI framed the market on TechCrunch’s Equity podcast as an $800 billion to $1.2 trillion opportunity by 2031. That number is huge, probably too clean, and not all that helpful. The grounded version is simpler: AI security is now its own buying category, and the buyers include the CISO, the chief data officer, and whoever owns applied ML in production.

That part is real.

What the “confidence layer” actually needs to do

In engineering terms, WitnessAI is building a programmable gateway for LLM interactions.

A serious product here needs a few core capabilities.

First, policy-as-code. Teams need rules they can version, test, and roll out the same way they handle infrastructure policy. Think OPA/Rego-style controls or YAML rules that decide what data can be sent to a model, which tools an agent may call, and what output gets blocked or rewritten before it reaches a user.

Second, inline data controls. Prompts and retrieved context need to be scanned for PII, secrets, and regulated data before anything leaves the enterprise boundary. Some of that is basic pattern matching. SSNs, credit card numbers, cloud keys. Some needs ML-based entity detection for the messier cases where sensitive data isn’t neatly formatted.

Third, prompt injection defense. This is where things get ugly. Crude jailbreak attempts are easy enough to catch with rules. Harder cases come from documents or web content carrying hidden instructions that get pulled into an agent’s context window. If the system doesn’t preserve instruction hierarchy across retrieval and tool calls, a malicious snippet can still steer the model.

Fourth, identity and permissions. AI requests can’t be anonymous inside the company. If an agent can call internal tools, it has to inherit some version of RBAC or ABAC, respect least privilege, and stay segmented by tenant or business unit. Otherwise the “helpful assistant” becomes broadly privileged middleware.

Fifth, observability. This matters more than a lot of AI demos admit. Teams need transcripts, model and provider metadata, tool-call history, prompt lineage, token usage, and tamper-evident audit records. If something leaks, hallucinates, or takes an unsafe action, you need to reconstruct what happened. That’s hard to do with scattered SDK wrappers and partial logs.

Then there’s cost and reliability. A practical gateway should rate limit, apply quotas, route around degraded providers, and trip circuit breakers when latency or error rates spike. AI security products that ignore spend control are skipping part of the job.

Where it fits in a real stack

There are three obvious deployment patterns, and each has trade-offs.

A reverse proxy in the egress path is the clearest model. Route all LLM traffic through a gateway, apply policy there, and keep model calls visible. This works well for SaaS apps and service-to-service traffic. It also gives security teams one place to enforce encryption, VPC peering, and key-handling policies.

A Kubernetes sidecar makes sense for teams already running AI services in-cluster. You can enforce policy close to each workload and tailor rules per service. It’s flexible. It also adds operational overhead and plenty of room for traffic misconfigurations.

An SDK wrapper is the lightest option and often the fastest to roll out. It also relies on developer discipline, which usually means it’s easy to bypass. If hard enforcement matters, SDK-only controls won’t cut it.

The companies that get this right will probably use a mix. SDKs for developer ergonomics, egress controls for actual enforcement.

Latency is the hard part

Every AI security vendor promises “inline.” The real question is how much pain that introduces.

If you inspect prompts, redact data, classify injection attempts, evaluate policy, and maybe rewrite outputs, you’re adding latency directly into user-facing interactions. The source material points to a target of keeping P95 overhead under 75 ms. Reasonable on paper. Ambitious once traffic scales and policies get more complex.

Streaming makes it harder. Teams want token streaming for responsiveness, especially in chat UIs and copilot flows. Naive redaction and output filtering can break streaming or force buffering that ruins the experience. A real product needs streaming-compatible inspection, not batch cleanup after the fact.

False positives are another problem. Heavy-handed redaction can gut the model’s usefulness. Weak filtering leaves sensitive data exposed. There’s no magic threshold. You need policy testing against real corpora, override workflows with audit trails, and enough instrumentation to see where controls are degrading the product.

That’s why the “confidence layer” idea has substance, and why it’s harder than the branding suggests. Blocking obvious bad strings is easy. Doing it accurately, quickly, across multiple providers and agent frameworks is much harder.

Agents make the problem worse

Plain chatbots are manageable. Tool-using agents are where the bill gets expensive.

Once a model can retrieve documents, hit APIs, write tickets, call internal services, or hand work to another agent, you need controls on the whole chain, not just the opening prompt. That means signed messages between agents, ACLs on cross-agent calls, recursion limits, token and spend budgets, and provenance metadata on tool outputs.

Without that, you end up with overpowered automation and weak accountability. The system can act broadly, but nobody can say with confidence which step caused the failure or whether a malicious prompt came from a user, a document, or another model-generated message.

Enterprises will pay to close that gap.

The field is already crowded

WitnessAI isn’t alone. Hyperscalers already offer products like Bedrock Guardrails, Vertex AI safety controls, and Azure AI Content Safety. Startups such as Lakera, Robust Intelligence, CalypsoAI, and Protect AI are all working nearby, from runtime defenses to model risk and supply-chain security. Open source projects like LlamaGuard, NeMo Guardrails, Rebuff, Guardrails, and Open Policy Agent cover parts of the stack too.

So the challenge is obvious. WitnessAI has to beat the DIY approach of stitching together cloud-native features and open source components, while staying neutral enough to justify one more architectural layer.

That’s a tough sell. Enterprises already have more control planes than they want.

Regulation does help. The EU AI Act is starting to matter in practical terms. NIST’s AI RMF is showing up in risk programs. Existing sector rules already apply when AI systems influence decisions in finance, healthcare, and other regulated industries. Compliance teams don’t want bespoke controls for every model endpoint. They want repeatable policy and clean audit records.

What developers and tech leads should watch

The important question is where AI security gets enforced.

If you’re evaluating products like WitnessAI, ask a few direct questions:

• Can it inspect and redact data before third-party model calls?
• Does it support multi-model routing without leaking provider-specific quirks into application code?
• Can it preserve streaming while enforcing policy?
• Does it tie requests to user identity, entitlements, and tool scopes?
• Can it log full request lineage and emit traces your observability stack can actually use?
• What happens when the guardrail service fails? Does traffic fail closed, fail open, or route elsewhere?

Then ask the uncomfortable one: will developers route around it because it slows them down?

That’s usually where these products live or die.

WitnessAI raised $58 million because enterprises want a gatekeeper for AI traffic, and because the old model of trusting app teams to be careful is already breaking. The opportunity is obvious. So is the execution risk. A neutral control plane for enterprise AI makes sense. Building one that’s fast, accurate, and hard to bypass is the part that matters.