AI Agent Security Layer in Practice: Cerbere AG Seeks Early Testers

When AI Agents Start Acting Autonomously, Who Guards the Security Perimeter?

As AI Agents move from concept into production environments, a long-overlooked question is coming to the surface: when agents can access data, call APIs, use MCP protocols, send emails, and even make autonomous decisions — how do you ensure their behavior stays within controllable, auditable boundaries?

An independent developer from Kinshasa is trying to answer that question. He's built a product called Cerbere AG — positioned as a "security/control layer" for AI Agents — and is publicly recruiting 5 to 10 serious early users and design partners for a free trial of his full toolchain.

What Exactly Is Cerbere AG

Based on the developer's own description, Cerbere AG is not a conceptual prototype — it's a product stack with a relatively complete shape. According to him, the project has already built the following core components:

• SDK: Allows developers to integrate security control capabilities into their own agents;
• Runtime: Performs real-time monitoring and intervention as agents execute actions;
• Dashboard: Provides a visual interface for observing agent behavior;
• Detection system: Identifies abnormal or high-risk agent behavior;
• Public benchmark: Measures the effectiveness of the security layer.

This combination covers the full lifecycle — from integration and execution to monitoring and evaluation. For a solo developer to have assembled all these modules in an isolated environment signals a fairly systematic understanding of agent security, not just surface-level ideation.

Security/Control Layer is a new middleware concept that has emerged alongside the real-world deployment of AI Agents. The core idea is similar to an API gateway or firewall in traditional software architecture: insert an observable, interceptable proxy layer into the agent's execution path, rather than modifying the agent's own logic. These products typically exist as SDKs or Runtime Proxies, capable of capturing every tool call, API request, or data operation an agent makes — enabling rule validation, risk scoring, or human approval before actions are actually executed. Unlike traditional application security, AI Agent behavior is highly nondeterministic — the decision paths of each LLM inference are nearly impossible to enumerate in advance. This makes whitelist-based rule strategies insufficient, and detection systems must also possess semantic understanding and anomaly baseline modeling. The component combination Cerbere AG describes is a systematic response to exactly this challenge.

Why He Needs "Real Agents"

The developer openly admits he's hit a wall: continuing to develop in an isolated environment is no longer what he needs most right now. What he truly needs are real agents, real workloads, and honest feedback.

This is a phase-specific dilemma that resonates with any developer building tooling products. Security products especially — their value can only be validated against real attack surfaces, real call chains, and real business scenarios. A detection system that runs perfectly on a "toy agent" may be full of holes in production.

He has explicitly listed five types of feedback he hopes to get from early users:

1. What works
2. What doesn't
3. What it misses
4. What would make it genuinely useful in production
5. What users would ultimately pay for

That last point is particularly telling — it reveals that this developer isn't pursuing pure open-source altruism, but rather charting a path toward commercialization. The current free-access strategy is essentially trading product usage rights for real-world scenario data and payment intent validation.

What Kind of Partners He's Looking For

The developer specifically emphasizes that his target users are builders with agents already deployed or close to deployment. In other words, he's not interested in demo-stage experiments — he wants to engage teams that have already let their agents touch real data, call real tools, and bear real consequences.

Specifically, if you're building an agent with any of the following capabilities, you're his ideal test candidate:

• Can access data
• Can call APIs or tools
• Uses MCP (Model Context Protocol)
• Can send emails
• Can execute actions or make autonomous decisions

This list neatly outlines the typical characteristics of today's "high-risk agents." An agent that only chats requires almost no security layer — but an agent that can send emails, modify data, and call external services on its own is capable of serious damage if it goes off the rails. Cerbere is targeting exactly this rapidly expanding risk zone.

MCP (Model Context Protocol) is an open protocol proposed and championed by Anthropic in late 2024, designed to standardize how LLMs interact with external tools and data sources. Before MCP, every AI application implemented tool calling differently, with no interoperability. MCP defines a unified client-server architecture: the LLM acts as a client and sends tool call requests via the MCP protocol to various "MCP Servers," which can be local file systems, databases, browser controllers, or enterprise internal systems. This dramatically expands an agent's capability boundaries — while also significantly increasing its attack surface. Any MCP Server could become an entry point for injecting malicious instructions or leaking sensitive data. Cerbere AG explicitly lists MCP as a target scenario, which means its detection system needs to parse and audit call content formatted according to the MCP protocol — not merely monitor generic HTTP traffic.

A Representative Case Study of Solo Development

Beyond the product itself, this recruitment post is also a fairly representative sample of the indie developer experience.

The developer repeatedly emphasizes "I built this alone" and is candid that "I'm not looking for money right now" — he wants to see "what happens when real agents start running on it." This mindset is not uncommon among early-stage technical founders: validate value first, monetize later.

For a relatively specialized track like AI security, the biggest challenge for independent developers is rarely technical implementation — it's building trust and distribution from a cold start. With no reputation and no team backing, publicly recruiting early partners through community channels and offering free integration support in exchange for real feedback is a practical but difficult path.

A Few Things to Keep in Mind for Developers

If you happen to be building a production-grade agent and are interested in this kind of security control layer, it's worth adding products like this to your watchlist. But before actually integrating, a few points are worth keeping in mind:

• Data boundaries: Security layers typically need to observe agent behavior and potentially some call content — clarify how data is handled before integrating;
• Maturity expectations: This is explicitly an early-stage product; you'll need to assess stability and feature completeness yourself;
• Value of feedback: As an early design partner, your input may directly shape the product's direction — that's both an opportunity and a real cost in time and effort.

AI Agent security governance is still largely uncharted territory. Efforts like this from frontline independent developers — regardless of how they ultimately play out — are accumulating real experiential data for an emerging field that badly needs it.