Keep execution close. Share the minimum.

Product-preview security model · July 22, 2026

Intended data flow

1. Customer CI installs Smethe alongside the customer controller and runs the scenario locally.
2. The CLI creates an immutable provenance manifest and a separate completion object containing finite metrics, assertion outcomes, and the verdict. Together they form a versioned smethe.evidence/v1 bundle.
3. GitHub Actions authenticates with short-lived OIDC identity; supported non-GitHub CI uses a scoped upload token.
4. Smethe Cloud verifies organization and repository ownership, stores structured evidence, and writes the pull-request check.

Controller source, repository checkout, secret values, and arbitrary executable artifacts are outside the intended upload contract.

GitHub access

The planned GitHub App will request the minimum repository permissions needed to identify commits, receive relevant webhook events, and write check results. Webhook signatures, installation ownership, replay protection, and idempotency are release requirements. The final permission list will be shown before installation.

Repository access does not authorize billing. Authenticated checkout and billing-portal actions require verified organization-owner access and a same-session CSRF token; checkout is offered only after written pilot scope is accepted.

Storage and rendering

• Private report data is intended for private object storage with organization-scoped authorization.
• Paid evidence is intended to expire after 90 days; immediate deletion will be supported.
• The planned free public tier keeps seven days of run metadata.
• Uploaded HTML will not be rendered on the authenticated application origin. Dashboard views render validated structured fields; original reports, if retained, are downloads.
• Production readiness checks must fail closed when durable storage or signing dependencies are unavailable.

Application and operational controls

Before general availability, the hosted service is intended to include secure cookie sessions, CSRF protection, strict input validation, rate limiting, dependency and container scanning, secrets in a managed secret store, immutable deployments, staging, monitored health checks, backup and restore testing, and a documented rollback path.

What Smethe does not certify

Neither the core engine nor Cloud evidence proves that a controller is safe, compliant, certified, or free from defects. Security controls also do not make functional simulation an appropriate substitute for physics-based simulation, HIL, threat analysis, safety engineering, or real-world validation.

Responsible disclosure

If you believe you found a vulnerability in this website or a Smethe build you were authorized to access, email support@talkdoc.com with the subject [SECURITY] Smethe report.

• Initially include impact, affected surface, and safe reproduction steps; do not email credentials, customer data, or exploit archives.
• Test only systems and accounts you own or have explicit permission to test.
• Do not access, alter, retain, or disclose another person’s data; stop if you encounter it.
• Avoid denial of service, automated high-volume testing, social engineering, and physical attacks.

We will acknowledge a credible report as soon as practical and coordinate a secure channel if sensitive details are needed. Smethe does not currently operate a public bug-bounty program, and this page does not promise payment or create authorization beyond the scope above.

Security questions

Design partners can request a focused architecture and data-flow review during pilot scoping. General questions can be sent through the contact form.