Security & Audit

1. Overview

BIDS handles data that matters — your business profile, your UEI and CAGE codes, your encrypted EIN, your past performance, and the actions you authorize when filling portal forms or running Guided Sessions. Protecting that data is not an afterthought; it is built into how the product works.

This page explains what we do to keep your information safe, in plain English. For the formal data-handling commitments, see our Privacy Policy. For the contractual terms, see our Terms of Service.

2. Authentication & Sessions

You sign in with Google, Microsoft (Azure), or a one-time magic link sent to your email. BIDS never receives or stores your provider password — magic-link tokens are single-use and expire immediately after use.

BIDS supports optional two-factor authentication (2FA) via any standards-compliant authenticator app (Google Authenticator, Microsoft Authenticator, 1Password, Authy). You can enable or revoke it at any time from your Profile page.

We do not support SMS-based verification. SMS is vulnerable to SIM-swap attacks; an authenticator app is the only second factor BIDS will accept.

Privileged server credentials are held server-side only and are never accessible to the browser or to client-side code.

3. Your Data Stays Yours

Every piece of data you store in BIDS is isolated to your account at the database level. Another authenticated BIDS user cannot read or modify your records under any circumstance — this boundary is enforced by the database itself, not just application logic.

Your business profile, registration numbers, saved applications, submission history, and account requests are all scoped to you and only you. Internal system logs used for security review have no client-accessible access policy whatsoever.

4. Sensitive Data Encryption

Your EIN is encrypted. Your Employer Identification Number is the most sensitive identifier we hold. It is encrypted with industry-standard authenticated encryption before it is ever stored, using a unique key per record. The encryption key is held in a server-side-only environment and is never exposed to the browser.

Your EIN is decrypted only when a specific server-side operation requires it — for example, when copying identifiers into a Guided Session or extension fill. It is never returned in any API response, never stored in browser memory, and never logged. Every decryption is recorded in an internal audit log, creating a complete trail of every time your EIN was accessed.

Other sensitive information — capability statements, application content, financial figures — is visible only to you. Service credentials and API keys are stored in our secure hosting environment, never in source code, and never sent to the browser.

Payment data is handled entirely by Stripe. BIDS never sees or stores your card number or any other payment instrument details.

5. BIDS Vault Security Architecture

Vault credentials are encrypted with AES-256-GCM (authenticated encryption; a unique random 96-bit IV per record) under a dedicated 256-bit key that exists only in our server runtime environment — separate from the key protecting Tax IDs, so compromise of one secret class does not expose the other. The key is never present in client code, never in our background-worker environment, and never stored alongside the database.

Access control is enforced server-side on every request: vault endpoints require an authenticated session, an enrolled authenticator app (TOTP), and an MFA-stepped-up session (aal2 — email one-time codes are not accepted). List, store, delete, and reveal routes are rate-limited, and every access writes an audit record with a hashed source address. The tables holding vault ciphertext are inaccessible to client database roles entirely — all access flows through audited server endpoints.

AI isolation guarantee. BIDS uses AI systems to analyze portal pages and map form fields. Those systems operate on page structure and field labels — never on credential values. In the current release, passwords reach the portal only when you copy them from an audited reveal into the login form yourself. They are stripped from every page snapshot our systems capture, and appear in audit ledgers only as one-way hashes or portal identifiers. This isolation is enforced by automated tests in our release pipeline, not by policy alone. Server-side injection into portal fields is a planned future capability and is not enabled today.

During a Guided Session, credential reveal and clipboard copy happen in your browser next to your dedicated, isolated portal session, whose recording features are disabled under our zero-retention configuration. The portal connection itself uses HTTPS. When BIDS Agent copies Vault usernames or passwords, the same MFA (aal2) gate applies via a short-lived grant — the extension token alone cannot decrypt Vault secrets, and Agent never autofills portal login fields.

6. The Audit Log (Agent tier)

When you use Agent-tier tools that act on official portals — the BIDS Agent browser extension and Guided Portal Sessions — BIDS writes a tamper-evident record of what you authorized. Historical package receipts from earlier product features, if any, remain in the same append-only log. The log has properties that matter:

It cannot be altered or deleted. The audit log is append-only by database enforcement — not just policy. No internal action, credential, or migration can modify or remove a row once it is written.

Sensitive values stay out of the trail. Extension sessions log which profile fields were used and whether you completed in-extension review — not the plaintext values typed into forms. Guided Sessions similarly record lifecycle events without treating BIDS as the agency system of record.

Each portal page is logged as you go. During a Guided Portal Session, BIDS automatically records a hash and timestamp for each page as it is filled or edited — you do not need to take any extra action for this to happen. Sign & Record then locks the full set into one final tamper-evident receipt.

You have read-only access to your own records from Submission History and Audit Log in your account.

Audit rows are retained indefinitely, even after account deletion — they are a legal record of actions you authorized. This is also disclosed in the Privacy Policy.

BIDS never auto-submits applications on your behalf. Pre-Fill, the extension, and Guided Sessions help you complete forms on the official portal; you click Submit yourself.

7. AI Safety

BIDS uses AI for keyword extraction, opportunity summarization, and narrative generation. Every AI call that touches your data or external content goes through multiple layers of defense to prevent prompt-injection attacks — where malicious text embedded in an opportunity description or external source tries to hijack the AI's output.

Those defenses include structural isolation of your content from the AI's instructions, hardened system prompts, pattern detection for known attack signatures, and a full-corpus rescan that catches attacks split across multiple fields. Content is also normalized before scanning to defeat obfuscation techniques like invisible characters and lookalike substitutions.

If an attack is detected on an Agent-tier AI draft (briefs, outreach, or similar), the request is stopped before draft generation runs and the attempt is logged. Draft content cannot reach your profile without passing server-side structural validation.

Drafts are assistive only. Every Opportunity Brief and outreach draft is yours to edit before you send or paste it. Always verify opportunity details and eligibility requirements directly with the issuing agency. BIDS does not use your data to train AI models.

8. Abuse Prevention

All AI-backed and sensitive-data routes are rate-limited per user. Each feature has its own independent limit so heavy use of one cannot affect another. If our rate-limiting infrastructure is unreachable, affected routes return an error rather than silently removing the limit — we prefer brief degraded availability over an open window.

9. Transport & Browser Security

All traffic to BIDS is encrypted in transit. We enforce HTTP Strict Transport Security (HSTS) with a multi-year policy, including subdomain coverage and browser preload registration.

Every response includes a strict set of browser security headers: clickjacking protection, content-type enforcement, referrer controls, a permissions policy that disables camera, microphone, geolocation, and payment APIs, and a Content Security Policy that prevents unauthorized scripts and limits where the browser can connect. API endpoints are excluded from search engine indexing.

IP addresses are not stored in plaintext. When logged for security review, they are stored as a one-way cryptographic hash — useful for correlating activity without retaining a directly identifying record.

10. Third-Party Integrations & Webhooks

BIDS pulls public opportunity and award data from federal and state sources — SAM.gov, Grants.gov, USASpending, and state procurement portals among them. These integrations are read-only: BIDS retrieves information from those systems but never sends your business profile, EIN, or application content to them. The only time your data reaches a government system is when you open the official portal and submit there yourself.

Incoming webhooks (such as billing events from Stripe) are cryptographically verified before BIDS acts on them. Duplicate deliveries are detected and ignored — a captured webhook cannot be replayed to trigger a duplicate action.

11. The BIDS Agent Browser Extension

The BIDS Agent browser extension (Chrome / Edge) is an optional companion that autofills government procurement forms from your saved profile — engineered with the same posture as a password manager:

• It does not connect to government portals on its own. The extension reads your BIDS profile and types into forms you already have open in your browser. It never opens its own connection to SAM.gov, Grants.gov, or eBuy.
• It does not submit on your behalf. Fills are actions you initiate; the submit-button click is always yours.
• Authentication uses a scoped, expiring token stored in secure local extension storage. It can be revoked from your account at any time.
• The extension logs what you did, not what you typed. Each session records the portal origin and which profile categories were used. The actual values entered into government forms are never logged.
• Vault portal logins in Agent are MFA-gated and clipboard-only. Copying a Vault username or password from the side panel requires a short-lived grant minted after authenticator (aal2) step-up on the BIDS website. The Agent extension token alone cannot reveal Vault secrets. Credentials are never autofilled into login fields.

12. Engineering Security Practices

Secret scanning. Every code commit is scanned automatically for leaked credentials and dangerous patterns before it can be accepted. Production builds run the same scan and will refuse to complete if any violation is detected.

Dependency hygiene. Dependencies are monitored for known vulnerabilities and updated regularly. Production infrastructure runs on managed, patched hosting.

Cron job security. Scheduled background jobs require authenticated headers and reject any unauthenticated call. The credentials are held only in our secure hosting environment.

13. What BIDS Does NOT Do

An honest disclosure list is more useful than a marketing list:

• BIDS is not FedRAMP-authorized, SOC 2 certified, or HIPAA-covered. We are an early-stage product. If your organization requires any of these for vendor onboarding, BIDS is not the right tool yet — we will publish any future certification work on this page when it is real.
• BIDS does not auto-submit applications on your behalf. Pre-Fill, Guided Sessions, and the browser extension help you complete official forms; you open the portal and click Submit yourself.
• BIDS does not file or maintain your SAM.gov registration. We surface your SAM status and expiration warnings — registration itself happens directly with the government.
• BIDS does not sell your data to anyone, ever, under any circumstance.
• BIDS does not use your data to train AI models.
• BIDS does not use your Google or Microsoft sign-in data for advertising.
• BIDS does not store your EIN in plaintext — not at rest, not in logs, not in API responses.
• BIDS does not store your payment card numbers. Stripe handles payment processing end-to-end.
• BIDS does not store raw IP addresses in security logs.
• The BIDS Agent extension does not log the values you type into government forms — only which form you filled and which profile categories were used.

14. What You Can Do

A few simple steps make your BIDS account materially harder to compromise:

• Enable two-factor authentication from your Profile page. It takes about a minute and is the single biggest improvement you can make to your account security.
• Use a unique password on the Google or Microsoft account you sign in with, and enable 2FA there as well — your BIDS account is only as strong as the upstream account you sign in through.
• Don't forward magic-link emails. Magic links are single-use sign-in credentials; forwarding one hands over a session.
• Sign out of shared devices when finished, particularly on hardware you don't personally control.
• Review your business profile periodically and remove any information you no longer need on file.

15. Reporting a Vulnerability

If you discover a security vulnerability in BIDS, please report it privately:

• Email [email protected]. Include steps to reproduce, the affected URL or endpoint, and any potential impact.
• Please do not open a public GitHub issue, perform denial-of-service testing, run automated scans that generate significant load, access data that is not your own, or publicly disclose the vulnerability before we have remediated it.
• We will acknowledge your report within 72 hours and follow up with remediation steps. Disclosures are coordinated under responsible-disclosure practices and acknowledged publicly only after a fix is released.

See also our machine-readable security policy at /.well-known/security.txt.

16. Changes to This Page

We may update this page as our practices evolve. The date at the top reflects the most recent material change. Substantive changes affecting how your data is protected will also be reflected in the Privacy Policy.

17. Contact

The Freedom Project, LLC is based in Maryland, United States. Security correspondence: [email protected].

See also our Privacy Policy, Terms of Service, and Legal Disclaimer.