ForgeOps Security & Data Practices

This notice describes how the ForgeOps platform is built and operated from a security and data-protection standpoint. It describes controls that are in place today. Where something is planned rather than implemented, it says so.

1. Tenant isolation

ForgeOps is multi-tenant. Every organization is a separate tenant, and every tenant table in the database has row-level security enabled and forced — including for the table owner. Access policies are evaluated by the database on every read and write, and route through a small set of security-definer helper functions that resolve the caller's membership and permissions.

This matters because it means isolation does not depend on application code remembering to filter by organization. A query that forgot its tenant filter returns nothing rather than returning another customer's rows.

Every security-definer function pins its schema search path, which closes the search-path manipulation class of privilege escalation.

2. Authentication

Authentication is email and password, handled by our authentication provider. Passwords are stored only as salted hashes and are never visible to ForgeOps. Session cookies are HTTP-only — the application is server-rendered and no browser-side script needs to read a session — and are marked secure outside local development, with an explicit same-site policy.

Invitations are issued as single-use tokens with an expiry. Only a SHA-256 hash of the token is stored; the raw token exists only in the link sent to the invitee. An invitation can only be accepted by the email address it was issued to.

3. Authorization

Access is role-based. Roles are defined per organization, permissions are granted to roles, and every server action re-checks the caller's permission on the server before acting — the interface never grants access on its own. Sensitive record classes additionally enforce record-level access, so being a member of an organization does not automatically mean seeing every job in it.

Approval authority can be bounded by dollar thresholds, so the ability to approve a small purchase does not confer the ability to approve a large one.

4. Secrets and credentials

The database service-role credential — which bypasses row-level security — is server-side only. It is never present in client code, never committed, and is used only by explicitly-scoped server modules and operator scripts.

Third-party integration credentials are held server-side and are stored encrypted. Integration access is granted by the customer through the provider's own OAuth consent flow and is limited to the scopes the customer approves.

5. Audit logging

Material actions inside an organization are recorded to an append-only audit log: who acted, what action, which record, when, and a short summary. Writes go through a controlled database function that refuses to write an entry for an organization the caller does not belong to. Organization administrators can read their own audit log; no organization can read another's.

Agreement acceptance events, legal document publication, changes to acceptance requirements, organization ownership transfers and exports of agreement evidence are all recorded there.

6. Uploaded content

Files uploaded to ForgeOps — drawings, models, photographs, receipts, spreadsheets, email attachments — are stored in access-controlled object storage. Links issued to the browser are short-lived, credential-bearing URLs issued only after a permission check, and are scoped to the requesting organization's storage prefix.

Attachments received through inbound email intake are scanned before they are made available, and mail from unknown senders is quarantined for human review rather than acted on automatically.

Spreadsheet content is read as data. Formulas in an uploaded workbook are never executed.

7. Untrusted content and AI features

Text that originates outside ForgeOps — customer, vendor, RFQ, proposal and imported spreadsheet content — is treated as untrusted throughout, including where it is passed to an AI feature. AI features produce drafts for human review; the Service does not auto-commit an AI-derived record without a person approving it.

8. Change control

Database schema changes are made only through reviewed, version-controlled migrations. Production schema is not edited by hand through an administrative console. Application changes pass type checking, linting, an automated test suite and a production build before release.

9. Data integrity for legal records

Published legal document versions carry a SHA-256 digest of their own canonical content. That digest is copied onto every acceptance record at the moment of acceptance, so the exact text a person agreed to can be re-verified later. A version that has been accepted is immutable — the database refuses edits to its content, version, type and hash — and any change is published as a new version instead.

10. Availability and backups

The Service runs on managed cloud infrastructure with automated database backups on the provider's schedule.

11. Sub-processors

Infrastructure and service providers with access to Customer Data are listed in the ForgeOps Subprocessor List, published alongside this notice.

12. What is not in place yet

Stated plainly, because a prospect will ask:

• ForgeOps has not completed a SOC 2, ISO 27001 or equivalent third-party audit.
• There is no published penetration test report.
• Single sign-on and SCIM provisioning are not yet available; identity-provider integration is on the

roadmap.

• Customer-managed encryption keys are not offered.

13. Reporting a vulnerability

Send security reports to security@forgeops-erp.com. Please include enough detail to reproduce the issue. Do not access data that is not yours in order to demonstrate a finding, and give us a reasonable opportunity to remediate before public disclosure.