Incident response runbook.

Use the security@mesedi.ai inbox only when a project-admin key has been compromised. A project-admin key is the highest- privilege credential on your project: it can mint or revoke any other key on the project, change project configuration, and read all telemetry. If one of those leaks, the blast radius is broad and the response involves suspending the project.

For read/write keys, do not email us. Read/write keys are scoped to a project and are managed entirely by your own admin. If a read/write key is compromised, rotate it from the API Keys page in your dashboard at app.mesedi.ai. Mesedi does not get involved in read/write key rotation because the customer admin who issued the key is the right person to revoke it, and we should not be in the loop for every routine rotation.

Email security@mesedi.ai with the information below. The more of these you include, the faster we can verify the report is legit and act on it.

• The key prefix (e.g. mesedi_sk_a1b2c3d4). Do not send the full secret in the email; the prefix is enough for us to identify it in our system.
• The project ID the key belongs to, visible at the top of the API Keys page.
• Your owner email for the project. We cross-check this against our records as basic identity verification before acting.
• How and when the key leaked, in one or two sentences. e.g. “pasted into a public Slack channel at 14:30 UTC on 2026-06-18”. Helps scope the report we send back.
• If you already rotated the key in the dashboard, say so. The action we run is idempotent against an already-revoked key.

The procedure below is the same one we commit to in the Terms, broken out step by step. Steps 2 through 5 are a single transaction in the admin tool; the operator clicks one button after acknowledging your email, and all four happen together.

1. Acknowledge within 48 hours. A human reads your email and replies confirming we have it. If you do not hear back inside 48 hours, escalate by replying to your original email; the bounce-back handler routes to a secondary inbox.
2. Record the report. We open an internal abuse-signal record on the project so the action is auditable from our side.
3. Suspend the project. Every authenticated request to your project starts being rejected with HTTP 403. This stops further unauthorized traffic from the leaked key (and from every other key on the project as a side effect). The suspension is reversible; once you have rotated upstream credentials and confirmed you are ready to resume, we lift it.
4. Revoke the key. The leaked key is deleted from our records. Project suspension already blocks it, so this step is belt-and-suspenders; if you ever ask us to lift the suspension later, the leaked key still cannot be used.
5. Share the recent-use report. We generate a JSON report of every agent run and every authenticated HTTP request attributed to the leaked key for the prior 90 days, and email it to you. See the next section for what is in the report.

The report is a single JSON file you can open in any text editor or feed to your own forensic tooling. It contains:

• Identifiers and timestamps. The key id, key prefix, project id, the time the report was generated, and the time window it covers (the last 90 days up to the report time).
• Agent runs. For each execution attributed to the leaked key: execution id, status, start and end timestamps, duration, SDK language, and the crash signature if the run terminated abnormally. Read this list to know which workloads ran on a compromised credential.
• Request log. For each authenticated HTTP request attributed to the leaked key: timestamp, method, URL path, response status, and client IP address. Read this list to know what endpoints the attacker probed, including read-only endpoints that did not create agent runs.

The report does not include full event payloads (LLM prompts, tool arguments, model outputs). Those stay in your dashboard; you can drill into any execution by id if you need more detail.

If you need information older than 90 days, tell us in your email. We may have it, depending on retention; we will tell you honestly what we still have and what has already aged out.

We list these explicitly so expectations are calibrated before an incident, not during one.

• We do not refund charges incurred from a compromised key. Customers are responsible for keeping keys secret; this is consistent with how every cloud platform treats key compromise. If your agent uses upstream model providers (Anthropic, OpenAI, others), those charges are between you and the upstream vendor and we cannot influence them.
• We do not run a 24/7 hotline. The acknowledgement SLA is 48 hours during business hours US Eastern. Mesedi is a small team; if you need an always-on incident response service, that does not describe us today, and it would be unfair to charge you as if it did.
• We do not take action without your written confirmation.We will not suspend your project, revoke a key, or change any customer-state value based on a phone call, an inbound webhook, or a report from anyone other than the project's verified owner email. This is intentional: it makes social-engineering attacks on Mesedi much harder.
• We do not run automated content scanning on your telemetry to flag possible compromises for you. Our compromise workflow only fires when you report it. If you want automated key-leak detection (e.g. GitHub's secret-scanning push protection), configure that on the source-control side.

The security@mesedi.ai inbox is for project-admin key compromises and for vulnerability disclosure. If you found a vulnerability in Mesedi itself, the vulnerability disclosure section of the Security page has the program details, including the appreciation credit we apply to your account for verified in-scope reports.

For everything else (general support, billing questions, feature requests), use the dashboard's support widget or email hello@mesedi.ai. Mixing those into security@ slows the security inbox down for actual incidents.