Security and responsible reporting

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

Effective September 20, 2026

Current controls

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

Payment boundary

Stripe hosts card collection. Zinvyl does not store full payment-card numbers. Signed Stripe webhooks, live/test separation, exact offer and amount matching, required terms consent, Zinvyl-issued purchase references, stale-event protection, and duplicate-event handling protect the order ledger. A browser redirect, agent statement, invoice, or purchase intent can never mark an order paid.

Agent boundary

The public MCP server is read-only and stateless. It can list offers, qualify sanitized summaries, return acceptance tests, and prepare an external funding route. The separate work-request API can record an unfunded request for operator review only; agent submissions require an HTTPS identity endpoint, delegated budget limit, and replay-resistant idempotency key. Neither interface can access customer systems, verify payment, change an order, or begin work.

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 and payer email. 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.

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.