Terms

Myla Security examines the systems you connect — a GitHub organisation, a Supabase organisation, a Google Workspace domain, and a domain name — for exposed secrets, vulnerable dependencies and risky configuration, and helps you fix them. It can also watch what your AI coding agents do and block a tool call that looks like an attack.

It is a tool that reports what it finds. It does not find everything, and it does not claim to.

Myla is not a penetration test, not a compliance certification, not a guarantee that your systems are secure, and not a substitute for a security professional. Nothing it produces is an audit, an attestation, or advice you should rely on in place of someone qualified looking at your systems.

A clean result means the checks Myla ran did not find anything — not that there is nothing to find. That distinction is built into the product rather than written only here. Every check records its own outcome, and a check that could not run is recorded as “couldn’t check”, never as a pass; only a check that actually ran is allowed to close a finding. The screens say the same thing in their own words: a partial check tells you that “anything it didn’t reach is not counted as safe”. There is a test asserting that a failed read cannot report a check it could not run as a pass, and cannot auto-close findings.

The Gate, which watches your coding agents, is a tripwire and not a guarantee. It can block a call that matches a rule; it cannot promise that every harmful call matches one.

You are responsible for the credentials and systems you connect, and for having the authority to connect them. Connecting an organisation’s GitHub, Supabase or Google Workspace means you are telling us you have permission to do so — we check what the provider will tell us (GitHub is asked whether you administer the organisation; Google Workspace requires a super admin), but the permission itself is yours to hold.

You are responsible for what you do with what Myla reports, including any change you or a coding agent makes in response to it.

Scan systems you own or are authorised to scan. Do not use Myla to examine systems you have no right to examine, and do not use it to attack anything.

Do not use it to interfere with the service itself — that includes working around the rate limits on the public repository check and on rescans.

What we read, what we store, what we deliberately do not store, and who else sees any of it is described in the privacy policy. It is not restated here: two documents describing the same thing drift, and the privacy policy is the one kept in step with the code.

We make no uptime commitment. The service is in active development, and the checks, the screens and these terms may change.

Scheduled checks are best-effort. A check can fail or finish only partially — when that happens the product tells you which parts did not run rather than reporting a pass.

You can delete your account at any time from Settings → Danger zone. What that removes, and the few things it deliberately does not, are described in the privacy policy — again, not restated here.

We may end your access if you use the service to examine systems you have no right to examine.

Open question: this section needs a lawyer, and five decisions nobody has made yet. First, and before the other four: who the counterparty is — Myla Security is run by an Israeli osek murshe (a registered sole trader), not a company, so these terms currently name no legal entity, and what they are is a different document depending on that answer. Then: the limitation of liability (whether there is a cap, and what it is); the warranty disclaimer (the sections above say what the product does not claim, which is not the same as disclaiming a warranty); the governing law; and the venue for a dispute. Until those are decided this page states no position on any of them, and a blank is more honest than a borrowed paragraph.

Questions about these terms, or anything else: support@mylasecurity.app.