Loading…
Loading…
This page explains the public baseline: how GlobiGuard handles access, review records, deployment choices, and documentation. It is meant to help technical and non-technical evaluators understand the product without turning private implementation detail into public copy.
Account access, workspace settings, billing, app keys, and review activity are available in the hosted product today.
Hosted, managed private, and customer-controlled paths are handled differently. Availability depends on the rollout path and contract.
User sessions, step-up checks, API keys, and service accounts are separated so people and systems do not share the same access model.
Baseline trust, setup, and product docs are public. Customer-specific reviews stay available through a separate request path.
GlobiGuard is not one deployment shape. Hosted workspaces, managed private rollouts, and customer-controlled deployments have different boundaries and operational responsibilities.
Best for teams starting quickly with the shared product. Workspace users manage access, billing, apps, and review activity from the hosted workspace.
For customers that need a tighter operating boundary or guided onboarding. Exact isolation, hosting, and support terms depend on the agreed deployment plan.
For self-hosted, private-cloud, or sovereign environments. Secret handling, retention, and infrastructure controls remain deployment-specific and are not described in full on this page.
Baseline trust and setup material stays public. The request path is for customer-specific review, not for hiding the basics.
Workspace access is tied to authenticated user sessions. Sensitive actions can require step-up verification before they complete.
API keys, service accounts, and app keys are scoped separately from user sessions so operational access can be rotated and reviewed independently.
Supported product flows record security and review events so teams can inspect activity without exposing raw secrets back to the browser.
The hosted path, managed rollout path, and customer-controlled path do not share the same security envelope. This page describes the public baseline, not every contract-specific detail.
Public trust copy should explain where the product helps and where outside review is still required. It should not turn framework names into unsupported promises.
GlobiGuard maintains public documentation and product mapping across 12 frameworks and standards. Those mappings help teams understand which controls or records the product can support.
Some frameworks are supported through direct product records, while others require partner review, customer process, or external certification work. Public docs should be read as support material, not as a substitute for an audit or legal review.
Questionnaires, deployment-specific architecture reviews, and private security discussions can be requested when a customer needs material beyond the public trust and documentation set.
Short answers for buyers and technical evaluators. These notes stay high-level so public documentation remains useful without publishing secret architecture.
The hosted product processes account, workspace, app/key metadata, supported policy inputs, and review records needed to operate the configured workflow. Customer records should only move through supported product or deployment paths.
Security-sensitive product flows record account and workspace activity such as sign-ins, step-up events, key creation/revocation, connector changes, and supported review decisions. Raw provider secrets are not returned to the browser after save.
The public and demo UI may keep consent choices, guided-tour progress, and non-secret demo progress in local or session storage. API keys and provider secrets should be submitted through server routes and are not intentionally stored in browser localStorage.
Workspace users see data according to their role and product permissions. Internal operational access, where applicable, is limited to support and deployment needs and is handled through customer-specific review rather than public architecture copy.
Private, self-hosted, or sovereign deployments use a different security envelope from the hosted workspace. Exact isolation, retention, residency, and operational responsibility are documented during the private review and contract process.
Incident communication depends on customer relationship and deployment path. Public pages provide the baseline; customer-specific notification channels and timelines should be confirmed during onboarding or security review.