Security

Security and governance

This public site is a presentation layer. It is not an authorization boundary and does not execute governed actions.

How the platform is designed

MasterEngine treats authorization as infrastructure — not a UI convention or model prompt.

Designed authorization boundary

PostgreSQL and the approval layer are the only authoritative write and authorization path. No alternate mutation routes from UI, models, or connectors.

Proposal-only models

Models, retrieved documents, memory, and UI buttons propose — they never grant themselves permission or trigger privileged side effects.

Exact-subject approval

Protected actions require a human decision bound to the exact subject. Change a bound field and the approval invalidates.

Server-enforced tenancy

Tenant isolation is enforced server-side and at the database — not by caller-supplied headers or programmer-discipline WHERE clauses.

What this public site will not do

Clear boundaries keep the marketing surface honest while the governed kernel matures.

The waitlist form opens a mailto draft. It does not persist leads to Postgres, a CRM, or any other store.
Mission Control is a synthetic demo: no live customer systems, credentials, auth claims, or side effects.
This Next.js app may not define mutation handlers under /api/control-plane/*.

What this surface can and cannot do

A checklist for reviewers. It covers the public masterengine.ai site and its synthetic demo only — not the governed approval layer behind it.

This site can

Serve static marketing pages and a labeled synthetic Mission Control demo with example data.
Answer GET-only demo routes under /api/control-plane/*/demo that self-report mode: synthetic_demo.
Open a prefilled email draft in your own mail client when you use the waitlist form.
Offer a private sign-in at /login that fails closed when the approval layer is unconfigured or the principal is unknown.

This site cannot

Execute a governed action or write to the approval layer.
Store a waitlist submission in Postgres, a CRM, or any other store.
Create an account, an organization membership, or an approval from the browser.
Approve, defer, or reject anything in the demo — those controls are disabled.
Connect to a customer system or hold customer credentials.

Design rules behind the boundary

These are MasterEngine architecture rules. They describe how the platform is designed to behave as it matures; they are not a certification or an audit result.

Memory may inform a proposal but never authorizes a consequential action.
Tool adapters such as MCP sit behind the gateway, policy, budget, approval, and evidence path; an inbound client token is never passed through to an upstream API.
Untrusted or arbitrary code never runs inside the approval layer.
Execution is designed to use a narrow, short-lived grant bound to the action, its arguments, targets, tenant, and cost.

Security review

Review requests go to founder@masterengine.ai. We respond to substantive architecture and tenancy questions — not generic sales inquiries routed through this channel. Describe the page or route, what you observed, and how to reproduce it. Please do not email passwords, API keys, or real customer records; email is not a secure intake channel.

Inspect the synthetic demo

Mission Control shows the governed workflow with labeled example data — no live approval-layer writes from the browser.

Open Mission Control →Contact the team