Protection built into the way Ginsi works.
Identity, company membership, Case access and privacy each have their own checks. Together, they govern who can access company information and what an analysis may reveal.
A sign-in is only the first check.
Ginsi verifies identity on the server. Accepted company membership and role are checked separately before company access is granted.
How this is enforced
Supabase Auth manages signed sessions and credential verification. Ginsi verifies the bearer token on the server before using the authenticated identity in its access checks.
Accepted company membership and database-owned roles establish organization access. Record-level permissions and product access are checked separately. Company administration and Ginsi platform operations use distinct roles.
Company data has clear boundaries.
Database policies and server-side checks govern access to company records. Each Case follows its audience and Workroom permissions; access to the original source is checked separately.
How this is enforced
Row-level security (RLS) scopes database access to the relevant company and record. Case service readers validate a fixed visibility projection and recheck authorization after privileged reads. Database policies and service authorization provide separate controls.
Analysis has privacy boundaries.
Case evidence uses source-specific group thresholds and suppression to reduce the risk of identifying individuals. Free text needs separate handling and can still contain indirect identifiers.
How this is enforced
Case projections apply current visibility and redaction state. Evidence bundles use source-specific group thresholds and complementary-group suppression before analysis, keeping privacy decisions within the data-processing path.
Changed permissions matter.
Case readers check access again after retrieving content. Changed membership, visibility or privacy state can stop a response before it is released.
How this is enforced
An earlier access decision is not sufficient for a later response. Reviewed Case and analysis-queue paths revalidate current authority and relevant privacy state at their effect or response boundary. Revocation, redaction and changing membership must be evaluated in the domain that owns the record.
Protection continues through analysis.
Ginsi prepares permitted evidence, binds queued analysis to a verified work item and checks the privacy state before releasing Case-derived results. Each stage has an explicit control.
Prepare the evidence
The generated-Case path prepares permitted evidence and applies source-specific group privacy rules before analysis.
Technical detail
The generated-Case path builds a bounded evidence bundle before model inference: permitted aggregates, source coverage, data gaps and relevant company context. Source-specific suppression rules determine which statistical breakdowns can be included.
Source scope · group privacy · minimization
Bound the model call
Selected inputs travel over HTTPS. Queued analysis must match a current, verified work item before the model call proceeds.
Technical detail
The model integration sends selected inputs over HTTPS. Queued analysis validates a current database claim that binds the company, work item, execution attempt and privacy revision before the model call proceeds.
Verified work scope · explicit model input
Recheck before release
Case readers check current visibility and redaction state again before returning content.
Technical detail
Case operations use privacy-revision checks at sensitive read, commit and response boundaries. Case readers resolve current visibility and redaction state, so the response reflects the access decision at release.
Current authority · current privacy state
Some analysis paths also use source-level inputs and sanitized free text. Text can still contain indirect identifiers.
How free text is handled
Free text receives separate treatment. Some enabled analysis paths can send source-level inputs and sanitized text to the model provider, including survey-response records where that path applies. Pattern-based sanitization removes certain direct identifiers. Text can still contain indirect identifiers; input selection and privacy handling remain specific to the analysis path.
Permission to analyze
is not permission to identify.
Statistical evidence uses source-specific group suppression and minimization to reduce exposure. Free text and imported attributes can still identify people indirectly and need their own handling. Where survey-response records are present, they remain pseudonymous rather than guaranteed anonymous.
Controls matter when the state changes.
When access is revoked
Case readers revalidate authorization after privileged reads. Case-derived analysis also checks the privacy revision before committing or releasing a result. A changed permission or privacy state can stop the response.
When a model request needs review
The queued-analysis integration reserves a logical model call before sending it. Its idempotency checks block duplicate sends for the same reserved call. An ambiguous transport result is held for attention, keeping a retry from silently creating another paid request.
When a group is too small
Relevant evidence breakdowns count distinct contributors and apply complementary-group suppression. Withholding only the small group is insufficient if another result would reveal it by subtraction.
When something goes wrong
Identity verification, the administrative API and the operational-import handler use fixed client-facing errors and bounded diagnostic fields. These handlers limit the error detail exposed to the browser and the data written to their diagnostics.
Inspect the controls behind the product.
Explore the architecture and control mechanisms with your IT team. Bring your identity, data-processing and operational requirements into the review.
Implementation evidence
Architecture, authorization boundaries and focused control tests. These explain the mechanism and the behavior exercised by the test.
Deployment evidence
Review the target environment, configured identity provider, session settings and released controls for your company.
Contractual commitments
Discuss processing terms, subprocessors, processing locations, retention and service requirements as part of your security review and agreement.
Identity and access, in detail.
| Control | Implemented mechanism | Control scope |
|---|---|---|
| SAML SSO | Provisioning derives the provider from verified authentication claims and an active server-owned connection. Company and default role come from that connection. | Configured per company. Customer IdP setup and end-to-end acceptance must be verified before use. |
| Invitations | Server-owned invitations and acceptance establish membership. Concurrent acceptance, revocation and role changes use transaction and locking boundaries. | Access follows accepted membership and the current role. Revocation expires earlier invitations. |
| Multi-factor authentication | Users can enroll TOTP. The protected application challenges an enrolled user when the session can advance from AAL1 to AAL2. | Optional, user-configurable TOTP. The application checks session assurance for enrolled users. |
| Tenant & Case isolation | Organization-scoped database policies and bounded Case projections enforce permitted visibility. Case readers revalidate authorization after privileged content reads. | Company membership, applicable Workroom scope, Case visibility and current privacy state. |
| Operator access | Platform administration uses database-backed operator authority and a verified administrative boundary, separate from customer owner/admin roles. | The administrative API verifies platform-operator authority before dispatching an administrative action. |
Security, in practice.
Bring us your questionnaireHow are model and email requests protected in transit?
Ginsi’s model and transactional-email integrations use HTTPS with TLS to encrypt requests in transit. Server-side credentials authenticate these service calls. The analysis input and email content are selected by their respective application paths.
How is access to company records controlled?
Accepted company membership and database-owned roles establish organization access. Row-level security (RLS) and record-specific authorization apply the relevant company and visibility scope. Case service readers validate a fixed projection of permitted records and recheck access after privileged reads.
What information reaches the AI model?
The generated-Case path prepares an evidence bundle containing permitted aggregates, source coverage, data gaps and relevant company context. Other enabled analysis paths can include source-level inputs and sanitized text, including survey-response records where that path applies. The selected inputs depend on the path’s evidence contract; free text can still contain indirect identifiers. The privacy notice describes AI processing, with provider data-use and retention requirements addressed through the applicable processing terms.
How is platform administration authorized?
The administrative API verifies the authenticated identity and checks database-backed platform-operator authority before dispatching an administrative action. This role is separate from customer company owners and administrators. Customer roles control their organization; platform operations use their own authorization boundary.
What happens when access or privacy settings change?
Membership revocation expires earlier invitations. Case readers evaluate current visibility and redaction state, then revalidate authorization after privileged content reads. Case-derived analysis binds its work to a privacy revision and checks that revision before a result is committed or released. These checks allow a changed state to stop work at the relevant boundary.
How are small groups protected in the evidence?
Statistical breakdowns use source-specific minimum-group thresholds. Relevant controls count distinct contributors and apply complementary-group suppression, withholding related results when subtraction could expose a small group. Free text and imported attributes receive separate privacy handling. Where survey-response records are present, they remain pseudonymous rather than guaranteed anonymous.
How are access changes recorded?
Workroom access changes create transactional event records alongside the permission change. Each record binds the actor, affected member and authority revision. Selected administrative and import handlers also use bounded diagnostic fields. Access events, operational diagnostics and the evidence history in a Case serve distinct review purposes.
