Security & responsible disclosure

Email hello@medlar.app with “Security” in the subject. A person reads it. Machine-readable contact details are at /.well-known/security.txt.

You will get an acknowledgement within 3 working days and an assessment within 10. If it is serious you will hear from us sooner than that, because we will want to talk to you.

• Test against accounts and workspaces you own.
• Don't run automated scanning that degrades the service for other people — we are one deployment, not a lab.
• Don't access another customer's data. If you reach it by accident, stop, tell us, and don't look further. We will treat that as the good-faith act it is.
• Give us a reasonable window to fix it before publishing.

We will not pursue legal action over good-faith research that follows the above, and we will not ask you to sign anything before we will read your report.

There is no bug bounty yet, so we cannot promise money. We can promise credit if you want it, and a straight answer about what we changed and when.

• Connections begin read-only. Write access is a decision somebody makes.
• Credentials never reach the model. It asks for an action; the key stays on our servers.
• Host-side app tools pass a deterministic check that the model has no vote in — an unregistered tool is refused, an unreviewed write never runs unattended, and registered recipient limits are counted before execution. Provider-hosted web search is separately allowlisted; shell, filesystem and direct network tools are disabled.
• An emergency stop blocks new external writes at their execution checks, without stopping the ability to read what happened. A provider request already in flight may still finish; stopping cannot recall an email that was already sent.
• Stored connection tokens are encrypted with AES-256-GCM. The workspace database runs in the EU (Frankfurt).
• Every run keeps a record: which agent, which tool, which account, who approved it, and what the provider actually returned.

Saying this out loud is the point of the page. A security page that lists only strengths is a marketing page.

• Workspace separation is enforced in the application, not yet in the database. Every query is scoped to one workspace and a build-time check refuses a query that is not — but there is no second layer beneath it.
• The agent can be fooled by content it reads; what it cannot do is act on it unchecked. The containment is at the action, not at the context.
• Content leaving the workspace is not yet inspected for sensitive data.
• The audit trail is append-only by convention. Each finished run's trail is sealed with a keyed digest (HMAC), chained per workspace, which lets us detect a change made directly in the database. The key is ours, so it is not something you can verify independently, and we do not describe the trail as tamper-proof.
• No independent penetration test has been carried out.
• We hold no SOC 2 or ISO 27001 certification and do not claim to. See the Data Processing Agreement.

Your data leaves your network. We would rather you hear that from us: the model runs at Anthropic and app connections run through Composio. Both are named, with the purpose of each, in the DPA, alongside every other sub-processor.

There is no self-hosted deployment. The agent engine runs on Anthropic's infrastructure, so a self-hosted Medlar would still send your data there — it would offer the feeling of control rather than control, and we would rather say no than sell that.

If we become aware of a breach affecting your data we will tell you without undue delay and as required by applicable law: what happened, which data, what we have done, and what you may need to do. An incomplete notice sent on time beats a complete one sent late.