Sentisec vs. the alternatives

Sentisec is in a different category from LLM gateways, content filters, and API gateways. It shares their shape — something in the request path, speaking your provider's protocol — but it answers a different question. A gateway asks "where should this call go and what does it cost?" A filter asks "is this text acceptable?" Sentisec asks "does this action make sense, given everything this session has seen?"

These categories complement each other more than they compete, and most serious deployments end up running more than one. This page is about picking the right tool for each job, not about winning an argument.

At a glance

vs. LLM gateways

The gateway category is mature and good at what it does: provider abstraction, model routing and fallback, per-key budgets and spend caps, a catalogue of a hundred vendors, and traffic observability.

Sentisec is not trying to beat gateways at that. Today Sentisec dispatches to five providers — Anthropic, OpenAI, Kimi, Google Gemini, and Google Vertex AI — plus a passthrough path for subscription-authenticated CLI tools. It does not do per-key spend caps, it does not do model routing or fallback, and it cannot currently route to a self-hosted or local model endpoint. If any of those are load-bearing for you, keep your gateway.

What Sentisec adds is the layer a gateway structurally cannot provide: semantic evaluation of each call in the context of its session. A gateway sees a request and a response. It has no notion of what the agent was asked to do, what content has entered the conversation since, or whether the tool call it is now making follows from the task or from something the agent read along the way.

Sentisec does bring an operator surface for the traffic it carries — a request log explorer with per-call latency, tokens, cost, and status, and trace views over a session. That is there so you can operate what you are protecting, not as a replacement for your gateway's commercial features.

vs. content filters and DLP

Content filters work at the string level: does this output contain a card number, does this input look like a jailbreak attempt, does this text match a policy pattern. They are effective at that, and Sentisec does not do it — we do not score text for toxicity, bias, or sensitive strings.

The structural limit of a filter is that it is stateless. It cannot express "this agent fetched a page three steps ago, and the action it is taking now is a consequence of what that page said." Indirect prompt injection is specifically the case where the offending instruction is not in the user's input but in something the agent retrieved along the way — the exact shape a string-level check is blind to.

Sentisec reads the session. A content filter reads the string. Run both: they cover genuinely different failure modes.

vs. WAFs and API gateways

Traditional API gateways and WAFs — Kong, AWS API Gateway, Cloudflare, NGINX with rules — operate at the HTTP layer: rate limiting, IP allowlists, JWT validation, schema validation, signature checks. They have no semantic understanding of what an LLM call is doing, and they do not claim to.

Keep one in front of your Sentisec deployment for HTTP-layer concerns. Different layer, different threats, no overlap to resolve.

Sentisec's one adjacent feature is the egress allowlist: the set of hostnames and CIDR ranges your agents are permitted to reach. That is an agent-behaviour control expressed in your workspace policy, not a network appliance, and it does not replace one.

vs. building it yourself

You can build this. Several teams have started. The parts that make it harder than the prototype suggests:

• Cross-shape coverage. Anthropic-shaped and OpenAI-shaped traffic differ, streaming differs from non-streaming, and a block has to be returned in a form that every agent framework's error handling survives. Getting that wrong turns a security control into an outage.
• Policy expressiveness. The policy language has to encode real workflows without quietly becoming a programming language you now maintain.
• Evidence that survives an auditor. Hash-chaining and signing are the easy half; producing a bundle an auditor can verify without trusting you is the requirement.
• An operator surface people will actually use. Half-built tooling gets ignored, and an ignored control is not a control.

Sentisec is the consolidated version of that work. The product is the composition.

What we do not claim

• Sentisec is not a content-moderation product. We do not score whether outputs are toxic, biased, or infringing.
• Sentisec is not a training-time control. Data poisoning and weight tampering happen long before a request reaches us.
• Sentisec is not a substitute for least privilege. Give the agent the smallest credential that does the job; Sentisec catches what gets through that.
• Sentisec is not a full-featured LLM gateway. Five providers, no spend caps, no routing rules, and no self-hosted or local model endpoints. If you need those, run a gateway behind us — the topology above is supported precisely so you do not have to choose.

Next