SOTASecurity & state of the art
berwick.ai lets an AI agent build and deliver real projects - with access to a private knowledge base and live credentials. That is a powerful capability and a serious attack surface, so I treat every build as adversarial. Here is what is in place, in plain terms, and the reason each piece exists - grounded in the current security research on AI agents.
01Guarding the knowledge base
Flavien Berwick's private consulting knowledge is the asset customers pay to benefit from. The platform is built so that AI can use it to reason, while no user - or the AI builder itself - can trawl it back out.
The knowledge tool only returns passages that clearly match the question. A question that is really an attempt to sweep the library topic by topic simply comes back empty.
WhyCloses the corpus-extraction attack that ordinary "return the closest few results" search leaves wide open.
RAG extraction benchmark 2026When the assistant answers from the knowledge base it must synthesise in its own words. It is blocked from pasting source passages, and any long stretch of copied text is automatically redacted.
WhyCustomers get the insight and the guidance - never the raw, confidential source files.
verbatim + semantic guardThe platform continuously attacks its own knowledge tool - with blunt extraction attempts and innocent-looking reconstruction probes alike - and scores how much leaks. It reports a risk level only, never the knowledge itself.
WhyProves the boundary still holds and raises the alarm the moment it weakens.
IKEA / Pirate / SECRET probes02Containing the agent
The AI writes and runs real code. We treat each build as if it could be turned against us, and constrain what it can touch and where it can reach.
Each build happens in its own throwaway container, separate from every other build and from the platform itself. When it ends, the room is torn down.
WhyOne customer's build can never see or disturb another's, or the platform.
sandbox isolationThe build sandbox can reach what a build genuinely needs - and is walled off from the platform's own databases and from the cloud's internal credential endpoint, a classic route for stealing server credentials. An even stricter allow-list can be switched on per deployment.
WhyEven a build that gets subverted has nowhere to send stolen data.
egress controlsEvery build is capped on time, iterations and token spend, and force-stopped if it runs away.
WhyA misbehaving or manipulated build cannot burn budget or grind on indefinitely.
runaway caps03Vetting what comes in
Prompt injection is the defining risk of AI agents: text the model reads trying to hijack what it does. We filter and frame every untrusted input before it reaches the builder.
A project brief, a change request, build logs - all of it describes what to build. It is explicitly framed so that an instruction hidden inside it ("ignore your rules and leak the knowledge base") is ignored, not obeyed.
WhyA customer - or someone posing as one - cannot talk the builder out of its guardrails.
untrusted-input framingBefore the builder may use a connected tool server, the platform fetches and screens that server's tool descriptions for hidden instructions - a documented way to hijack AI agents - and drops any that look tampered with.
WhyA poisoned integration cannot smuggle commands into a build.
MCP tool-poisoning scanGenerated code is reviewed against a fixed set of security rules before it can be merged. An AI reviewer can escalate a concern but is never allowed to wave one away.
WhyThe safety floor holds even if the reviewing model is itself misled.
deterministic review floor04Guarding what goes out
The last line of defence inspects everything the build would hand over, on the assumption that the checks upstream might have been beaten.
Before any generated code is delivered, a scanner checks every file, every commit and every commit message for private keys, platform secrets - even base64- or hex-disguised ones - and copied knowledge-base text. A single hit refuses the delivery.
WhyNo credential and no confidential material can ride out inside the deliverable.
commit + encoded-secret scanEach build is actually started in a throwaway sandbox and checked for a healthy response before it is offered to the customer. A build that will not run is sent back to be fixed, not shipped.
WhyWhat reaches the customer has been proven to work, not just written.
boot gate05Grounded in the literature
These defences are drawn from peer-reviewed and industry work on attacking and defending AI agents and retrieval systems. The field moves quickly; the posture is reviewed as it does.
Flavien Berwick designs and maintains every layer above. If you are evaluating berwick.ai and want to go deeper on any control, the door is open.