Safety is the work, not the disclaimer.

What Mara will not do.

• —Author functional offensive code targeting a specific named victim, environment or asset.
• —Author novel exploit code for unpatched vulnerabilities.
• —Help with operational planning of intrusions, fraud or extortion.
• —Defame, doxx, or attribute attacks to identifiable individuals.
• —Produce content for harassment, child safety violations, or other prohibited categories.

These boundaries are enforced through training, refusal behaviour and a separate review layer. They are not perfect. The model card documents the failure modes we have measured.

What Mara will help with.

• —Detection engineering, threat modelling, red-team / blue-team education.
• —Analysis of samples already in the wild and reported on publicly.
• —Reasoning about adversary TTPs at the level of frameworks like ATT&CK.
• —Writing the artefact: post-mortems, customer notes, runbooks, detection rules.

How we evaluate.

We test Mara on the work, not on trivia. Our evaluation panel includes practising SOC analysts, IR consultants, threat-intel leads and an external red team. They run live cases, score calibration and refusals, and challenge the model in the directions they know it should resist. We publish the results, including the failure modes.

Responsible disclosure.

If you find a way to make Mara do something it should not, or a failure of judgement that matters, please tell us before telling anyone else. We respond inside one business day and credit researchers who would like to be credited.

Email hello@venode.ai with the subject “Safety report”.

On the boundary itself.

Where the line between defensive and offensive sits is a judgement call, and not always ours alone. We write up specific cases in our research notes, including the ones where we changed our minds. Read Working in the open for the longer argument.