MARS
Security

The input is hostile. MARS is built on that assumption.

Every email, link, attachment and XDR field MARS handles was written by someone else, often an attacker. These are the controls at each point where that material crosses a boundary.

Five boundaries, and what guards each

  1. 01

    Reading hostile input

    Mail and attachments are parsed and inspected, never run.

    • Attachments are analysed statically. Archives are unpacked within fixed limits on depth, entry count, size and compression ratio.
    • Every hop of a link is checked before MARS connects, and addresses inside your network are refused.
    • Parsing is bounded: nesting is capped and the scanning steps take time in proportion to the size of the mail.
    • Sandbox containers run with all capabilities dropped and no way to gain privileges.
  2. 02

    What is sent to the AI

    The model sees evidence, marked as evidence.

    • Attacker-controlled text is wrapped in a boundary with a fresh random marker on every call. Forged markers inside the text are neutralised.
    • Internal mailboxes and account names can be replaced with pseudonyms before a prompt leaves, and restored in the reply.
    • The AI endpoints MARS may contact are set on the host. The web console cannot widen that list.
    • When a prompt is too large, evidence is dropped whole, so the boundaries and rules stay intact.
  3. 03

    What comes back

    An answer is checked before anyone sees it.

    • The reply must fit a closed schema. A truncated or malformed reply is rejected.
    • A conclusion with too little evidence behind it is withheld.
    • Anything that fails a check stops at "needs review", with a reason code.
    • There is no path that executes a response action without a person approving it.
    • A change to the instructions is detected automatically and has to be approved as a release. Known cases can be replayed to compare quality first.
  4. 04

    Console and API

    Signed-in users get what their role allows.

    • Permissions are set per role, per module and per action. The read-only role cannot change anything.
    • API keys are stored as hashes and can be rotated with a grace period.
    • Sign-in can use LDAP over an encrypted connection, or OpenID Connect.
    • Hunting queries, whether written by a person or by the AI, are validated against an allowlist before they run.
    • Every write is recorded in a signed audit log kept in its own database.
  5. 05

    Settings and secrets

    Secrets stay out of the browser.

    • Provider keys, the session secret and the audit signing key live in a root-owned file on the host and cannot be edited from the console.
    • Each setting has one source of truth, so a value shown is the value in effect.
    • Update packages are verified by checksum before they are applied.
    • Backups run on a schedule, and another is taken before every database migration.
Known limits

What MARS does not protect against

A security product should say where its guarantees end.

One instance

MARS runs as a single instance on one host. It is not a high-availability cluster.

The sandbox is not the last line

Containers are hardened, but put them on a network segment you can throw away.

The AI provider is outside

MARS checks what a provider returns. It cannot promise the provider keeps no record of what it was sent. Choose where the model runs accordingly.

ARC signatures are not verified

Authentication results forwarded through an ARC chain are passed to the AI as claims, with that caveat.

The host is yours

Patching, disk encryption, network segmentation and off-site backups are the deployer's responsibility.

Judgement can still be wrong

The checks catch unsupported answers. They do not make the model right, which is why response actions need a person.

Reporting a vulnerability

Report a suspected vulnerability in a deployment to that deployment's MARS administrator, not in a public issue.