$ myla ~/about
Myla is a security engineer for teams that don’t have one.
It does two jobs. It looks at the systems you already use, including your code, your cloud and your AI setup, and tells you what’s wrong in words you can act on. And it sits in front of your AI agents, so every tool call they make goes past a policy before it runs.
Why it exists
AI agents got real access faster than anyone built controls for them. An agent today can run shell commands, write files, call APIs and reach production. In most small companies nobody can say what each one is allowed to do, or what any of them did last week.
The tools that exist for this are built for security teams. They assume someone is paid to read dashboards, tune policies and triage alerts. Most companies now running AI agents don’t have that person, and aren’t going to hire them.
So Myla is built on the assumption that nobody is watching. It has to be useful on the first day, to someone with no security background, with no tuning period.
Who it’s for
Solo founders, small teams, and companies with no security person: people shipping with AI agents who need to know what those agents can reach, and what they have actually done.
A test, if you’re unsure: can you name every AI agent with access to your code right now, and say what each one is allowed to do? If you can, you may not need this yet.
Who it isn’t for
Myla is not a SOC, a SIEM, or a replacement for a security team. If you have one, they will want more depth than this. It does not do endpoint security, network monitoring or compliance certification.
It covers one gap: your AI agents, and the systems they can reach.
Who’s behind Myla
We’re in stealth, so the names aren’t on this page yet. That’s a decision about timing rather than an attempt to be mysterious: the founding team goes public here in the coming weeks.
In the meantime, we’d rather you didn’t take our word for anything. Every claim Myla makes is one you can check.
The judgement calls in Myla (what counts as dangerous, what gets stopped, what we decline to infer) are not ours alone. They are reviewed by people who do security for a living, from cloud and application security teams, who tell us where we have it wrong. Several of the rules in the Gate exist because one of them pushed back.
Which is also why the product is built to be checked rather than trusted. How it’s built sets out the decision path, and why the verdict is a pure function that nothing in your codebase can argue with. How we measure publishes precision and recall every release, including the cases we already know we miss. And every verdict the Gate reaches is written to a ledger you can read, line by line.
What we do to our own product
- The Gate starts in observe mode. On day one it records what it would have stopped and stops nothing, so switching it on cannot break your work. You decide when it starts enforcing.
- We publish what we miss. The numbers on how we measure are a real run, and the known misses are held out of the rates rather than quietly dropped.
- We would rather show nothing than invent a number. Where Myla can’t check something, it says so and calls it a gap. It does not guess and call the guess a result.
- Found a problem in Myla itself? Tell us at support@mylasecurity.app. We will confirm we received it.