Security
Written for the person doing the security review.
This page describes what is actually implemented: how identity, sessions, secrets, execution and network access work in Forewarden, in enough detail to check against your own controls.
- AES-256
- GCM envelope encryption for every stored credential, with key rotation by version
- 8h / 12h
- session idle and absolute timeouts; every session records its IP and client
- Append-only
- audit log: a database trigger rejects UPDATE, DELETE and TRUNCATE for every role
- Read-only
- tools for the AI Data Engineer; every agent and MCP tool call is written to the audit log
§ 01/Identity & access
Who can sign in, and what they can touch
- Sign-in
- Email and password with bcrypt hashing and sign-in throttling, or Microsoft Entra ID (OIDC), the only single sign-on provider today. Sessions are opaque server-side tokens in Postgres; the token never leaves the server and the session endpoint returns only an allowlisted user summary.
- MFA
- TOTP enrollment with a QR code and one-time recovery codes, and atomic lockout after repeated failures. Passkeys (WebAuthn) are supported alongside. A system admin can require MFA for every password account on the deployment, which forces enrollment at next sign-in; Entra ID sign-ins are not asked for a Forewarden code.
- Password changes
- Self-service change and admin reset both sign out every other session for that user.
- Roles
- Viewer, Analyst, Developer, Maintainer and Admin per project. Only Maintainers and above can run against production; only Admins can change connections and members. System administrators manage every project and user.
- Provisioning
- SCIM 2.0 (Users, Groups, Schemas, ServiceProviderConfig) for Microsoft Entra ID and other SCIM clients, with group-to-role mappings per project. Deprovisioning ends the user's sessions immediately. Provisioned users have no local password and sign in with Microsoft Entra ID. Users with audit history are disabled, never hard-deleted.
- Support access
- Support staff can view a user's account only after the user reads them a one-time PIN shown in their own session. The session is read-only (every mutating request is blocked) and ends after 60 minutes.
§ 02/Secrets & execution
Credentials stay server-side; code runs in a box
- Secrets
- Warehouse credentials, git tokens, SES keys and AI provider keys are encrypted with AES-256-GCM envelope encryption under a master key and are never returned to the browser. Warehouse credentials are decrypted only inside the worker when a query or run needs them. AI, email, Jev and GitHub status keys are decrypted in the web server for the single outbound request that uses them. Git tokens are never written to .git/config.
- Execution isolation
- dbt, SQLFluff, MetricFlow and git run as child processes with an allowlisted environment. A project's env_var() cannot read the master key, the worker token or the database URL. Job runs build from a fresh checkout of the pinned commit, not from anyone's workspace.
- SQL workspace
- Ad-hoc queries, from the SQL workspace or MCP's execute_sql, are parsed with sqlglot in the warehouse's dialect and limited to single read-only statements (SELECT, WITH, set operations, SHOW, DESCRIBE). DML inside CTEs, SELECT INTO and server-side file, network, session and sequence functions are rejected. PostgreSQL, Oracle and ClickHouse also enforce read-only on the server: a READ ONLY transaction, SET TRANSACTION READ ONLY and the readonly=2 setting respectively. On every other warehouse there is no session-level read-only mode and the statement guard is the only barrier, so connect with a least-privilege warehouse role that cannot write.
- Git
- Transport allowlist https, ssh and file (no ext::). Remote URLs are validated on both the web and worker sides: no embedded credentials, no leading dash. Branch names are validated too.
§ 03/AI & MCP
What AI tools can reach, and the record they leave
- AI Data Engineer
- Off by default; a system admin enables it with a provider key. Its tools are read-only and fixed in code: it cannot edit files or trigger or cancel runs. It is pinned to the current project, runs with the user's own role, and is bounded to 8 rounds, 6 tool calls per round and 150,000 tokens per session.
- Row data
- Warehouse rows are sent to the AI provider only when the user ticks the row-data option and their role can use the SQL workspace. Tool results are passed to the model as data, not as instructions.
- AI ledger
- Agent sessions and steps are stored as SHA-256 digests and Forewarden-written summaries. Prompts, responses and transcripts are not stored.
- MCP
- Tokens need the mcp scope. Each of the 14 tools has a minimum project role, SQL and metric row limits follow the caller's role, and personal tokens act as their owner.
- Audit trail
- Every tool call made by the AI Data Engineer or an MCP client is written to the append-only audit log.
§ 04/Network
Inbound, outbound and the browser
- IP allowlist
- CIDR ranges enforced in the request proxy before any route runs. If a change would exclude the address you are using, it is only saved after you confirm.
- Outbound
- Notification webhook URLs pass an SSRF guard: private, loopback and link-local addresses are blocked after DNS resolution. Generic webhooks are signed with HMAC-SHA256 and carry event, delivery id and timestamp headers for replay checks. Slack and Teams messages are not signed.
- Headers
- Content-Security-Policy and standard security headers on every response; the editor is served from the same origin with no CDN. CSV exports neutralize spreadsheet formulas. Callback URLs are same-origin only.
- Proxies
- Client IPs come from the socket. X-Forwarded-For is honored only when explicitly configured behind a trusted reverse proxy. Cookies are Secure in production.
§ 05/Certifications
What we hold, and what we don't
We do not hold a SOC 2 report or a similar third-party certification today, and will not claim one we do not have. Hosted trials run on infrastructure we operate, so network isolation, disk encryption and backups are on us. Self-managed deployments put all of that under your own controls. If your team needs to review ours as part of an assessment, send us a message and we will walk through them directly.