IAMImplemented
Identity & access
Host-only sessions, short-lived scoped tokens, single-use exchanges, reserved hostnames, and least-privilege deployment identities.
Security & compliance
Trust claims should come with receipts.
Cinch treats security as a system property: designed into boundaries, tested through delivery, and demonstrated with evidence an operator can inspect.
ProofDesign, implementation, validation, and operation stay distinguishable.Evidence-led
- Trust boundaryEXPLICIT
- Control behaviorTESTABLE
- Release evidenceRETAINED
- Known limitsVISIBLE
Evidence describes the POC, not an independent audit.
This page maps engineering practices to familiar frameworks so reviewers can evaluate the control design. Cinch has not claimed a SOC 2 report, ISO 27001 certification, regulatory approval, or an auditor's opinion.
Control system
Six domains. One evidence trail.
Controls are strongest when design, implementation, test, and operating evidence point to the same boundary.
TENTested
Tenant isolation
Tenant identity is carried and enforced through database access, mutation boundaries, routing, and synchronization paths.
APPImplemented
Application security
Origin and CSRF evidence, deny-by-default CORS, secure headers, input validation, and independent public and authenticated surfaces.
SDLCEnforced
Secure delivery
Reviewed revisions, isolated release identities, dependency review, automated gates, preview environments, and exact-revision promotion.
RESExercised
Resilience & recovery
External health journeys, versioned rollback, restore procedures, replica rebuilds, and explicit recovery evidence.
GOVOperating model
Agent governance
Bounded scopes, explicit authority, reviewable artifacts, automated policy checks, and operator-owned risk and release decisions.
Approved control evidence
Security claims keep their maturity and their limits.
These claims come directly from the application evidence registry after operator review. Validation and production exercise remain visibly distinct.
Health-gated blue/green application releases
Application releases use a blue/green strategy. The complete replacement web fleet and fresh SBOM-backed image policy must pass before traffic is promoted, the prior image is retained as rollback evidence, and routine application releases leave the real-time sync service unchanged.
Why it matters
Health-gated promotion reduces release risk for authenticated customers while separating routine product delivery from maintenance on the stateful real-time sync tier.
Scope and limits
Releases on 2026-08-10 exercised healthy replacement Machines, immutable identity, public checks, the private Zero hop, and unchanged Zero. On 2026-08-11 refreshed vulnerability data blocked two candidates without an exception or promotion. Later, evidence-backed OpenSSL dispositions yielded zero blocked findings; source 70e27f0ffa484fc0964f0672fc08a567d058adb0 passed the same gate, promoted two healthy Machines, passed all twelve public checks, and left Zero unchanged. Active-session continuity remains an evidence gap, so zero-interruption wording is not approved.
Standards alignment
One control. Multiple useful lenses.
The mapping uses SOC 2 Trust Services Criteria, ISO/IEC 27001:2022, and NIST Cybersecurity Framework 2.0 as cross-references—not as a checklist substitute for an audit.
Control themeSOC 2ISO 27001NIST CSF 2.0Cinch evidence
Access boundariesCC6A.5, A.8PR.AA
Least privilege, host isolation, scoped credentials
Secure change controlCC8A.8.25–32PR.PS
Reviewed revisions, gated delivery, traceable release
Monitoring & detectionCC7A.8.15–16DE.CM
External journeys, security checks, operational signals
Availability & recoveryA1A.5.29–30, A.8.14RC.RP
Restore, rollback, resync, recovery exercises
Risk & governanceCC1–4Clauses 4–10GV.RM
Operator authority, ADRs, evidence, risk acceptance
Data minimizationP-seriesA.5.12, A.8.10–12GV.OC
Cookie-free marketing, bounded collection, separated data planes
Privacy & regulatory posture
Start with the principles regulators reward.
Data minimization, purpose limitation, access control, traceability, and recoverability create a stronger base for future privacy and sector-specific obligations.
Collect deliberately
The public site is separated from product sessions; feature requests collect only the content a visitor chooses to submit and a random voting identifier.
Limit purpose
Feature-request records exist to understand demand and prioritize delivery—not for ad targeting or cross-site profiling.
Reduce exposure
No tenant messages, credentials, authentication cookies, or product secrets are available to the marketing runtime.
Retain accountability
Changes, control decisions, and evidence remain tied to a versioned revision and an accountable operator.
Privacy laws such as GDPR and U.S. state privacy laws depend on the data, users, contracts, and operating context of a real deployment. This POC demonstrates supporting engineering principles; it does not make a legal compliance determination.
A deliberately boring boundary
The marketing site cannot read a workspace.
No product session cookiesNo tenant messagesNo authentication secretsNo application database access
The public feature board uses its own narrowly scoped datastore. It does not share a binding, secret, or runtime with the authenticated product.
Responsible disclosure
Report a vulnerability without putting people or data at risk.
Send the affected URL, potential impact, reproduction steps, and a safe proof of concept to security@cinchme.app. This is the single public destination for Cinch security controls and reporting guidance.
Keep testing safe
Do not access another person's data, disrupt service, use social engineering, or run destructive or high-volume tests.
Allow investigation
Give Cinch reasonable time to investigate and remediate before public disclosure.
Expect a practical response
Reports are acknowledged as promptly as practical, handled confidentially, and updated when possible. This pilot does not offer a paid bug bounty.
Autonomous delivery governance
Independence begins after approval—not before accountability.
The intended request-to-release loop gives an agent room to execute while keeping authority, scope, evidence, and rollback explicit.
Community signal
Requests and votes surface demand; they do not directly change production.
Agent proposal
The monitoring agent drafts scope, risk, acceptance criteria, and architectural consequences.
Operator approval
Your approval defines the bounded authority to implement, validate, and release.
Independent execution
The agent delivers the approved outcome and returns evidence, deployment identity, and rollback path.
Next: product proof