What we hold, and what we refuse to hold
megamcp sits between your AI assistant and the software you run your business on, which means we are trusted with credentials and with traffic. This page says exactly what is collected, where it lives, how it is encrypted, how long it stays, and who else can see it. It says the uncomfortable parts too. It is written to be read alongside the security page, which covers the controls behind it.
Last updated 7 August 2026. This service is operated by megamcp, 160 W. Camino Real, Unit #559, Boca Raton, FL 33432, United States, established in Florida, United States. Privacy questions go to support@megamcp.ai.
We control your account. We only process your traffic.
Most privacy confusion about a connector platform comes from mixing these up, so they are separated here and everywhere else.
Where we act as a processor, we act on your documented instructions: the connector document you approved, the tools you enabled, and the guardrails you set. A data processing agreement is available on request from support@megamcp.ai, and the subprocessor list on this page is the current one.
Eight things, and the reason for each
Nothing here is collected for a purpose other than running the product you are paying for.
Our hosting and database providers keep their own infrastructure logs of requests to megamcp, on their own retention schedules. We record the platform request id on our log rows so a row here can be joined to the platform log line for the same request. We do not collect advertising identifiers, we do not build profiles, and we do not knowingly collect anything from children.
It passes through. It does not pile up.
This is the part most people actually want answered: what happens to the contents of a tool call.
- The arguments your AI client sends to a tool, forwarded to your software in the shape the mapping defines.
- The response your software returns, passed back to your AI client. Responses are never written to our database, never cached across requests, and never used to train anything.
- Calls leave over HTTPS only, to public addresses only, and redirects are never followed, so a connector document cannot point the gateway at internal infrastructure.
- When a write needs human approval, the pending payload is held in the database encrypted, is readable exactly once, and expires after ten minutes. An hourly job sweeps whatever expired unread.
- We do not sell data, we do not share it with advertisers, and we do not use your business data or your tool traffic to train models. There is no analytics pipeline over log content, internal or third party.
Sealed with AES-256-GCM, and an honest list of what is not
- Upstream credential material, including OAuth access and refresh tokens
- Gateway bearer tokens for each connection
- Client secrets for OAuth apps you bring yourself
- Pending approval payloads and OAuth authorization state
- The checkout payload held between starting a subscription and provisioning it
- Activity log arguments and audit log change diffs, which sit in Postgres under the platform's disk encryption rather than a second application-layer key. This is exactly why the redaction setting below is the control that matters
- Invite tokens, OAuth authorization codes, and refresh tokens for our own authorization server are not stored at all, in any form: only their SHA-256 digests are kept, so an observed row cannot be replayed
- Connector configuration, which describes your integration rather than carrying your business data
Every sealed record gets a fresh random initialization vector and is authenticated, so tampering makes the decrypt fail rather than succeed quietly. One server-side key does that work and it is held in the deployment environment, scoped to production only. There is no managed key service, no envelope encryption, and no key-rotation path yet, and we would rather you knew that than assumed otherwise. In the database itself, every table has row-level security enabled with no policies and explicit privilege revocations on top, so browser-facing roles can read nothing at all: access is server-side only.
You choose how much of a tool call we store
The activity log always records that a call happened, who made it, which tool, and what the outcome was. What it keeps of the arguments is a setting on your connector, changeable at any time, and it applies inside the engine before anything is written.
Machine-built connectors start at field names only, because a mapping nobody has reviewed should not be the thing that decides your arguments are safe to store. Verified connectors start at full, on the theory that you asked for an audit trail. Either way it is your call, and the change is itself recorded in the audit log. Systems that hold health records, consumer financial records, or similar regulated data are not self-serve here at all: we detect them at intake and route you to a compliance conversation instead.
Ninety days by default, and the part that is not built yet
- Each connector carries a retention setting, expressed in days, defaulting to 90 and settable between 1 and 365.
- Stated plainly: that setting is recorded and displayed, and the scheduled purge that would enforce it is not built. The database function that could delete log rows has EXECUTE revoked from every role, so nothing in the running system can remove a log row today. Until the purge job ships, activity and audit rows persist.
- Log rows survive cancellation and deletion on purpose, so an offboarded member's history stays attributable. There is no self-serve export yet either, so ask us and we will produce the rows for your connector.
- Pending approvals and rate-limit windows expire on a timer and are swept hourly.
- Stored credentials are the exception and are destroyed immediately on revoke or cancellation, not aged out.
- Stripe keeps its own records of your payments for as long as its own obligations require, independently of anything here.
Five companies, and exactly what each one sees
This is the current list. If it changes, this page changes with it, and customers with a signed agreement are notified per that agreement.
The software you connect a connector to is not our subprocessor. It is your vendor, under your agreement with them, and we call it on your instruction using the credential you supplied. Storage is single-region at this stage, in the United States (us-east-1), and processing happens there and in the regions our hosting provider runs functions in.
Leaving is clean, with one exception
- Pause stops a connector or a single connection instantly. Nothing is cached that could serve past it, and your configuration is retained.
- Revoke is permanent. The URL deactivates, the stored credential is hard-deleted rather than flagged, and calls already in flight fail rather than complete.
- Cancelling a subscription runs the same destruction across every connection under that connector, and the process retries until it actually succeeds rather than reporting a completed offboarding it did not perform.
- We do not call your provider to revoke an OAuth grant. We destroy our copy of the token, which stops it working here. Remove megamcp's access in that provider's own account settings to end the grant itself.
- Deleting your account removes your connectors, connections, encrypted credentials, and billing records by cascade. There is no self-serve delete button yet, so write to us and we will do it and confirm when it is done.
- What deletion does not reach: activity and audit rows, including the email snapshot on an audit row. Both tables are append-only by construction and the purge capability is currently revoked, so we cannot honestly promise erasure of log history today. If that is a blocker for you, tell us before you build a connector.
How to actually use them
- Ask what we hold about you and get a copy.
- Correct anything wrong. Most of it you can edit yourself in the dashboard.
- Delete your account and everything that cascades from it, with the log-row exception stated above.
- Get your activity history for a connector. There is no export button yet, so this one is a request to a human.
- Object to or restrict processing, and complain to your local supervisory authority if you are in a jurisdiction that provides one.
Email support@megamcp.ai from the address on the account. We answer within 30 days and will tell you plainly if something you asked for is one of the things we cannot do yet.
What is in your browser, and what is not
- Session cookies set by Supabase Auth to keep you signed in. Necessary for the product to work.
- A short-lived, HTTP-only cookie issued during a password reset, valid for fifteen minutes, which exists so that holding a session alone cannot be escalated into a password change.
- A draft of the connector wizard held in your browser's local storage so you can leave and come back. Credentials are never part of that draft: they are held in memory and sent straight to the server.
- No analytics, no advertising or tracking pixels, no session replay, and no third-party scripts on any page.
How you find out when this changes
We update this page when the product changes, not on a schedule, and the date at the top moves when we do. Material changes to what we collect or who processes it are announced by email to account owners before they take effect. If we suffer a breach affecting your data, we notify you and any regulator we are required to notify, with what we know and what we are doing about it.
Read it, then send it to whoever has to approve this
The security page covers the identity model, kill switches, and offboarding guarantees in the same plain language. Then connect your software and try it with no card.