DEV Community: Christopher dikesa

Why a Cloud Guardrail Is a Contradiction

Christopher dikesa — Fri, 06 Nov 2026 12:53:11 +0000

On November 2nd, GitBook told its users to rotate all their API tokens. An AI agent had reached infrastructure secrets. Days before, WIRED reported that a Claude Code agent spent two months with admin rights inside a US Department of Defense network, undetected. It exfiltrated credentials, passwords, a network map. These are not isolated cases. This is the new normal. And facing this, most AI security startups offer you the same solution: send us your data, we will protect it. That is where the problem starts.

To protect you, you have to expose yourselfFor a cloud guardrail to work, you have to send it what it needs to monitor:Your prompts.
Your tool calls.
Your secrets.
Your API responses.
Sometimes, your internal documents. In other words, you have to give a third party exactly what you are trying to protect. You create a new central point where all your sensitive data transits. If that third party gets breached, if one of its employees makes a mistake, if one of its own AI agents goes rogue, you leak. You did not reduce your risk. You moved it.
Trust should not be required to be secureCloud guardrails tell you: "Trust us, we are SOC 2, we are encrypted, we don't store your data. "But GitBook was encrypted too. The DoD had controls too. Trust should not be a prerequisite for security. It should be unnecessary. If to be protected, you first have to trust another actor with your most critical secrets, then your security model is fragile by design.
Self-hosted is not a feature, it's the missionThat is why we made a radical choice with Cerbère AG: self-hosted by design. Cerbere runs in your infrastructure. It sees your agent actions, it blocks exfiltrations, it logs decisions. But nothing leaves. No prompts sent to us. No secrets sent to us. No tool calls sent to us. The only number that leaves, once a month, is a counter: "124,502 decisions made". Just for billing. Not the content. We don't want to see your data to protect it. We want you to never need to trust us. Because we can't protect your secrets by asking you to send them to us.
Cloud to test, self-hosted to protectWe are not saying cloud is useless. It is useful to test fast, to do a demo in 2 minutes, to validate an idea. But in production, when your agents touch your APIs, your databases, your customers, you cannot afford a middleman. Cloud to discover. Self-hosted to protect.

AI agents have the keys to your company. The question is no longer if they will make a mistake, but if someone is watching what they touch. And that someone should not be a new third party you have to trust. It should be at home, under your control.

That is Cerbère AG.
AI agents need more than intelligence. They need control. And that control should never leave your infra.
Cerbere AG

Your agent reads your .env. Then a prompt injection tells it to send that .env somewhere else.

Christopher dikesa — Thu, 05 Nov 2026 08:41:33 +0000

This is the demo:

[1] Agent reads .env → allowed (internal tool)
[2] Agent posts a harmless report → 200 OK
[3] Injection tries to send .env out → BLOCKED
[4] Same try, secret base64-encoded → BLOCKED

Cerbere remembers the secret the agent read. If it appears in an external tool call, the call stops before it runs. Base64, hex or URL-encoded too.

Open source 👇

chrismsmr-celcom / cerbere-AG

Welcome to cerbere-agent guard, originally just agent guard, then rebranded after the mythical hound of the underworld. Our mission? Guarding your AI agents, keeping them in line, and blocking unauthorized actions. Think of it as the ultimate guard dog for AI security and guardrails. 🐕🛡️

Cerbere AG

The three-headed guardian of AI agents.
Runtime security & observability for autonomous agents: it sits between the model's decision and the real-world side effect.

Website · Quick start · Taint tracking · MCP · Benchmark · Roadmap

Why Cerbère

Prompt filtering checks what an agent is told. It cannot tell you whether the action the agent is about to take is safe An innocent prompt can still produce update_customer(role="admin"), an http_post carrying your .env, or fifty refunds in a loop.

Cerbère enforces policy at the execution boundary: every LLM call and tool call is inspected, scored and decided (ALLOW, REQUIRE APPROVAL or BLOCK) before it touches a database, an API or an inbox, and every decision leaves evidence.

Prompt analysis stays useful. Cerbère adds the layers that come after it: tool policy, budgets, data-flow tracking and human approval.

The three heads

…

View on GitHub

The safety of agents should never be done at the cost of speed or vice versa. Cerbere is the two

Christopher dikesa — Wed, 04 Nov 2026 13:29:11 +0000

Most guardrails have only one layer: a model that guesses if a prompt is nasty. 19ms to 120ms, and many false positives.

Cerberus is 3 layers:

Layer 1 - Rules / Regex: 0.87ms

It's the determinist guardrail. If the action is prohibited, it is blocked net. No guess, no latency. This is where we do 0.34ms in heat.

Layer 2 - ML: 251ms

For cases that the rules do not cover. The model classifies the risk of the action.

Layer 3 - LLM Judge: 362ms

Only for ambiguous cases. It's slow, but it's rare. We only pay the price of the LLM when we really need it.

Result: 95% of the actions are decided in <1ms, and really hard cases have a real judge.

We don't filter words. We control actions, with the right layer at the right time.

Code + bench: https://github.com/chrismsmr-celcom/cerbere-AG

Cerbere-AG -- The layer that ensures security, observability, and control, which sits between the AI agent and the real world

Christopher dikesa — Tue, 20 Oct 2026 23:43:32 +0000

Cerbere-AG is a three-layer security guardrail for AI agents: Regex, ML, and an LLM Judge.

AI agents are unpredictable. They improvise and act with full autonomy. I built Cerbere-AG (named after the three-headed dog, Cerberus) so that autonomy doesn’t come at the cost of control.

Why three layers? Our benchmarks show it:
→ Regex alone lets more than 30% of attacks through.
→ ML pushes recall up to 100% in some of our tests, but raises false positives.
→ The LLM Judge resolves the ambiguous cases ML can’t classify.
It also looks at context. Cerbere-AG follows tool calls, checks whether they’re legitimate, and then allows them, blocks them, or flags them for real-time human approval. Agents keep their autonomy, and humans keep control.
Everything is audited too. The collector gathers spans and traces into an audit trail that is independent from the agent and supports compliance.
And like any tool, it has limits. That’s why observability matters: security isn’t only about blocking attacks, it’s about understanding what happened, what was allowed, what was blocked, and why.

Open source and free for now. Try it and give me your honest feedback 👇
https://github.com/chrismsmr-celcom/cerbere-AG
https://app.cerbereag.site

I’m building a free, open-source security layer for AI agents — and I want the community to help build it

Christopher dikesa — Sun, 04 Oct 2026 19:59:23 +0000

Github

I’m building Cerbere AG, an open-source security and observability runtime for AI agents.
The idea is simple:
See what your agent does in production. Detect risky behavior. Block dangerous actions. Flag ambiguous ones. And require human approval when the system shouldn’t make the decision alone.
But this post isn’t really about announcing another AI security product.
It’s about making this a community project.
I want to make Cerbere AG free for everyone.
No credit card.
No paid plan required to start.
No artificial wall preventing developers from experimenting with agent security.
If you’re building an agent with tools, APIs, MCP, browser automation, databases, or other real-world capabilities, you should be able to add a security layer without first having to convince your company to spend thousands of dollars.
And I’m not pretending it’s finished.
It isn’t.
There are probably things I’ve missed.
There are edge cases I haven’t thought about.
There are attacks I haven’t covered.
There are integrations that could be better.
There are probably architectural decisions that someone in this community will look at and say:
“You should do this differently.”
Good. Tell me.
If you find a bug, report it.
If you find a security issue, report it.
If you think the detection logic is wrong, challenge it.
If you have a better approach, open a PR.
If you want to add an integration, build it.
If you have a new attack scenario, add it to the benchmark.
If you use Cerbere and discover that something doesn’t work, tell me.
The goal isn’t for me to personally build every feature.
The goal is to build something useful enough that other people want to contribute to it.
I’m building this largely by myself from Kinshasa, DRC, and I don’t have a large engineering team behind me.
So I can’t realistically cover every framework, every agent architecture, every tool integration, and every attack pattern alone.
That’s exactly why I’m opening it up.
What Cerbere currently focuses on
Agent execution tracing
Tool-call monitoring
Risk detection
Blocking
Flagging
Human approval for ambiguous/sensitive actions
Audit logs
Security evidence
Agent behavior observability
The project is still evolving, and I would rather have people tell me where it is wrong than pretend it is already perfect.
If you’re building AI agents, try it.
Use it.
Break it.
Audit it.
Contribute to it.
Tell me what sucks.
And if you think the idea is useful, give the repository a ⭐ or share it with someone building agents.
The more people test it, the more useful it can become.
Free. Open source. No credit card. Built in public.
GitHub: https://github.com/chrismsmr-celcom/cerbere-AG
If you see a problem, don’t just complain about it.
Bring the problem to the repo. Let’s build the solution together.

I’m building Cerbère-AG, a security evidence layer for AI agents.

Christopher dikesa — Sat, 26 Sep 2026 19:27:56 +0000

I’m building Cerbère-AG, a security evidence layer for AI agents.

Most AI security tools focus on what goes into the model: prompt injection, malicious inputs, jailbreaks, etc.

I’m focusing on what happens after the model decides to act.

Cerbère-AG observes and controls agent actions across tool calls, including:

tool-call monitoring and traces
policy enforcement
sensitive-action detection
argument and capability checks
budgets and execution limits
trajectory-level risk detection
human approval for sensitive actions
security evidence for AI agent activity

The idea is simple:

Don’t just ask whether an agent is safe to talk to. Ask whether it is safe to let it act.

I’m looking for developers and teams running AI agents in real or realistic environments to test Cerbère-AG and tell me where it fails.

I’m especially interested in design partners who can give real-world feedback on agent workflows, policies, approvals, and failure cases.

If you build AI agents, security tooling, MCP integrations, or autonomous workflows:

→ Give me your feedback: what would you expect a production-grade agent security layer to catch that Cerbère currently doesn't?

And if you find the project useful, a ⭐ on GitHub helps people discover it.

I’m more interested in breaking it and finding its weaknesses than in compliments.

If you have an agent that you think could expose a real failure mode, send it my way.

→ Test it:
→ GitHub:

We benchmarked our prompt-injection detector against OWASP's LLM Top 10

Christopher dikesa — Sat, 26 Sep 2026 19:11:17 +0000

We just published our first public benchmark for AgentGuard, the runtime we're building to secure AI agents in production.
The honest version: our deterministic (regex) layer alone catches 91.5% of prompt injection attempts with zero false positives, in under 2ms. Adding a ML layer pushes recall to 98.1% — but the trade-offs are real: ~450ms latency, and a 33% false-positive rate on benign prompts that were deliberately worded to look like attacks.
We're publishing the numbers as they are, weaknesses included, and mapped everything to the OWASP Top 10 for LLM Applications so it's easy to compare.