Memeri — Security & Responsible Disclosure

Part 1: security.txt

To be served at https://memeri.ai/.well-known/security.txt (RFC 9116). Plain text, UTF-8, HTTPS only.

# Memeri security contact — see https://memeri.ai/security for our full
# vulnerability disclosure policy, scope, and safe-harbour statement.

Contact: mailto:security@memeri.ai
Expires: 2027-06-15T00:00:00.000Z
Policy: https://memeri.ai/security
Preferred-Languages: en
Canonical: https://memeri.ai/.well-known/security.txt

Part 2: Vulnerability Disclosure Policy

Page: https://memeri.ai/security — Last updated: 15 June 2026

The short version

If you find a security problem in Memeri, please tell us at security@memeri.ai. We'll respond like engineers, not lawyers: we'll thank you, we'll fix it, and as long as you follow the rules below, we will not take legal action against you. We're a small team in private beta — your reports genuinely shape the product.

Who we are

Memeri (Memeri Ltd, "we"/"us") is a persistent AI workspace for software development. Users connect their own AI coding agents (Claude Code, Custom GPTs, Codex) to Memeri via an MCP gateway; Memeri stores project memory, workflows, decisions, and agent telemetry server-side, while agents execute on the user's own machine through a local console. That architecture matters for scope — see below.

Scope

In scope:

• memeri.ai and its subdomains operated by us, including the web app and API (/api/...)
• The Memeri MCP gateway service (MCP endpoint and /v1/tools/... REST surface)
• The WebSocket tunnel/relay between local consoles, the platform, and AI clients
• The memeri-console local console software and memeri CLI as distributed by us
• Authentication, session, and token handling (JWTs, connection tokens, gateway API keys, pairing codes)
• Tenant isolation — any way to read or modify another user's projects, conversations, memory, telemetry, or files

We are especially interested in: cross-tenant data access, authentication/authorization bypasses, ways to make an AI agent execute commands on a machine its user didn't authorize, token leakage, and injection into the agent tool-call pipeline.

Out of scope:

• Vulnerabilities in third-party services we use or interoperate with: Railway (hosting), Resend (email), GitHub, Anthropic/OpenAI and other AI providers, jsDelivr. Report those to the vendor — though if the issue is a Memeri misconfiguration of such a service, or a flaw in how our platform calls or integrates such a service (for example, our code sending data to an AI provider in a way an attacker can influence), that's our scope and we want to know.
• Your own machine and your own agents. Memeri's design runs AI agents with your privileges on your hardware; "the agent I authorized did something I told it to do" is not a vulnerability. "An agent or another user could do something I didn't authorize" absolutely is.
• Denial of service, volumetric attacks, and resource exhaustion testing.
• Social engineering, phishing, or physical attacks against our team or users.
• Spam, SPF/DKIM/DMARC-only reports, missing best-practice headers without a demonstrated impact, clickjacking on pages with no sensitive actions, and automated scanner output with no analysis.
• Anything requiring a stolen device, malware already on the victim's machine, or a compromised AI-provider account.

Rules of engagement

To stay within this policy (and our safe harbour):

1. Only test against accounts you own or accounts where the holder gave you explicit permission. Never access, modify, or delete another user's data — if a flaw exposes someone else's data, stop at the minimum proof needed (e.g., a record ID or redacted screenshot), don't browse.
2. Don't run agents or commands against machines you don't control. The console/tunnel executes real shell commands on real developer machines. This applies to prompt-injection and agent-pipeline testing too: if you're testing whether injected content can steer an agent or its tool calls, point it only at your own agent running on your own machine, never at another user's session.
3. No data exfiltration. Download the minimum needed to demonstrate the issue, keep it confidential, and delete it once the report is resolved.
4. No service disruption — no DoS, no destructive testing, no degrading the beta for other users.
5. Don't pivot. If you land on infrastructure (e.g., the database, Railway internals), demonstrate access and stop.
6. Give us reasonable time to fix before public disclosure — see coordinated disclosure below.
7. Don't extort. Reports conditioned on payment are outside this policy.
8. Follow the law. This policy authorizes testing of our systems under our rights; it doesn't authorize anything that's independently unlawful where you are — including how you handle any personal data you encounter (see below).

If you encounter personal data

Memeri has only one environment: production, with real beta users' real data — there is no staging or sandbox. So this part matters:

• If your testing surfaces another person's data (account details, project content, conversations, telemetry), stop at the minimum proof needed, don't read further, don't copy more than that proof, and tell us immediately.
• Store any such proof securely, share it with no one but us, and securely delete it once we confirm the issue is resolved (we may ask you to confirm deletion).
• Tell us right away if you believe someone other than you may have accessed user data — we may have notification obligations to users and regulators under applicable data-protection law, and your prompt report directly affects our ability to meet them.

Research accounts: because the beta is invite-only, you may not be able to self-register. Email security@memeri.ai and we'll happily set up an account for security research — please don't test using another user's borrowed account.

How to report

Email security@memeri.ai with:

• A description of the issue and where it lives (URL, endpoint, tool name, component)
• Steps to reproduce — a curl command, request/response pair, or short PoC beats prose
• Impact as you understand it (what could an attacker actually do?)
• Your handle/name if you'd like credit, or say so if you prefer anonymity

You may report anonymously. We don't require an NDA and we won't ask you to sign one to be told the fix status.

What to expect from us

We're a small team, so these are honest targets rather than contractual SLAs:

• Acknowledgement of your report within 3 business days
• Initial assessment (valid / duplicate / out of scope, and severity) within 7 business days
• Status updates at least every 14 days while we work on a fix
• We'll tell you when the fix ships and, where practical, let you verify it
• Credit, if you want it, once the issue is resolved

Rewards: Memeri is a pre-revenue private beta and we do not currently run a paid bug bounty. We offer sincere thanks and public credit. If that changes, this page will say so.

Coordinated disclosure

We ask for 90 days from your report (or from our acknowledgement, whichever is later) before public disclosure, extendable by mutual agreement if a fix is genuinely hard. We'd rather you publish a great write-up of a fixed bug than sit on it forever — once a fix has shipped, we're happy to coordinate timing and will link your write-up if you like. If we're unresponsive for 30 days despite good-faith attempts to reach us, you may disclose responsibly.

Safe harbour

We consider good-faith security research conducted under this policy to be authorized within the meaning of applicable anti-hacking and anti-circumvention laws (including the Computer Misuse Act 1990 in England & Wales). Specifically, if you make a good-faith effort to comply with this policy:

• We will not initiate or support legal action against you for your research, and we waive any claim we might otherwise have under our terms of use, if any, for the testing activity itself;
• We will consider your research authorized access under applicable computer-crime law, and your security testing exempt from anti-circumvention claims to the extent we can grant that;
• If a third party brings legal action against you for activity conducted in accordance with this policy, we will make it known that you acted in good faith under our authorization.

Limits, stated plainly: we can only authorize testing of our systems — this safe harbour cannot bind Railway, AI providers, GitHub, other users, or law enforcement, and it doesn't apply to activity outside the rules of engagement above. If you're unsure whether something is covered, ask first at security@memeri.ai — we'd rather answer a question than litigate a misunderstanding.

Known issues and honesty

We're in private beta and we know our security posture is a work in progress — we maintain an internal list of known weaknesses and are fixing them in priority order. If you report something we already know about, we'll tell you it's a known issue (it won't be eligible for credit as a new finding, but we'll still confirm and thank you). We won't pretend a real issue is "by design" to dodge it.

Handling of your report data

Reports sent to security@memeri.ai are read by our core team. We use report contents only to investigate and fix the issue, share them with service providers only as needed to do so (e.g., our hosting and email providers), and keep them as long as needed for remediation and audit history. We won't share your identity outside the team without your consent, except where the law requires.

Changes to this policy

We may update this policy; the version at https://memeri.ai/security and the Policy link in our security.txt are canonical. Testing performed in good faith under the policy version current at the time of testing remains covered.

Questions about this policy (not vulnerability reports): support@memeri.ai.