What we learned putting a firewall in front of ZapBrabo's AI agents

Before asking any company to put SemantiqWall in front of its AI agents, we put it in front of ours. ZapBrabo, a WhatsApp AI customer service platform for small businesses in Brazil (shops, clinics, barbershops), is customer zero.

It isn't a lab environment. It's a platform where many businesses (tenants) share the same system, with agents serving different audiences: one serves each shop's end customers on WhatsApp, another answers the business owner about sales and campaigns, another helps build purchase orders, and an internal assistant supports the platform's own operations.

These are the lessons that changed the product.

1. In a multi-tenant system, the biggest risk is crossing the wall

In a system with many tenants, the most expensive mistake isn't the agent doing something strange. It's the agent doing something normal for the wrong customer: looking up another shop's order, reading another business's conversation.

SemantiqWall's ownership rule compares "who is asking" with "who owns the resource". At ZapBrabo, both sides come from the conversation's tenant, supplied by the backend, not from anything the model read. A lookup that reaches the tool asking for another tenant's data is denied, whatever the text says.

Lesson: the most valuable control in an AI-powered SaaS isn't sophisticated. It's making sure the identity used in the decision comes from the system, never from the conversation.

2. The agent also gets things wrong in what it says, and that becomes a sales problem

On September 27, 2026, two errors showed up in real conversations:

• the agent sent a link to a Mercado Livre store profile that didn't exist (Mercado Livre is a major Latin American marketplace);
• the agent quoted a product at R$ 858.90 when the listing was at R$ 528.90.

Neither was an attack. It was the model filling a gap with something plausible. But to the end customer, a fake link looks like a scam, and a wrong price turns into an argument or a loss.

That's where the response check came from: before the message goes out, every link and every amount in Brazilian reais in the reply has to appear in some source: what the tools returned, what the application authorized, what the customer wrote, or what was already proven earlier in the same conversation. Anything without an origin is flagged.

The check is deliberately narrow. It does not judge tone, politeness or whether the answer is "good". It verifies one objective thing: whether the number and the link came from somewhere. No AI judging AI.

Lesson: for an agent that sells, "what it says" is also an action. Links and prices need backing.

3. Some risks the firewall can't close alone, and it's better to say so

One of the agents looks up marketplace orders (Shopee) by order number. The problem: in the data that arrives, the order has no link to the person asking. If someone gets hold of a leaked order number, a single lookup goes through.

The per-person limit slows down anyone trying to sweep order numbers in sequence. But a single lookup with a real number can't be told apart from a legitimate customer with the information that exists today. The real fix is in the application: tie the order to the buyer before answering. That fix is logged as an open item in ZapBrabo itself.

Lesson: a control on the action is only as good as the data the application gives it. When the data doesn't exist, the firewall doesn't make it up. The right move is to point to where the fix needs to happen.

4. Observe first, block later

Like every SemantiqWall policy, ZapBrabo's rules started in observe mode: recording what they would have done, without blocking any conversation. That's how you find out, with real traffic, whether a rule is too tight before it costs a sale.

Turning enforcement on is a person's decision, and it comes with an automatic watch: if the policy starts blocking far beyond what observation showed, it rolls back to observe mode by itself and opens a case.

Lesson: the fear that "the firewall will get in the way of customer service" is legitimate. The answer isn't promising it won't. It's showing the effect before switching it on.

What we don't do yet

For transparency, two open points that came out of this deployment:

• there is no "distinct customers per hour" rule yet (today the per-person limit stands in for it);
• the response check covers links and amounts in reais, not every claim in the text.

Putting SemantiqWall on our own product first wasn't marketing. It was the fastest way to find out what it didn't do.