Security posture
Security is part of Mulberry from the first commit, not a later feature. Here is what V1 does and does not do.
Export first, no cloud execution
V1 generates a loop pack you download and run yourself. Mulberry does not run arbitrary code in the cloud, store your loops, or hold your secrets.
The model only produces structured data
Model output is treated as untrusted. It is validated against a strict schema, then the governance validator checks it. The downloadable files are rendered deterministically from the validated contract, so a pack always matches the rules you reviewed. The model never writes files.
Governed by default
A loop cannot be exported unless its guardrails are in place: a clear goal, a trigger, a stop condition, a budget, permission boundaries, forbidden actions, a checker for medium and high risk, human gates for risky actions, a failure policy, and an audit schema. Abusive requests are blocked.
What is sent to the model vs kept local
Only your plain-English request and your clarifying answers are sent to the model to draft the contract. Your request is treated as data, not instructions, so embedded text cannot grant permissions or disable safety. Validation, rendering, and the export pack are produced locally and are never stored after download.
No secrets, ever
Do not paste API keys or secrets into the builder. Mulberry never asks for them, and generated runbooks warn against putting secrets into prompts.
This is a founder-level posture, not a penetration test, trademark review, or compliance certification.