Security
What it can touch, and what it cannot
An agent that works unattended has to be safe to leave alone. This is how Marlow is built to be, and where it still falls short.
Safeguards
- Each run gets its own container
- On the sandbox image the project sets, with memory, CPU and process limits. Its volume is discarded with the run.
- Secrets are encrypted at rest
- AES-256-GCM, so a tampered value fails to decrypt rather than reading back wrong. Project variables can come from your own Vault or OpenBao instead.
- Organisations are kept apart
- Every secret read is checked against the organisation asking for it, and someone else's secret reads exactly like one that does not exist.
- A second vendor reviews the diff
- The model that reviews a change always comes from a different vendor than the model that wrote it.
- Your scanner, not ours
- Name the SARIF scanner the project already trusts — Semgrep, CodeQL, Trivy, gitleaks — and it runs on each change Marlow writes and each pull request it reviews. A scan that leaves no report is never counted as clean.
- Migrations run before they merge
- A change carrying a migration is executed against a shadow database, not only read.
- Every change is on the record
- One append-only row per mutation: organisation, actor, action, target, payload and time.
- It can run in your network
- A Helm chart and a compose file, with nothing durable on local disk.
Not yet
- Is it certified?
- No. There is no SOC 2 or ISO certification yet.
- What can each person do?
- Two roles, owner and member. There is no finer-grained permission model yet.
- Can we bring our own identity provider?
- Not yet. Sign-in goes through our hosted login, with no SAML or SCIM.
- Is there a bug bounty?
- No. Reports are answered and credited, not paid.
Report a vulnerability
Email security@getmarlowai.com with what you found and how to reproduce it. Please give us the chance to fix it before you disclose it.