# Security > Where data lives, how access is decided, what is encrypted, and what a self-hosted deployment changes. Source: https://vibedasher.com/security # Security **Last Updated:** September 30, 2026 You're trusting us with your data, so this page tries to be genuinely useful rather than reassuring. It describes what we actually run today — and, just as explicitly, what we don't. Where a control isn't in place, you'll find it said plainly instead of dressed up. We're a small team building in the open. If a control you need is missing, email [security@vibedasher.com](mailto:security@vibedasher.com) and ask; we'll give you a straight answer. ## Security Overview ### Our Commitment - **Security First**: Security is a core principle in all design and development decisions - **Transparency**: We're open about our security practices — including the parts we haven't built yet. Where this page says we don't do something, that's deliberate; we'd rather you know. - **Continuous Improvement**: We keep tightening this as we grow ### Certifications and Compliance We hold no third-party security certifications of our own today. We'd rather say that plainly than imply otherwise. - **ISO 27001** (planned for 2026): Information security management certification - **SOC 2 Type II** (planned): we have not yet completed a SOC 2 audit, and we will not claim the certification until a report exists - **GDPR**: we build to the EU data protection regime — data export, deletion, portability, and the breach-notification duty described below - **CCPA**: we build to the California Consumer Privacy Act's access and deletion rights If your procurement process requires a completed audit report today, contact us at [security@vibedasher.com](mailto:security@vibedasher.com) and we'll tell you exactly where we stand rather than send you a certificate we don't have. ## Infrastructure Security ### Cloud Architecture **Multi-Region Deployment:** - We run in AWS `us-east-1` (North America) and `eu-central-1` (Europe). We do not currently operate an Asia-Pacific region. - **The split between them is not something you choose, and there is no region selector in the product.** Identity and account records — email address, credentials, account membership — are held in `us-east-1` (United States) for **every** account, wherever you are. Dashboards, datasets and query results are processed and stored in `eu-central-1` (Frankfurt), the only data-plane region running today. - So an EU customer's personal identity data does leave the EU, by design, on every sign-in. If that is a blocker, it should be, and you should know it before you upload anything rather than after. - Talk to us at [support@vibedasher.com](mailto:support@vibedasher.com) if you have a data-residency requirement — we'll tell you what we can serve today. **Infrastructure Providers:** - **Primary**: AWS (Amazon Web Services) - AWS maintains extensive security certifications of its own (SOC 2, ISO 27001, FedRAMP, etc.). **Those are AWS's certifications for the infrastructure we rent — they are not Vibedasher certifications and do not transfer to us.** ### Network Security **Perimeter Protection:** - All public traffic terminates at AWS API Gateway and CloudFront, which absorb the network-layer DDoS protection AWS provides by default - Authenticated request authorization at the edge We do **not** currently run a Web Application Firewall (WAF) or an intrusion detection/prevention system (IDS/IPS). Those are on the roadmap, not in production. **Network Segmentation:** - Untrusted, user-generated code runs in an isolated VPC with **no internet route at all** — no internet gateway, no NAT, egress only to AWS storage endpoints - Most compute runs as AWS Lambda functions with narrowly scoped IAM roles rather than long-lived servers - Our SQL worker instances do have outbound internet access, because they need to reach the customer databases you connect ### Server Security We run serverless (AWS Lambda) rather than managing our own fleet, so most host-level hardening is AWS's responsibility under the shared-responsibility model. We do not operate Kubernetes. **What we own:** - Minimal dependency surface in every deployed function - Least-privilege IAM per function - Dependency updates as part of normal development ## Data Security ### Encryption **Data in Transit:** - HTTPS everywhere. TLS 1.2 is the enforced minimum on our CDN and API edge; TLS 1.3 is supported and negotiated by default with modern clients - Modern cipher suites with Perfect Forward Secrecy, per the AWS TLS security policies we pin - HTTP Strict Transport Security (HSTS) with a one-year max-age, `includeSubDomains`, and preload on our marketing site. The application itself does not yet send HSTS — that's a gap we're closing. **Data at Rest:** - AES-256 server-side encryption on our primary object-storage bucket, explicitly configured - DynamoDB tables are encrypted at rest by AWS default. Not every table has encryption *explicitly* pinned in our infrastructure code, and we're tightening that. **Key Management:** - Encryption keys are AWS-managed. We do not currently operate customer-managed KMS keys, per-customer key separation, or a Hardware Security Module — data is separated by account at the application layer, not by distinct encryption keys. - Application secrets live in AWS SSM Parameter Store. No keys or credentials are stored in application code or version control. - Our ES256 JWT signing keys **are** rotated automatically, on a 30-day lifetime with a 7-day grace period. ### Database Security **Access Controls:** - Principle of least privilege - Service-specific database users - We run no self-managed database servers — our primary datastore is AWS-managed DynamoDB, reachable only via authenticated AWS APIs, never over the public internet **Database Hardening:** - Encrypted connections required - Strong authentication (no default passwords) - Encrypted backups **Query Security:** - Parameterized queries to prevent SQL injection - Input validation and sanitization - Query timeouts to prevent resource exhaustion We do not currently force connections to *your* databases to be read-only at the driver level. When you connect a data source, grant Vibedasher a read-only database user — that's the boundary we recommend, and it's yours to set. ### Backup and Recovery **Backup Strategy:** - Point-in-time recovery is enabled on our primary DynamoDB tables, giving a rolling 35-day restore window - We do **not** run a separate scheduled backup job, and object-storage versioning is off. PITR on our main tables is the recovery mechanism — that's the whole of it. **Disaster Recovery:** We have not published a Recovery Point Objective or Recovery Time Objective, and we do not currently run scheduled disaster-recovery drills. Stating a number we haven't tested would be worse than saying so. If a contractual RPO/RTO matters to you, contact [security@vibedasher.com](mailto:security@vibedasher.com) and we'll have the real conversation. ## Application Security ### Secure Development Lifecycle **Code Security:** - Every change is code-reviewed before it ships - A test, lint and contract-freshness gate runs locally and on a pre-push hook before code reaches production - Container images are scanned on push - Secrets are kept out of the repository and injected from AWS SSM Parameter Store at runtime We do **not** currently run dedicated SAST, DAST, or Software Composition Analysis tooling. Those are roadmap items. **Development Practices:** - Secure coding guidelines and an architecture-invariants document the team works against - Least-privilege IAM for every deployed component Vibedasher is a small team; we do not run a formal security training program, a security champions program, or a standing threat-modeling process. ### Authentication and Authorization **Authentication:** - Passwords must be at least 8 characters, with mixed case, a digit and a symbol - OAuth 2.0 sign-in with **Google and LinkedIn** - Signed session tokens (ES256, verified against a rotating JWKS) with expiry Multi-factor authentication and SAML 2.0 single sign-on are **not available yet**. If SSO is a blocker for your organisation, tell us — it moves up the roadmap when customers ask. **Authorization:** - Role-Based Access Control, with groups and per-object access rights - Granular permissions (view, edit, create, delete, share) - Account and workspace isolation enforced server-side on every request ### API Security **API Protection:** - API key authentication, with 256-bit tokens, expiry, and revocation - Short-lived JWTs (ES256, ~15 minute expiry) verified against a rotating JWKS - Service-wide request throttling at the API edge - API versioning for backward compatibility **Per-key** rate limiting and IP allow-listing are not available today — the throttle above is service-wide, not per customer. Embed keys carry a domain allow-list, which is **empty (allow-all) by default** — set it if you use embeds. **Input Validation:** - Pydantic schema validation and strict typing on every request body - Parameterized queries throughout - Size limits to prevent resource exhaustion - `Content-Security-Policy: frame-ancestors` on embed responses to control which origins may frame a dashboard ### AI Security **Prompt Injection Protection:** - Input sanitization for AI prompts - Context length limits, with automatic compaction of long conversations - Generated code and SQL are validated before they run — unknown columns, invalid references, and code that doesn't compile are rejected rather than executed - Destructive tools are allow-listed server-side, so the model cannot reach beyond the objects a chat is scoped to **AI Provider Security:** - Encrypted connections to AI providers - **We route AI requests through OpenRouter**, which forwards them to the underlying model provider (Anthropic, Google, Mistral, DeepSeek, Meta, xAI, Qwen, Moonshot and others, depending on the model you pick). OpenRouter is a sub-processor for every prompt you send. - We do not train any model on your data. Whether the *underlying* provider retains or trains on API traffic is governed by their terms and OpenRouter's routing policy, not ours — we do not currently set a no-retention flag on these requests. If zero-retention is a requirement for you, tell us before you send us sensitive data. - Data minimization (only send necessary context) ## Monitoring and Incident Response ### Security Monitoring **Monitoring:** - Structured application logging in AWS CloudWatch across every service - Error telemetry we review as part of normal operations We do not run a SIEM, a staffed 24/7 security operations centre, or automated paging. Alerting today is manual review. If continuous monitoring is a requirement for you, ask us where it stands before you rely on it. **Logging:** - Log retention is currently **3 to 30 days** depending on the service. We do not offer a long-lived, customer-visible audit trail yet, and permission changes are not separately audit-logged. If you need a longer retention window for compliance, tell us what you need. ### Vulnerability Management - Container images are scanned for known vulnerabilities on every push - We monitor our dependencies and apply security updates as part of normal development We do **not** currently run scheduled automated vulnerability scans, and we have **not** commissioned a third-party penetration test. We have no formal bug bounty program — but see Responsible Disclosure below; we do want your reports and will treat them seriously. **Patch Management:** - We aim to ship critical security fixes quickly, and our deploy path is fast enough to do so. We do not offer a contractual patch-time SLA. - Rollback procedures for failed deploys ### Incident Response Vibedasher is a small team. We do not staff a 24/7 on-call security rota, and we won't pretend otherwise. What we do commit to: - We triage security reports sent to [security@vibedasher.com](mailto:security@vibedasher.com) promptly - We classify incidents by severity and communicate with affected customers - We publish a post-incident summary for anything that affected customer data **Breach Notification:** - We will notify affected users of a confirmed breach without undue delay, and within 72 hours where GDPR requires it. This is a commitment we intend to honour, not a record of past incidents. - Transparent communication about incidents - Post-incident analysis and improvements - Cooperation with law enforcement if necessary ## Compliance and Privacy ### Data Privacy **Privacy by Design:** - Data minimization (collect only what's needed) - Purpose limitation (use data only for stated purposes) - Storage limitation (delete data when no longer needed) - Accuracy (ensure data is correct and up-to-date) **Privacy Controls:** - Account and data deletion is available in the product today - Self-serve data export and portability is **not built yet**. Email [support@vibedasher.com](mailto:support@vibedasher.com) and we will export your data for you — the right is real even though the button isn't there yet. ### Compliance Frameworks **Regulations we build toward:** - GDPR (General Data Protection Regulation) - CCPA (California Consumer Privacy Act) These are the regimes our data-handling design targets. We have not been independently audited against any of them. **Industry Standards:** - We write against the OWASP Top 10 — parameterized queries, output sanitisation, authorization checked server-side on every request - Payment card data never touches our systems: card handling is fully delegated to Stripe, which is PCI DSS certified We have not formally implemented the CIS Controls or completed a NIST Cybersecurity Framework assessment. ## On-Premise Security For customers using our on-premise or self-hosted deployment: > Self-hosting runs from a source checkout with a Docker Compose stack and an install script — there are **no published container images** and no air-gapped distribution, so it is an **Enterprise engagement scoped with us**, not a self-serve download. The installer pulls base images from public registries and needs network access. Contact [support@vibedasher.com](mailto:support@vibedasher.com) to discuss your environment. > > Note that a self-hosted deployment still needs an AI model endpoint that **you** supply — either an API key for a hosted provider, or your own OpenAI-compatible endpoint, since a custom base URL is supported. We do not ship a bundled local model, so the AI features do not work until you point them somewhere. ### Installation Security **Deployment:** - Containerised deployment into infrastructure you control - VPN or private network deployment - Secure default configuration, with TLS and database encryption set up as part of the engagement ### Your Responsibilities When self-hosting, you are responsible for: - **Infrastructure Security**: Server hardening, network configuration, physical security - **Access Management**: User authentication and authorization - **Backups**: Regular backups and disaster recovery - **Updates**: Applying security patches and updates - **Monitoring**: Security event monitoring and incident response ### Our Support We provide: - Security best practices documentation - Configuration review and recommendations - Security advisory notifications - Assistance with security incident investigation (optional) ## Team and Physical Security Vibedasher is a small team, so we'll be concrete instead of describing a corporate security program we don't run. **Access Controls:** - Access to production systems is limited to the people who need it, on least-privilege IAM roles - MFA on the accounts that hold production access - Access is revoked when someone stops needing it - Confidentiality agreements with anyone who has data access We do not run mandatory security awareness training, phishing simulations, or background checks, and we have no badge-controlled office to describe. **Data Centre Security:** - Entirely outsourced to AWS. Physical security, biometric access control, and environmental controls (fire, flood, temperature) are AWS's responsibility and are covered by AWS's own certifications — not ours. ## Third-Party Security ### Vendor Management We keep the vendor list short on purpose, and we review each one's security posture and certifications before it touches customer data. We do not run a formal recurring vendor-audit program. **Key Vendors:** - **AWS**: Infrastructure hosting - **Stripe**: Payment processing (PCI DSS certified) - **OpenRouter**: routes every AI request to the underlying model provider - **Resend**: transactional email, and the email the product sends on your behalf — alert notifications and dashboard subscriptions, which carry rendered dashboard content in the body and as an attachment - **PostHog**: product analytics, including session replay on the application. There is no consent banner today; our [Privacy Policy](https://vibedasher.com/privacy) says what that means and how to be excluded ## Responsible Disclosure We welcome responsible disclosure of security vulnerabilities. We do **not** run a formal bug bounty program with a published payout table — but we read every report and we'd rather hear from you than not. - **Email**: [security@vibedasher.com](mailto:security@vibedasher.com) - **Response**: we aim to acknowledge within one business day - **Rewards**: discretionary, case by case - **Credit**: happy to name you publicly, with your permission ### Disclosure Guidelines Please: - Give us reasonable time to fix vulnerabilities before public disclosure - Provide detailed reproduction steps - Avoid accessing, modifying, or deleting customer data - Don't perform DoS attacks or resource exhaustion tests ## Security Roadmap Everything in this section is **planned, not shipped**. It's here so you can see the direction, not so you can plan against it. - ISO 27001 certification (targeted for 2026) - SOC 2 Type II audit - Web Application Firewall and automated vulnerability scanning - Multi-factor authentication, then SAML 2.0 single sign-on for Enterprise - Longer, configurable audit-log retention, and audit logging of permission changes - Self-serve data export and portability - HSTS and a Content Security Policy on the application itself - A first third-party penetration test ## Contact Us For security-related inquiries: - **Security Team**: [security@vibedasher.com](mailto:security@vibedasher.com) - **Vulnerability Reports**: [security@vibedasher.com](mailto:security@vibedasher.com) - **Data Protection Officer**: [dpo@vibedasher.com](mailto:dpo@vibedasher.com) - **General Support**: [support@vibedasher.com](mailto:support@vibedasher.com) If you need to send us something encrypted, email [security@vibedasher.com](mailto:security@vibedasher.com) first and we'll arrange a channel. * * * **Last Review:** September 30, 2026 We update this page as our practices change — including when something moves off the roadmap and into production. If anything here is unclear, or you need a control we don't yet have, please ask.