Security Policy

1. Approach

VERA can post, send, and spend on your behalf, so the most important security property is not cryptographic: it is that VERA does not act without you. External actions are recorded as proposals and executed only after you approve them, or under an automation rule you configured yourself. The approval gate is enforced in the code path that executes actions, not merely stated in policy.

The second principle is that credentials are the crown jewels. VERA holds tokens for platforms that can move money, publish to an audience, and read a business's accounts. Those are encrypted with a key that is separate from everything else and are never displayed back to the interface or written to logs.

2. What is in place

Each of the following is implemented in the product today.

• Encryption in transit. All traffic is served over HTTPS. In production, plain HTTP requests are permanently redirected to HTTPS at the edge, and HTTP Strict Transport Security is asserted with a two-year max-age, includeSubDomains, and preload.
• Encryption of secrets at rest. Connector credentials and API keys are encrypted with AES-256-GCM, an authenticated cipher, so a tampered ciphertext fails to decrypt rather than yielding altered data. The key is a dedicated value that production startup validation requires to be present, distinct, and of sufficient length.
• Password security. Passwords are hashed with bcrypt at a work factor of 12 and are never stored or logged in a readable form. A minimum length is enforced. Email verification is required before a password account can sign in.
• Session management. Sessions are signed JSON Web Tokens carrying a revocation counter that is checked against the database on every authenticated request. Incrementing that counter invalidates every issued session at once, which is what makes password reset, "sign out of all devices", and account suspension actually evict live sessions rather than just prevent new ones.
• Password reset and verification. Reset links are single-use, expire after 1 hour, are rate-limited by a send cooldown, and revoke all sessions when used. Verification links expire after 24 hours. The reset request never reveals whether an account exists.
• Rate limiting. Sign-in, sign-up, password reset, and AI actions are rate limited using durable fixed-window counters held in the database, so limits survive process restarts and apply across instances rather than only within one.
• Tenant isolation. Every query is scoped to the authenticated account. A failed ownership check is itself recorded as a security event.
• Administrative access control. The internal operations console is restricted to an explicit operator allowlist configured in the environment. Every operator action is written to an append-only administrative audit log recording who did what to which account.
• Audit trail. Every proposal, approval, edit, decline, execution, and failure is recorded in an append-only per-account audit log, alongside security events such as password changes, session revocations, suspensions, and estimate link rotations. Secrets, tokens, and password hashes are excluded by design.
• HTTP security headers. A Content Security Policy restricting scripts, styles, frames, and form targets; X-Frame-Options DENY and frame-ancestors none against clickjacking; X-Content-Type-Options nosniff; a strict-origin-when-cross-origin referrer policy; and a Permissions-Policy disabling camera, microphone, and geolocation.
• Webhook integrity. Inbound webhooks are verified against each provider's signing scheme before processing, including Stripe signatures, Meta's HMAC header, Jobber's HMAC, Square's signature key, and QuickBooks' dedicated verifier token. Deliveries are deduplicated by event id so a replay cannot apply an effect twice.
• Server-side request forgery protection. Where the product fetches a URL you supply, such as a store domain or a website to analyze, the address is validated by scheme, port, and by resolving every IP it points to, rejecting loopback, private, link-local, carrier-grade NAT, and cloud metadata ranges. Redirects are handled so a public host cannot bounce a request into an internal one.
• Public link security. Customer-facing estimate links use 256 bits of cryptographically secure randomness. Owners can regenerate a link, which immediately invalidates the old one and records a non-reversible fingerprint of it for audit. Failed token lookups are throttled so the endpoint cannot be ground through, and tokens are masked wherever they would otherwise appear in logs or admin views.
• Least-privilege integration scopes. Integrations request only the scopes their features need, and several are read-only by design, including QuickBooks Online and Jobber. Billing analytics use a separate restricted read-only payment provider key so an analytics view can never mutate billing state.
• Payment data isolation. Card numbers never reach VERA. Payment is collected on Stripe's hosted checkout and managed through Stripe's billing portal, so VERA's systems are not in the cardholder data path.
• Secure configuration by default. Startup validation refuses to run in production with the development session secret, without a session secret, or without a dedicated secrets encryption key, and warns on half-configured integrations that would fail silently.
• Account suspension. A compromised or abusive account can be suspended, which refuses every authenticated entry point and revokes live sessions, without deleting data and without being irreversible.

3. What is not in place yet

These are controls a security reviewer would reasonably ask about. VERA does not have them today. We list them rather than leaving a reader to infer their presence from the section above.

• No certifications. VERA has not completed a SOC 2 Type I or Type II audit, is not ISO 27001 certified, has no HIPAA business associate program, and is not PCI DSS assessed in its own right. Payment card handling is delegated entirely to Stripe.
• No multi-factor authentication. VERA does not currently offer two-factor authentication, authenticator apps, hardware keys, or passkeys. Signing in with Google inherits whatever multi-factor protection you have on your Google account, which is currently the strongest available option.
• No single sign-on. There is no SAML or OIDC enterprise SSO, and no SCIM provisioning.
• No team accounts or role enforcement. VERA is one business per account today. A role and permission matrix exists in the codebase as a reference model, but per-user roles are not enforced across the product. Anyone with your credentials has your full access.
• No independent penetration test or bug bounty. VERA has not commissioned a third-party penetration test and does not operate a paid bug bounty program.
• No customer-managed encryption keys. Encryption keys are managed by VERA. Bring-your-own-key is not available.
• No data residency choice. Data is processed in the United States. There is no EU or regional hosting option.
• No independent backup program. VERA does not run its own backup tooling. Durability depends on the managed database provider's capabilities.
• No 24/7 security operations. There is no round-the-clock staffed security operations center, no formal on-call rotation published to customers, and no intrusion detection product beyond the application-level controls listed above.
• No uptime commitment. VERA does not offer a service level agreement. See the Terms of Service.

4. Infrastructure

VERA runs as a containerized Next.js application on Node.js, deployed from a multi-stage build that produces a self-contained runtime image, against a managed PostgreSQL database. A health endpoint is exposed for platform monitoring.

Uploaded photographs, generated images, and imported documents are stored as encoded data in the application database rather than in a separate object storage service. This means there is no separately configured bucket to leave publicly readable, and it also means file storage inherits whatever encryption at rest the database provider applies.

Hosting, network-level protection, and physical security are provided by the platform providers named on the Subprocessor List, under their own security programs. VERA does not operate its own data centers.

5. Monitoring and incident response

Application and error logging runs in production, and the internal operations console surfaces system health, background job status, integration failures, and a security panel that reports items such as the backlog of estimate links still on a legacy token format.

If we become aware of a security incident affecting customer data, we investigate, contain it, and assess what data was involved. For personal data processed on a business customer's behalf, VERA notifies the affected customer without undue delay and within 72 hours of becoming aware, as required by the Data Processing Addendum. Notifications to regulators and to individuals are the controller's responsibility, and we assist.

VERA does not currently publish a status page or a public incident history.

6. Reporting a vulnerability

Report security issues to support@myvera.io with the subject line "Security report". Include enough detail to reproduce the issue: the affected URL or feature, the steps, and the impact you believe it has. Encrypted correspondence is welcome; ask and we will arrange it.

We aim to acknowledge a report within 3 business days and to give an assessment within 10 business days. We will keep you updated while we work on a fix and will tell you when it ships. We are happy to credit you publicly if you would like that.

7. Responsible disclosure and safe harbor

If you research VERA's security in good faith and within the boundaries below, we will not pursue legal action against you and will treat your research as authorized under applicable computer misuse law. We ask you to:

• Test only your own account. Use an account you created. Do not access, modify, or retain another customer's data. If you inadvertently encounter someone else's data, stop, do not save it, and tell us what happened.
• Avoid harm. No denial of service, no load or stress testing, no spam, no social engineering of our staff or customers, and no physical attacks.
• Do not use automated scanners at volume. Aggressive automated scanning is indistinguishable from an attack and will get you rate limited or blocked.
• Give us time. Report privately and give us a reasonable window to fix the issue before disclosing it. 90 days is our default expectation; we are usually much faster and will tell you if something needs longer.
• Do not extort. Withholding details pending payment is not a security report. VERA does not operate a paid bounty program and cannot offer a reward.

8. Your part

Use a strong, unique password, and prefer Google sign-in if your Google account has multi-factor authentication enabled, since VERA does not yet offer its own.

Do not share your credentials. VERA has no team accounts, so sharing a login gives away full account access, including billing and every connected platform.

Grant integrations only where you need the feature, and disconnect the ones you stop using. Regenerate an estimate link if it has been forwarded somewhere you did not intend. Review your audit trail if something looks wrong, and tell us at support@myvera.io if you suspect unauthorized access.