Security
Two security teams read this: the one at the company shipping the product, and the one at the enterprise installing it. Everything below is a mechanism rather than a policy, so both can verify it instead of believing it.
Security and enterprise readiness
These are not policies. They are boundaries enforced in code, each one covered by the test suite.
Rows hold a Secret Manager name, and the name embeds the customer environment id. That is what structurally prevents two customers ever sharing a credential.
credential_referencesenv--a91f…--access_tokenxoxb-••••••••••••Credential-shaped keys are redacted from every event, audit entry and log line before they are written.
The hosted MCP endpoint resolves a bearer token to exactly one customer environment, and rejects a token issued for a different product.
Every call is checked against the capability's own schema before anything reaches your backend. Execution is audited by argument name, never by value.
Authorizations, approvals, credential rotations, state changes and executions are all recorded.
Models may suggest descriptions and mappings. Permissions, scopes, schemas and validation rules come from deterministic code.
Data flow
Four steps, in this order. The order is the security property: validation happens before the network hop, not after it.
The customer's client posts a tools/call to the hosted MCP endpoint with a bearer token issued for one customer environment. The token is the only thing that decides whose deployment this is.
The payload is checked against the capability's own JSON Schema. A call that fails is refused here. Nothing is forwarded, and the vendor backend never sees it.
The credential is fetched from Secret Manager under a name that embeds this customer environment id. It is not cached across customers and never written to the database.
Results transit Meetext in memory on their way back to the destination. They are not stored. What is written down is which capability ran, for which environment, with which argument names, and whether it succeeded.
Data handling
Capability results pass through the hosted MCP endpoint to reach the destination, so they transit Meetext in memory. They are not written down.
Review questions
No path exists to try. Tools come from the calling environment's frozen package and credentials are resolved by a name containing that environment's id. A bearer token issued for a different product is rejected without revealing whether that product exists, and cross tenant reads return 404 rather than 403.
No. Models draft descriptions and suggest mappings. Risk levels, scopes, schemas and validation rules come from deterministic code, and every write or destructive capability requires an explicit human approval recorded against a named actor.
The next validation observes the revocation, the deployment moves to disconnected, and the endpoint stops executing. Revocation is treated as an answer, not a fault: nothing done server side re-establishes it, and the customer gets a reconnection link if they want one.
Yes. Your vendor can share a security review for your specific environment. It lists every capability, its risk level and what it can reach, and each statement shows whether Meetext observed it, inferred it, or the vendor asserted it.
Posture, stated plainly
The boundaries on this page are enforced in code and covered by tests, which is a different claim from a completed audit. A SOC 2 report is not something we can hand you today. A data processing agreement is available on Enterprise, and a security review of a specific customer environment is available on every plan, including the free one.
If your procurement process needs something we do not have yet, tell us what and by when. We would rather be told the requirement than be measured against it after the fact.
Connect a source, publish, and send one link. Your next enterprise customer installs itself.
2 customer environments free, forever. No card required.