vibedasher

Security

Last Updated: August 19, 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 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 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.
  • Talk to us at 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 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

To be precise about it: our hosted CI does not currently run the test suite on every push — the gate is enforced before push instead.

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. Our metrics-dashboard and on-call stack is built but currently switched off for cost reasons, so alerting today is manual review rather than an automated page. If that matters to your risk assessment, it should — and you should ask us where it stands before you rely on it.

Logging:

  • Log retention is currently 7 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 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 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 to discuss your environment.

Note that a self-hosted deployment still requires an API key for a hosted AI provider to power the AI features — we do not ship a bundled local model.

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
  • PostHog: product analytics, including session replay on the application

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
  • 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:

If you need to send us something encrypted, email security@vibedasher.com first and we'll arrange a channel.

Last Review: August 19, 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.