Trust center

Built to survive your IT reviewer

Universal coverage without a universal safety model is a liability engine. This page is the model: how identity works, how credentials are handled, what happens when you leave, and where we honestly say no. Forward it to whoever has to approve this.

Architecture principles

The rules everything else follows

One engine, one audit surface

Every connector executes on the same hardened runtime. There is no per-customer executable code: a connector is a declarative mapping that cannot express arbitrary computation, network calls to unlisted hosts, or credential access outside its own vault reference. The mapping schema is the security boundary, and it is versioned, validated, and reviewable.

One grant, per-action approval

The connector requests the scopes its tool surface needs at connect time, so it works the moment you connect. The guardrail is per-action, not per-scope: every write still asks first, and you can turn tools off at any time. Expanding the tool surface later requires a fresh consent.

Writes ask first, previewed, and logged

Writes work out of the box, and nothing executes unapproved: every write pauses on a confirm-mode preview, delivered as a human-readable diff through the protocol's native Multi Round-Trip Requests, and runs only when the person who invoked the tool approves it.

Graduated trust for machine-built connectors

Auto-built long-tail connectors launch with strict defaults: writes confirm-only, destructive operations enabled only in dry run, where they demonstrate what they would do and never execute until you graduate them, and argument values redacted out of the activity log. They earn autonomy through human review or incident-free confirmed-write history. Build provenance is always visible.

Identity model

Chosen and disclosed, never discovered

Whose credentials does the connector use, and who does the upstream system think is acting? You choose the answer at build time, and we state it everywhere.

Team mode

The default wherever the upstream supports per-user credentials. Each member's connection carries their own upstream identity, so audit trails in your systems are truthful. Every call executes with that member's own credential, so the connector's guardrails and that person's upstream permissions both apply and the AI can never exceed what the invoking person could do themselves. We do not read your upstream permission set to predict that in advance: we enforce the guardrails here, and your system enforces the rest.

Solo mode

One credential, one URL, disclosed in plain language at auth time and in the dashboard: this connector acts as the connected account, and anyone using this URL acts as that account. We recommend a dedicated service account where the upstream supports one. Systems that only support a single org credential are Solo-only and badged as such at intake, never silently faked.

In both modes, each connection carries a distinct gateway token, so megamcp's own activity log preserves per-connection traceability even when the upstream sees a single account. On the client side, the gateway implements the hardened 2026-07-28 authorization profile: RFC 9207 issuer validation, issuer-bound credentials, and CIMD as the registration path.

Credential handling

Your keys, treated like keys

Encrypted at rest with AES-256-GCM, a fresh random IV per record, authenticated so tampering fails the decrypt
Never logged, never returned by any tool
Decrypted only server-side, never in a browser and never on a response
Isolated per connector and per connection
Destroyed on cancellation or revoke, hard-deleted, not soft-deleted
One server-side key held in the deployment environment. There is no managed KMS, no envelope encryption, and no key-rotation path yet

Offboarding

Leaving is clean here

All connector URLs deactivate immediately on cancellation or trial expiry
Stored credentials are destroyed on the spot, hard-deleted, not soft-deleted
We do not call your provider to revoke an OAuth grant. We destroy our copy of the token, which stops it working here; go to that provider's account settings and remove megamcp's access to end the grant itself
The same applies per member: revoking one connection deactivates that person's URL and destroys their stored credential without touching anyone else, and their grant should also be removed at the provider
Activity log rows survive cancellation. There is no export and no scheduled purge yet, so those rows stay until we build both

Prefer to keep your configuration? Pausing retains it and stops every connection instantly. Pausing does not touch your subscription, so billing continues until you cancel.

Activity log and redaction

Audit everything, store what you choose

The activity log records every tool call: who, what, when, and result, with confirmation events captured per round-trip. It is append-only by construction: the application role holds insert and select and nothing else, and the database refuses any update, delete, or truncate. Export is not built yet. What the log stores about your business data is up to you.

Full arguments

Complete tool-call arguments, for teams that want maximum audit detail.

Field names only

Which fields were touched, with values redacted. The default for sensitive verticals.

Hashes only

Tamper-evident records with no argument content stored at all.

Logs live in Postgres, covered by the platform's at-rest disk encryption. Argument content is not separately encrypted at the application layer, which is exactly why the redaction setting above is the control that matters. Log content is not copied anywhere else: there is no analytics pipeline, internal or third-party. Each connector carries a retention setting, but it is recorded rather than enforced, because the scheduled purge is not built yet. Storage is single-region at v1, stated plainly.

Kill switches

The panic button is one click away

User pause

One click, instant, for a whole connector or a single member's connection. Nothing is cached that could serve past it, so the very next request is refused.

Revoke

Permanent, for a whole connector or one member. URLs deactivate, stored credentials are destroyed, and calls already in flight fail rather than complete.

Rate ceilings

Every connection carries a fixed per-minute write and read budget, counted in shared state at the gateway. If the counter cannot be read, the call is refused rather than allowed through.

Two switches we do not have yet, said plainly: circuit breakers that trip automatically on error storms or anomalous write bursts, and a fleet-wide shutdown that disables one mapping across every affected customer at once. An upstream incident today is handled connector by connector.

Regulated data

Where we honestly say: not self-serve

Systems that store PHI, consumer financial records, or similar regulated data are not self-serve in v1. We detect them at intake and route you to a compliance conversation with our done-for-you team, where BAAs and appropriate infrastructure commitments are handled per engagement. That is a trust posture, not a rejection: you get an honest path instead of a quiet liability.

Compliance conversations: customconnectors.ai Check your system at intake

Also available: DPA on request and a current subprocessor list. A downloadable policy summary covering scopes, enabled tools, safety modes, identity model, logging settings, build provenance, and protocol posture is planned and not built yet. Until it ships, ask us and we will put the same information in writing for whoever approves tools like this.

Disclosure

Reporting a vulnerability

Found something? Report it to support@megamcp.ai. We reply, and we keep you informed while we fix it. We will not pursue good-faith research conducted without data destruction or privacy violation. A machine-readable version of this policy lives at /.well-known/security.txt.

Send this page to your reviewer

Then connect your software and watch a supervised write run on your own data. Evidence beats assurances.

Get your Blueprint