MuniAnchor holds ordinance text, amendment history, and development-review records — including applicant information. Security isn't a feature bolted on at the end; it's how the platform is built. This page is a plain-language account of the controls in place today, written for the planning staff and the municipal IT teams who evaluate them.
MuniAnchor is in active beta. We describe what is actually implemented — and label what is still in progress — so you can evaluate us honestly.
MuniAnchor was built inside a working Rhode Island planning department, by someone accountable to the same public-records and data-handling expectations municipalities operate under. The platform follows a defense-in-depth approach: layered access controls, a single authorization gate for every workspace, encryption in transit, immutable audit logging, and automated checks in our build pipeline that block known-vulnerable dependencies before they ship.
We'd rather under-claim than over-claim. Where a control is fully in place, we say so. Where one is still being rolled out, it's marked In progress. We don't carry security certifications we haven't earned.
Strong authentication and strict separation between municipalities are the foundation of the platform.
App-based two-factor authentication (TOTP) is available on every account. Users enroll by scanning a QR code into any authenticator app and receive one-time backup codes stored only in hashed form. Administrators can require it for sensitive roles.
Municipalities can delegate login to their own identity provider — Microsoft Entra ID (Azure AD), Google Workspace, and other SAML/OIDC providers — through our identity partner, WorkOS. SSO is invite-only: an unrecognized email is denied rather than auto-provisioned, so access stays under your control.
Every municipality's working data lives behind a single authorization gate. One town can never see another town's drafts, amendments, development-review records, or source files. Cross-municipality research surfaces only adopted, publicly shareable ordinance text — never another workspace's in-progress work.
Access is scoped by role at the platform, workspace, and project level — editors, board members, solicitors, administrators, and read-only reviewers each see only what their role permits. Reference materials are read-only by design.
Failed logins are rate-limited per source address, with a separate per-account lockout that also stops attacks spread across many addresses. The login system fails closed: a fresh deployment never ships with a default or guessable administrator password.
Sessions are time-limited and rotated on login to defend against session-fixation attacks. Cookies are HTTP-only with SameSite protection and are marked Secure on every HTTPS deployment. Passwords are subject to a minimum-strength policy.
We protect it in transit, keep recoverable backups, and let you take it with you.
All traffic is served over HTTPS with HTTP Strict Transport Security (HSTS) enabled in production, so connections can't be downgraded to plaintext.
Workspace data is stored in a managed PostgreSQL database with provider-managed encryption at rest and point-in-time recovery, hosted in a U.S. region.
We maintain a documented backup and disaster-recovery runbook with a periodic restore drill, plus a portable tool that produces a complete copy of database and document storage on demand.
Your ordinance text, amendments, and workspace history belong to you. A full workspace export is available at any time, and private workspace content stays private to your organization.
The application is built to resist the common ways web platforms are compromised.
All user- and document-derived content is sanitized through a strict, parser-based allowlist (not a fragile pattern match), so edited ordinance text can't be used to inject scripts.
Every state-changing request is protected against cross-site request forgery, enforced globally across the application.
Responses carry a hardened set of security headers — content-type protection, framing controls, referrer and permissions policy — plus a Content Security Policy.
Uploads are validated by inspecting their actual file signature, not just their extension. Server-side fetches are screened to block requests to internal or cloud-metadata addresses (SSRF), archive extraction is contained against path-traversal (zip-slip), and login redirects are restricted to same-site destinations.
Database queries are parameterized throughout, closing off SQL injection as a class of risk.
MuniAnchor uses Anthropic's Claude API to assist with amendment drafting, structure detection, and research synthesis. A few things we want to be explicit about:
A full plain-language account of what data does and does not leave the platform — per feature — is documented in our AI data-flow reference, available on request.
We keep a record of what happens, and we catch vulnerable code before it ships.
Security-relevant actions — logins, MFA events, section edits, amendment and adoption changes, exports, administrative actions — are written to an immutable audit log, each entry stamped with the originating address for forensics.
The platform emits structured logs and supports integration with error-monitoring (Sentry) for rapid diagnosis. Liveness and readiness probes back operational monitoring.
Our continuous-integration pipeline runs the full test suite on every change as a merge gate, audits dependencies for known vulnerabilities, and proposes security patches automatically every week.
We use a small number of trusted vendors to deliver the service, and share only what each needs to perform its function.
| Subprocessor | Purpose | Data shared |
|---|---|---|
| Anthropic | AI drafting, research, and analysis (Claude API) | Ordinance and amendment text submitted to AI features; not used to train models |
| Railway | Application hosting and managed PostgreSQL database | All workspace data, encrypted in transit and at rest |
| WorkOS | Single sign-on (SAML/OIDC) for municipalities that enable it | Authentication identifiers (e.g. work email) for SSO users |
| OpenGov | Optional development-review / permitting sync | Development-review records, for workspaces that connect it |
| LegiScan | Legislative bill monitoring | None of your workspace data; inbound public bill data only |
A formal subprocessor disclosure and Data Processing Agreement are available on request. In progress: publishing these as standing documents.
We welcome reports from security researchers and municipal IT teams. Use the form below to send us the details. Please don't disclose the issue publicly until we've had a reasonable window to investigate and remediate. Here's what you can expect:
In scope: the MuniAnchor web application and its public endpoints. Out of scope: denial-of-service testing, social engineering, and issues in third-party services we rely on (please report those to the respective vendor).
Last updated: June 28, 2026 · v1.0
MuniAnchor is in active beta and does not currently hold third-party security certifications (such as SOC 2). This page describes the controls actually in place and is updated as our security program matures. MuniAnchor supports municipal planning workflows and is not a substitute for municipal legal counsel or an official codification service.