Security and responsible reporting

Zinvyl limits public inputs, separates routing from payment authority, and records evidence without claiming perfect security.

Effective October 27, 2026

Current controls

Public traffic uses encrypted HTTPS. Browser responses use restrictive content, framing, referrer, permissions, and transport headers. Intake and account endpoints enforce same-origin requests, payload and field limits, secret-pattern rejection where applicable, bot checks, keyed abuse fingerprints, and short-window throttling. Raw network addresses are not stored in the abuse ledger.

Human identity and organization access

Zinvyl uses passwordless email verification followed by a random opaque session held in a Secure, HttpOnly, SameSite cookie. Only a keyed digest of the session token is stored; sessions are time-limited and revocable. Business resources are authorized through active organization memberships and explicit roles rather than an email string alone. Authenticator-app multi-factor verification raises the assurance of a session before credential issuance or other privileged changes. Email verification is not represented as phishing-resistant authentication. Stripe Identity hosts the government-ID check used to verify a profile before provider payout setup. Zinvyl stores the verification status and a keyed duplicate-profile token, not identity-document images or raw document numbers. A possible duplicate is held for human review rather than automatically merged or approved.

Payment boundary

Stripe hosts card collection. Zinvyl does not store full payment-card numbers or card security codes. An owner or administrator may enroll an organization payment method through Stripe-hosted setup without using Link; Zinvyl retains only opaque Stripe references and consent evidence. Enrollment is separate from purchase authority. A delegated charge additionally requires the same authenticated agent, organization, exact offer, unexpired single-transaction mandate, quote, currency, and tax-inclusive ceiling. The intent identifier is the Stripe idempotency boundary. Signed Stripe webhooks, live/test separation, stale-event protection, and duplicate-event handling protect the order ledger. Issuer-required authentication remains a safe stop, and a setup redirect, payment attempt, agent statement, invoice, or purchase intent can never mark an order paid.

Agent boundary

The public MCP server separates stateless discovery tools from a governed purchase tool. Discovery can list offers, qualify sanitized summaries, return acceptance tests, and explain purchase requirements without creating an order. An authorized buyer agent may create one capped, expiring unpaid purchase intent for an exact offer and price; that intent cannot mark an order paid or start fulfillment. Managed or repeat buyers may use an organization-bound Zinvyl credential with explicit scopes, offer allowlist, currency, and per-purchase maximum; only a keyed digest is retained after the credential is shown once. With an organization payment method separately enrolled by an owner or administrator, that persisted credential is the standing policy for delegated-card purchases and no per-purchase owner click is added; an optional signed one-time mandate can narrow a specific transaction. Without standing settlement consent, the agent receives hosted Checkout or may explicitly choose a compatible Stripe MPP wallet. Human approval is reserved for missing or insufficient purchasing authority. Only a verified Stripe receipt or signed live webhook may create paid state. Revocation blocks future charge submissions but does not erase a charge Stripe already accepted under authority that was valid at submission. The buyer work-request API rejects anonymous posts: a human request is bound to a verified session and active buyer-workspace or organization role, while a machine request is bound to an authenticated organization agent, recorded USD ceiling, and replay-resistant idempotency key. The provider API uses a separate one-time scoped credential and returns only funded, unexpired opportunities expressly available to that provider. No agent interface can increase its own authority, obtain a human session, accept expired scope, or release a provider payout.

Data minimization

Public intake accepts business contact and sanitized workflow descriptions only. Confidential files and credentials are prohibited. A secure transfer method and least-privilege access are agreed only after scope confirmation. Access should be time-limited and removed after delivery.

Secure order files

File upload is available only for a matched live paid order that has been claimed by the verified payer account for an organization where the current user retains active membership. The order URL and payer email alone do not authorize access. Zinvyl limits file count, size, extension, declared media type, and binary signature; stores bytes outside the public database; records a SHA-256 digest; and serves downloads as attachments with no-sniff and sandbox controls. Buyer files remain unreviewed until an authorized operator records review. These controls reduce risk but are not malware certification, so customers must still submit only sanitized, necessary materials.

Private sales records

Structured prospect and customer relationships are stored in private Supabase tables with Row Level Security enabled and browser-role privileges revoked. The service-role credential is restricted to the server-side Worker and is never delivered to client code. Cloudflare R2 object keys use opaque identifiers rather than customer names or email addresses. Google Calendar receives only generic owner-action titles and deadlines when that integration is configured. A public listing or agent request does not by itself authorize outreach, purchasing, payment, or customer status.

Operator access

The operations console is unlisted, excluded from indexing, and requires the configured authenticated Zinvyl owner identity. It cannot create a paid state or bypass Stripe reconciliation. Administrative accounts for hosting, payments, email, source control, and banking should use unique credentials, multi-factor authentication, least privilege, and protected recovery codes.

Report a vulnerability

Do not include exploit code, credentials, customer data, or sensitive vulnerability details in public intake. Use the Zinvyl contact form, identify the matter as a security report, and request a secure reporting channel. Include the affected URL, observed behavior, date, and a safe reproduction outline. Zinvyl will acknowledge the report and coordinate validation and remediation.

Testing authorization

This page does not authorize scanning, denial-of-service testing, social engineering, data access, persistence, destructive actions, or testing of Stripe, Cloudflare, OpenAI, or other third-party systems. Written authorization and an explicit scope are required before active testing.

Incident response

Zinvyl will contain suspected incidents, preserve relevant evidence, assess affected data and providers, correct confirmed weaknesses, and make legally required notifications. Security controls and this statement will evolve as the service and observed risks change.

Contact