Security

Last updated: September 28, 2026

This page describes how RFP Monitor protects your data. For what we collect and why, see our Privacy Policy. For the vendors involved, see Subprocessors.

1. What the Service handles

RFP Monitor indexes public government solicitation data. The customer data it holds is limited:

• account details (from our sign-in provider, WorkOS);
• your Team's search-context profile, saved searches, pipeline and comments;
• your searches; and
• issue reports.

It is not built for Controlled Unclassified Information (CUI), classified information or export-controlled data. Our Terms of Service prohibit uploading them. The Service does not hold a FedRAMP authorization and has not been assessed against NIST SP 800-171 or CMMC.

2. Hosting and infrastructure

• The Service runs on Cloudflare's serverless platform:
  • Cloudflare Workers for the application;
  • Cloudflare D1 for the database;
  • Cloudflare R2 for stored solicitation attachments.
• We do not run our own servers or virtual machines for production.
• The application is reachable only through its production hostname. The default public workers.dev addresses are turned off. The data-ingest service has no public address at all; the application reaches it over an internal Cloudflare service binding.
• Production deploys run from our CI pipeline after automated checks pass. Deploy credentials and API keys are stored as encrypted CI secrets and Cloudflare Worker secrets, not in source code.

3. Encryption

• In transit: all traffic to the Service uses HTTPS (TLS). Traffic between our application and our providers (WorkOS, OpenRouter) also uses HTTPS. Traffic between the application, D1 and R2 inside Cloudflare's network is encrypted with TLS.
• At rest: Cloudflare encrypts all data stored in D1 and R2 with AES-256 in GCM mode, including metadata (D1, R2).
• Secrets we never keep in plain form: session tokens are stored only as SHA-256 hashes. We do not store passwords; the Service has none.

4. Sign-in, SSO and MFA

• Sign-in provider. WorkOS AuthKit handles sign-in. Users sign in with a one-time email code, a passkey, or their organization's single sign-on. The Service has no passwords.

• Enterprise SSO. A Team administrator can connect the Team's own identity provider, such as Okta, Microsoft Entra ID, Google Workspace, or any SAML or OIDC provider. They can also verify the Team's email domain, so that everyone at that domain signs in through the identity provider. Your identity provider's credentials are never stored by the Service.

• Directory sync. On plans that include it, Teams can sync users and groups from their directory (SCIM) through WorkOS, and map directory groups to roles. When a user is removed from the directory, WorkOS removes their Team membership, and their access to the Team ends when their session next refreshes, within minutes.

• Sign-in policies. A Team owner can turn on either or both of these for the Team:

  • Require SSO (on plans that include SSO): members must sign in through the Team's SSO.
  • Require MFA: members must sign in through the Team's SSO, where the identity provider applies its own MFA, or with a passkey. A one-time email code alone does not meet this policy.

  The Service checks a Team's policy at sign-in, each time a session's tokens are refreshed, and before anyone switches into the Team, so turning a policy on ends non-compliant sessions within minutes. An owner can turn a policy on only if their own current session already meets it, so a Team cannot lock out the owner who enables it.

• Passkeys are phishing-resistant. Teams that use SSO apply their own identity provider's MFA policy.

• Sessions.

  • Your browser holds a random 256-bit session token in a cookie marked HttpOnly, Secure and SameSite=Lax. We store only the token's hash.
  • Sessions last at most 30 days and end when you sign out. Signing out also ends your session with WorkOS.
  • WorkOS access tokens last five minutes, so a role change or removal takes effect within minutes.
  • The sign-in flow uses PKCE, and binds its state to your browser to prevent login forgery.

• AI assistants (MCP).

  • AI assistants connect through OAuth, with WorkOS as the authorization server.
  • The Service checks each request's token signature, issuer, audience and expiry.
  • Each token is limited to the Team chosen at consent.

5. Tenant isolation and access control

• Each Team is a separate organization in WorkOS. Every record that belongs to a Team carries the Team's organization ID. The Service reads and writes Team data only through a data-access layer that scopes every query to the Team of the signed-in session, so one Team cannot read or change another Team's data.

• Each member has one of four roles in a Team:

  • Owner: everything an admin can do, plus billing.
  • Admin: manages members, roles, sign-in settings, API keys and the audit log, and uses the Service like a member.
  • Member: searches, uses AI features, works on the Team's pipeline, comments and alerts, and runs exports.
  • Viewer: read-only access.

  The Service checks the permission each route needs on every request. Administrative actions, such as inviting, removing or changing the role of a member, check the membership against WorkOS at the time of the action.

• IDs belonging to another Team are rejected as not found.

• Our staff.

  • Internal operator functions (managing data sources and running collection jobs) are kept apart from customer access. They are restricted to named staff, who need an operator role in our own WorkOS organization and must pass Cloudflare Access.
  • Our staff access Customer Data only to provide support that the customer asked for, to keep the Service secure, or when the law requires it.
  • For support, a staff member can sign in as a user through WorkOS impersonation. The Service records the staff member's email address on that session. Impersonation is not currently recorded in the Team's audit log.

6. Application security

• Web pages set a Content-Security-Policy with per-request script nonces, and forbid being framed by other sites.
• Attachments from government sources are treated as untrusted files. They are always served as downloads with X-Content-Type-Options: nosniff, so they cannot run as web content in the Service.
• Database queries use parameter binding.
• Changes are made through pull requests. Production deploys only after automated type-checking and test suites pass.
• Every pull request, and every change to our main branch, runs automated security checks:
  • static analysis with Semgrep, including our own rules against unsafe HTML handling and SQL built from strings;
  • a dependency audit that fails on any High or Critical advisory in a production dependency; and
  • a secret scan with gitleaks.

7. Logging and monitoring

• Cloudflare Workers observability records application logs and request metadata. We keep logs for up to 30 days.
• WorkOS records sign-in events.
• Team audit log. The Service records security-relevant actions in each Team's audit log in WorkOS: invitations, member removals and role changes, members leaving, API keys created and revoked, changes to the Team's pipeline, data exports, audit log exports, and opening the WorkOS Admin Portal to change SSO, directory sync, domains or log streaming. Team owners and admins can view the log and export it as a CSV file. On the Enterprise plan they can also stream it to their own systems.
• Automated health checks run daily and alert our team when a data source or the data pipeline fails.
• Error monitoring. While error monitoring is switched on, errors in the application and the data-ingest service are reported to Sentry. Cookies, credentials, query strings, IP addresses and other user details are removed, and email addresses are masked, before a report is sent.

8. AI data handling

• Natural-language search sends your request and your Team's search-context profile to OpenRouter. OpenRouter routes it to the model provider listed in Subprocessors.
• Other AI features process only public solicitation text.
• We do not use Customer Data to train models.
• Our requests do not currently pin a model provider or set a zero-data-retention option. Each provider handles requests under its own data policy, which Subprocessors links to.

9. How we collect public data

• We collect only data that government bodies publish on public websites and public APIs. We do not sign in to access-restricted portals.
• Our crawler identifies itself in its User-Agent header, with a contact address. Staff review each source's robots.txt when deciding which sources to collect from.
• State and local portals are scraped once a day to limit load on government sites.
• If a public posting appears to contain CUI, classified information or personal information published in error, report it to support@shannoncyber.ai. We will remove or restrict it.

10. Backups and continuity

• Database. Cloudflare D1 Time Travel lets us restore the database to any minute in the last 30 days. Cloudflare manages it; we do not keep separate exports of the database.
• Attachments. The files in R2 are copies of attachments that government sources published. Cloudflare designs R2 for 99.999999999% annual durability. We do not keep a separate backup copy.
• Accounts and Teams. Users, Teams, memberships and roles are held by WorkOS, not in our database.
• We have not yet set formal recovery time or recovery point objectives.

11. Incident response

If we become aware of a security incident that affects your data, we will:

• investigate it;
• contain it; and
• notify affected customers without undue delay, and in any case within 72 hours after we confirm it.

The notice will say what happened, what data was involved, and what we are doing about it.

12. Compliance

We do not currently hold a SOC 2 report or other third-party certification. Our infrastructure providers (for example Cloudflare, WorkOS and Stripe) maintain their own. Their certifications cover their services, not ours:

• Cloudflare Trust Hub
• WorkOS Security
• Stripe security

13. Reporting a vulnerability

Email support@shannoncyber.ai. Please include:

• a description of the issue;
• steps to reproduce it; and
• its potential impact.

We will acknowledge your report within 3 business days and keep you updated until it is resolved.

Safe harbor. If you research the Service in good faith and follow these rules, we will consider your research authorized and we will not pursue or support legal action against you for it:

• Only test accounts and Teams that you own.
• Avoid privacy violations. Do not access, change or delete other people's data. If you encounter it, stop and tell us.
• Do not destroy data, and do not degrade the Service. This rules out denial-of-service testing, spam and heavy automated scanning.
• Do not exploit an issue beyond what you need to show that it exists.
• Give us reasonable time to fix the issue before you disclose it publicly.

If a third party brings legal action against you for research that followed these rules, we will make it known that your research was authorized.

14. Contact

Security questions: support@shannoncyber.ai