Suggest improvements
Help us get better.
InstaLaw is a transparency-first project. We believe the best way to build secure software is to be honest about how it is built, what we are doing well, and where we know we can improve. This page describes our current infrastructure, the controls we have in place, and areas where we are actively seeking input from the security community.
InstaLaw is vibe coded — the majority of the codebase has been written with AI-assisted development tools. We are a solo-founder project that leverages large language models heavily in the development process, from architecture decisions to implementation.
We share this openly because we think it matters for security context. AI-assisted codebases can move fast, but they can also introduce subtle bugs or patterns that a human developer might catch differently. We depend on automated tooling, careful review, and — critically — independent eyes from security researchers like you to keep the product safe.
If you spot patterns in our code that suggest an AI-generated vulnerability class (hallucinated auth checks, insecure defaults, phantom validation, etc.), we are especially interested in those findings.
All InstaLaw applications are deployed on Vercel. We use Vercel's Fluid Compute for serverless functions, edge middleware, preview deployments, and production infrastructure. Vercel handles TLS termination, DDoS mitigation, and CDN distribution.
All AI inference is routed through Vercel's AI Gateway, which provides a unified API layer to multiple foundational model providers. This gives us provider-level redundancy, observability, model fallback capabilities, and zero data retention on the gateway layer. We currently use models from Anthropic, OpenAI, and Google through the gateway.
Our primary database is Neon — a serverless Postgres provider. Neon provides connection pooling, branching for preview environments, point-in-time recovery, and encryption at rest. All database connections use TLS.
All users with access to our Vercel account are required to have two-factor authentication enabled, including authenticator app (TOTP). No exceptions — access is revoked immediately if 2FA is disabled.
Email accounts and development machines are secured with physical hardware security keys (YubiKey). This provides phishing-resistant authentication that cannot be intercepted by remote attackers, credential-stealing malware, or SIM-swap attacks.
- Email accounts protected by YubiKey (WebAuthn/FIDO2)
- Development machines require physical key for login
- Backup keys stored securely in a separate physical location
- Strict Content Security Policy and security headers across all apps
- PII redaction before storage — anonymization by default
- Workspace isolation — no cross-tenant data access
- Rate limiting on all public API endpoints
- Zod-based input validation on all API route handlers
- AI Gateway zero data retention — inference requests are not stored
These are areas where we know we could improve and would especially value input from security researchers. If you have recommendations — even if they are not tied to a specific vulnerability — we want to hear them.
AI-specific attack surface
Prompt injection, jailbreaking, data exfiltration through AI responses, model confusion attacks. Our anonymization pipeline is a critical control — we want it stress-tested.
Authentication and session management
We use third-party auth providers. Are there gaps in our session handling, token rotation, or RBAC enforcement that we are missing?
Supply chain security
As a vibe-coded project, we have a large dependency tree. Recommendations for dependency auditing, lockfile integrity, or build pipeline hardening are welcome.
Infrastructure configuration
Vercel, Neon, and AI Gateway are managed services, but misconfigurations happen. If you spot overly permissive headers, exposed debug endpoints, or misconfigured CORS policies, let us know.
Privacy and anonymization
Our core promise is user anonymity. If you can find ways to de-anonymize users, correlate activity across sessions, or bypass PII redaction, that is a critical finding for us.
Monitoring and incident detection
Recommendations for better logging, alerting, anomaly detection, or audit trails that we should implement.
How to submit suggestions
Security improvement suggestions do not need to follow the full vulnerability reporting process. Email security@instalaw.io with the subject line "Security Improvement Suggestion" and describe the recommendation, why you think it matters, and any references or examples. You can also use our report form and select "Informational" severity.
We read every suggestion. If your recommendation leads to a meaningful improvement, we will credit you on our Hall of Fame.