Security
How we protect the operators and data entrusted to Bridging Main.
This page describes how Bridging Main approaches security, what controls are in place today, and how to reach us with a security concern. It is intended as an honest overview rather than an exhaustive technical reference. A more detailed Security Posture document is available on request—see “Security Posture document” below.
Publishing this page is part of how we operate. Bridging Main’s posture is ethics-first: clear, accurate disclosure is preferred over discretion. Operators who entrust us with sensitive operational information deserve to see how we handle it, and prospective clients who evaluate us deserve to see the same.
Our security philosophy
Defense in depth. No single control is allowed to be the only thing between an attacker and a successful outcome. Meaningful assets have at least two independent defenses; high-value assets have more.
Least privilege. Accounts, services, and database roles have only the access their function requires. Defaults toward broader permission are rejected.
Privacy-preserving by default. We collect operator data only when necessary, retain it only as long as necessary, and disclose what we collect in our Privacy Policy before collection. The retention schedules that govern each category of data are stated there.
Document the decision. Security choices—what to defend against, what to defer, what to accept as residual risk—are recorded internally with a date and rationale. This page reflects current state, not future state.
Data in transit
All traffic to Bridging Main is encrypted with modern Transport Layer Security (TLS). We support TLS 1.2 as a minimum and prefer TLS 1.3; older protocols are disabled. HTTP Strict Transport Security (HSTS) is enabled with a two-year maximum age and includes our subdomains, so browsers refuse insecure connections to our site once they have seen a secure one.
Modern HTTP security headers are set on every response: protections against MIME-type sniffing, clickjacking, referrer leakage, and unauthorized use of browser capabilities such as camera, microphone, geolocation, and payment APIs. A Content Security Policy is configured and will be enforced after a monitoring window confirms clean operation.
Data at rest
Operator data is stored in a managed PostgreSQL database that encrypts data on disk by default. The database is reachable only from our application server over a private network, and the application connects with full TLS verification against our database provider’s certificate authority.
Every database query in our application uses parameterized statements. String concatenation into SQL is forbidden as a standing rule, and code changes are reviewed against this rule. Parameterized statements are the canonical defense against SQL injection, and they are applied without exception.
Daily automated database backups are taken by our managed database provider and retained per the provider’s default schedule. Code and configuration are versioned, and the previous deployed version of any change is preserved on the server for rollback.
Account security
Multi-factor authentication is enabled on every active account with access to operator data, production infrastructure, the AI provider, the email provider, or the domain registrar. Strong unique passwords are stored in a password manager; recovery codes are stored separately. Public addresses—for example, hello@bridgingmain.com—are never used as recovery contacts for sensitive accounts.
The domain registrar account is locked against unauthorized transfer. The domain itself is the highest-value account in our threat model—loss of it would compromise everything connected to it—so it carries the strongest controls available at the registrar level.
Database roles are scoped to the minimum access their function requires. The application user holds only the rights it needs to read and write its own data; schema modifications use a separate role and never run from web requests.
AI features
Some pages on our site offer AI-powered interactive tools. When you use one, the input you provide—assessment responses, free-text context, and any other content you enter—is sent to Anthropic for processing, and the response is returned to you. We use Anthropic’s commercial API under terms that prohibit Anthropic from training on customer API data and that retain inputs and outputs for up to seven days before deletion. The full data flow, retention schedule, and your rights as a user of these tools are described in our Privacy Policy.
AI features include defenses appropriate to their public exposure: structured input validation, content sanitization for free-text fields, prompt-side safeguards against instruction-following from operator-supplied content, and per-feature rate and budget limits. These defenses evolve as the threat landscape evolves; the underlying philosophy of layering them does not.
Subprocessors
The third parties we rely on to operate Bridging Main are listed below with their roles. Our Privacy Policy includes links to each provider’s own privacy practices.
- Anthropic—provides the AI models used to generate AI feature output.
- DigitalOcean—hosts the website and the managed PostgreSQL database that holds operator data.
- Formspree—processes form submissions (discovery requests, signups, calculator results).
- Google Analytics 4 / Google Tag Manager—website analytics and tag management.
- Let’s Encrypt—issues the TLS certificate that secures connections to our site.
If we add a new subprocessor that processes operator data, we update both this page and the Privacy Policy.
Incident response
We maintain a written incident response process. When we become aware of a security incident affecting operator data, the process directs us to contain the incident, preserve evidence, assess scope, eradicate the underlying cause, recover affected systems, and notify affected parties. For incidents involving personal data, our target for breach notification follows the GDPR baseline of 72 hours. We commit to honest, factual communication during incidents over minimization or delay, and to a written postmortem for any material incident.
Responsible disclosure
If you believe you have found a security issue affecting Bridging Main, please report it to security@bridgingmain.com. We will acknowledge your report within five business days.
Bridging Main will not pursue legal action against security researchers who act in good faith—who avoid privacy violations and service degradation, who access only the data necessary to demonstrate the issue, and who give us a reasonable opportunity to respond before public disclosure. We appreciate reports that include enough detail to reproduce the issue.
Security Posture document
A more detailed Security Posture document covering our architecture, controls, and policies in greater depth is in preparation. Enterprise prospects, insurance underwriters, and security teams who need a fuller view before engaging may request early access by emailing security@bridgingmain.com.
Privacy
For information about what data we collect, why, how long we retain it, and how to exercise your data rights, see our Privacy Policy. Privacy and security are reviewed together when either changes.
Contact
For security reports: security@bridgingmain.com
For privacy and data rights: privacy@bridgingmain.com
For everything else:
Main St Holding I LLC dba Bridging Main
1081 Camino del Rio S, Ste 105
San Diego, CA 92108
hello@bridgingmain.com