Don't trust us — verify us

The rest of this page is the detail your security reviewer will ask for — the gate every action passes, what a CXO can see, and what is ours versus other people's open-source work.

The governance plane — one gate, every action

The part that makes a Pie governed rather than merely useful is ours. Every action a Pie attempts passes a single gate; nothing routes around it: kill switch → per-Pie pause → policy → autonomy floors → approval. What the gate enforces:

• Live One-tap approvals. A default-deny broker parks anything sensitive until you tap Approve or Deny. Each approval is time-boxed and single-use — silence means no.
• Live Autonomy dial, L0–L3. Each Pie runs from observe-only to trusted. Above the dial sit platform floors you cannot configure away: payment.* and data.delete always need a human — enforced in code, not a setting.
• Live Hard-stop budgets. Per-Pie and per-company caps at the model gateway; a Pie that hits its cap stops. Cost-spike anomaly rules watch for runaway burn.
• Live On-device PII shield. Aadhaar, PAN, Luhn-checked card numbers, email and phone are redacted on the device before any model sees them.
• Live Content guardrails. Before/after hooks (regex, JSON-schema, code-detection) run in the open SDK — no third-party guardrail SaaS in the path.
• Live Kill switch. One tap pauses every Pie on the instance instantly; the stop is recorded in the chain and is resumable.
• Live Durable-once delivery. A governed reply reaches the customer exactly once behind a stable idempotency key — retried through an outage, dead-lettered, never double-posted.
• Live Governance metrics. A Prometheus surface computed from the signed chain itself. Your monitoring reads the same record your auditor does.

Our access. Support access to your tenant is scoped, time-boxed, reason-logged, and shows up in your own audit log — our actions are hash-chained too.

What leaves your premises

Controlled by the telemetry dial, enforced on-device before anything is sent:

CXO oversight — the Fleet console

When pods enrol with our cloud, a CXO or org admin gets one pane over the whole fleet — and it works without ever reaching into a pod. Each pod calls out on a heartbeat with a secret-free self-report; controls are queued as commands the pod pulls on its next beat. From the console an admin can:

• See live pod state — service health, companies, Pies, configured providers, and spend today/this month in exact micro-USD.
• Hold the controls — pause or resume a single Pie, or the whole fleet, from the cloud.
• Set the org leash — allowed BYOK providers, a monthly budget ceiling, an autonomy ceiling L0–L3 (a ceiling only — the floors always still apply), and an allowlist of hosts any pod may reach.
• Approve hires and watch anomalies — approve or reject a new-hire board request; chain-verified ingest flags cost spikes, repeated denials, chain gaps and odd-hours activity.
• See the surface, never the content — which governed connectors each pod runs (names + tool counts, never a token) and a secret-free Founder OS rollup — org names + counts, never a value.

Fleet ingest, org policy and the command channel are shipped and chain-verified Live; a richer live CXO dashboard is being extended Roadmap. A pod only appears here once it's enrolled — Solo pods report to no one.

Connectors, data boundaries & your own database

• Enableable Governed connectors. Every MCP tool the pod gains is classified, its first use asks you, and a server that changes a tool must re-earn approval (input-schema-hash drift). Endpoints are checked against an SSRF denylist; parameters are hashed on the chain (raw bytes never land); connector tokens are AES-256-GCM encrypted and write-only.
• Founder OS boundary. The operating plane lives in the pod's own database. The cloud only ever mirrors a secret-free rollup — names and counts — never a field label or a cell value.
• Enableable Your own database. Opt-in, one-way export to a Postgres, MySQL or MongoDB you control. The connection string is AES-256-GCM encrypted and write-only; the pod pushes OUT on demand — never inbound.

What we built — and what is other people's work

The enforcement above is ours. So is the evidence layer beneath it — the record that proves what happened, verifiable without us.

On the last row, plainly: the thin layer is committed to Apache-2.0 and is not published yet. Until it is, treat it as intent, not something you can go and read. Everything above it — this control plane, the fleet and mentor consoles, provisioning, licence issuance — is not open source and is not planned to be.

What we stand on

Everything the Pie runs on is third-party open source, and we name it — Apache-2.0/MIT-class only, local models Apache-2.0 or MIT. The per-release SBOM is published alongside each golden-image version.

We also publish an MIT platform toolkit on npm: @demystify/rag, @demystify/extract, @demystify/events, @demystify/gateway-sdk, @demystify/platform-contracts, @demystify/platform-observability, @demystify/platform-profiles, @demystify/platform-state and @demystify/voice-client — published and open, but no Pie depends on them yet. When that changes, the capability list will say so.

DPDP mapping DRAFT

Full DPA template available on request (DRAFT — pending legal sign-off).

Responsible disclosure

Found a vulnerability? Email security@dmstfy.com. We acknowledge within 48 hours, commit to a fix timeline within 7 days, and credit researchers who report in good faith. Critical agent-runtime CVEs are patched fleet-wide within 72 hours of disclosure. DRAFT — policy text pending sign-off