Security at Forge

Forge is operated by GradTensor in our own cloud accounts. The application runs on Vercel and the database and file storage on Supabase. Your documents, the text extracted from them, and your records live in that database. They are not copied anywhere else.

What leaves that environment is the model calls. To answer a question, Forge sends the question and the specific passages retrieved to answer it. To make a document searchable in the first place, its text is sent once for embedding. Nothing else is transmitted, and no single call sends more than the passages needed to answer it.

• Nothing you send is used to train any model. This is contractual, under commercial terms with every provider we call, not a setting.
• Personal data is masked before a message reaches a model. This is on by default, and an organisation admin can require it so that no individual member can turn it off.
• Redaction of document text at ingestion is a separate, per-library setting and is off by default, because a knowledge base often needs the real values in its answers. An organisation that wants it applied to stored text as well turns it on per library.
• A document uploaded to a project or a library is not kept as a file. After extraction the original is never read again, so it is deleted; what remains is its text in segments, and an embedding of each segment, which is what search runs against.
• A file attached to a one-off chat is never stored as a file at all. Only its extracted text is held, it is not indexed or searchable from any other conversation, and it is deleted with the conversation.
• Three things are deliberately kept as files, because the feature does not work otherwise: a program you upload to a program app, which has to be there to run again; what a run produced, which is the report you came for; and documents attached to a business app record, such as vendor onboarding paperwork. These sit in private storage, are reachable only through Forge, and are deleted with the app or the record they belong to.

One point of detail, because it is often assumed otherwise. The text of a document is stored as text. Embeddings are stored alongside it, not instead of it: an embedding is a list of numbers used to find the right passage, and it cannot be turned back into the passage, so the passage itself has to be kept in order to be shown to you and sent to a model. Forge is therefore able to read what you store, which is the plain reading of section 9 and the reason access control and the audit log carry the weight they do here.

Sub-processors

The complete set of parties that touch customer data. Each name links to that provider’s own published terms and security documentation. We summarise them here for orientation; the provider’s page is the authority, and provider policies change, so verify directly if your review depends on it.

Bring your own key

An organisation admin selects the model provider and can supply your own API key for it. Every member’s model calls then run on that key, so model usage appears on your own account under your own commercial terms with the provider, and the admin can see usage per member. Keys are encrypted at rest and are never displayed again after saving.

The exception, stated plainly. Your key covers the reasoning calls. Document indexing and search run on Forge’s own provider accounts under no-training terms, which means embedding sees document text at ingestion and your query on retrieval. This is how the hosted platform works rather than a temporary gap: those services are part of what we operate, so on the hosted platform they stay on our accounts and under our contracts.

If your requirement is that every call runs under your own contracts, in your own account, that is what private deployment in your own cloud account does, and it is the honest answer rather than a longer list of keys. See section 5.

Forge is a multi-tenant hosted platform. Customers share one application and one database, and are separated as follows.

• Cross-organisation separation is enforced in the application layer. Every tenant read and write resolves the caller's organisation, verifies membership, and filters on the organisation id through a single guarded helper, so the check is reviewable in one place rather than repeated per route.
• Row-level security is enabled on tenant tables with no policies, which denies the public database API any direct access to them. The application reads through a service-role connection that bypasses this, so row-level security is defence in depth today rather than the cross-organisation boundary.
• Within an organisation, access to a project is granted per project, not to everyone in the organisation by default.
• Each member's chat threads are private to them by construction: the data layer offers no query that returns another member's conversation.
• Authentication runs on Supabase Auth, with email and password sign-in. It is invite-only and there is no open registration.
• Multi-factor authentication is not available today, and is planned. Single sign-on and SCIM provisioning are not offered.
• Roles are organisation admin and member. GradTensor holds an operator role with cross-organisation access, used for support and administration.

Making the database itself the per-organisation boundary, with membership-keyed policies and reads moved onto the user-scoped connection, is planned.

Data at rest is held in Supabase in the ap-southeast-2 (Sydney) region, and application compute runs in the same region. This is one region for all customers on the hosted platform. Per-customer region placement is not offered today, and moving stored data alone would not achieve residency in any case, because model inference leaves the region regardless.

One exception, and it is a smaller one than it was. When a program app runs, the uploaded program and the files the member supplied are executed in a container on Cloudflare’s network, not in Supabase in Sydney. That container is constrained to the Asia-Pacific region: it is not placed freely across Cloudflare’s network, and a run does not execute in America or Europe. It is created for that single run, has no network access at any point while your program runs, and is destroyed afterwards.

Two things to be precise about, because this is a residency claim and they are the parts a reviewer should test. Asia-Pacific is a region, not a country, so this says a run stays within that area and not which country inside it was used. And the processing still happens outside the Sydney region named above, on a different provider. If your requirement is that data is processed in one named country, or inside a specific compliance boundary such as the EU, that is available as a dedicated deployment rather than on the shared platform, and it is worth raising before you start rather than after.

Encryption is TLS in transit and provider-managed encryption at rest. Stored credentials, including API keys, are additionally encrypted by Forge with AES-256-GCM. To be precise about what that does and does not cover: extracted document text is held in the database in a form Forge can search, so encryption protects against exposure of the storage layer and is not a claim that we are unable to read your documents.

• Conversation retention is configurable per chat space and per project, and an organisation admin can set a ceiling that no member may exceed.
• A scheduled daily sweep deletes conversation past its window, including the text of any file attached to it, so an expired conversation does not leave its attachment behind.
• New chat spaces default to a 30-day window. Spaces created before that default existed were deliberately left unchanged rather than having history silently deleted, and are offered the change.
• Documents and records are not on a retention timer. They persist until deleted, by you or on request, and deleting a document removes its derived embeddings with it.

Access and administrative actions are recorded to an append-only log that organisation admins can read. It records who did what, to which resource, and when.

It never records content. No message, prompt, reply, or document text goes into the log. That boundary is the point: it is how an admin gets oversight of use without gaining the ability to read their colleagues’ conversations.

• Recorded: project and document access, uploads and deletions, record changes, exports, membership and role changes, privacy policy changes, publishing or unpublishing a project, and organisation key changes.
• The retention sweep writes its results to each organisation's own log, with counts of what was deleted, so a request for evidence that deletion happens can be answered from the customer's own audit view rather than by assertion.
• Usage is attributed per member, including which funding path paid for each call.
• Reliability is reported for your own organisation: how many questions each project answered, how often it declined rather than guessing, how many excerpts each answer rested on, and which retrieval strategy was used. Counts only, on the same boundary as the audit log.

Hosted platform. The standard option, and what everything above describes: operated by GradTensor, one region, shared application and database, with organisation-level separation as set out in section 2.

Hosted, on your own model key. The same platform with your organisation’s own provider key supplying the reasoning calls, subject to the indexing and search exception in section 1. Available today, configured by your admin.

Private deployment in your own cloud account. Offered under an enterprise agreement, provisioned per engagement rather than as a self-serve product. This is the option that resolves residency and tenancy together, because the database sits in your account, in the region you choose, and the deployment serves only you. If this is what your review requires, talk to us early: it is scoped and delivered as part of the engagement. The data processing agreement and the specific residency and tenancy arrangements are settled there too.

The questions that are particular to an AI system, rather than to software in general. These follow from the three properties Forge is built for, which are set out in full under Defensible AI.

• Nothing you send trains a model. Contractual with every provider we call, on every plan, not a setting a user could get wrong.
• Answers to questions about your documents are grounded in those documents and cite what they drew on, so a reader can check an answer against its source rather than taking it on trust.
• The system is built to refuse rather than guess when your material does not support an answer.
• Calculations over your data are computed rather than generated, so a number is reproducible and does not depend on the model getting arithmetic right.
• Only the context needed to answer a question is sent to the model, not your whole corpus.
• Personal data is masked before egress by default, and can be required at organisation level so an individual cannot weaken it. Redaction of stored document text at ingestion is separate and off by default (section 1).
• A person stays in control of consequential steps. Forge is built to draft, retrieve and compute; it does not act on your systems on its own initiative.

Forge does not hold SOC 2, ISO 27001, or any other formal certification. Certification is not scheduled today.

Forge runs on infrastructure that is certified, including Vercel, Supabase and the model provider your organisation uses, each under its own published attestations and data processing agreements. That is a real part of the posture and it is not the same as Forge being certified. Forge is an operated platform, not an independently audited product.

What we can provide contractually is a data processing agreement that flows down our sub-processors’ agreements, a completed security questionnaire, and the evidence described in section 4. Forge is designed to support your data protection and governance obligations. It does not discharge them, and no vendor can tell you that it makes you compliant with anything.

Forge does not operate a formal, documented incident response programme with published detection and response targets.

What exists today: access and administrative activity is recorded to the append-only audit log described in section 4, which is where an investigation of anomalous access would begin. Our commitment to notify you of a personal data breach is contractual and set out in the data processing agreement, which requires notification without undue delay after we become aware, and flows down our sub-processors’ own breach-notification obligations.

A documented runbook with defined roles and response timelines is planned.

The current limits, in one place.

• No formal certification. SOC 2 and ISO 27001 are not held.
• No per-customer region choice on the hosted platform, and model inference leaves the hosting region regardless of where data is stored.
• On the hosted platform your own key covers reasoning calls. Document indexing and search run on Forge's provider accounts, and that is structural rather than pending. Private deployment is the option where every call runs under your own contracts.
• Cross-organisation isolation is enforced in the application layer. Row-level security is enabled as defence in depth but is not yet the database boundary.
• GradTensor holds an operator role with cross-organisation access for support and administration.
• Extracted document text is stored in a form Forge can search, so Forge is technically able to read your documents.
• Retention windows apply to conversations. Documents and records persist until deleted.
• No single sign-on or SCIM provisioning, and no multi-factor authentication. Access is invite-only, on email and password, managed per organisation.
• No formal incident response programme. Activity is logged (section 4) and breach notification is governed by the data processing agreement, but a documented runbook with defined response timelines is not in place.