1. Inbound: how users reach the platform
Controls on this path:
In a private tenant with private-only access there is no public entry at all: this whole
path sits behind the VPN, and the public internet sees no open ports for the dashboard or
API. See Private network access (private tenant) below.
2. Outbound: the egress policy
The stance is deny by default. All outbound traffic is forced through an egress control layer that enforces an explicit allowlist by hostname: a workload cannot reach an endpoint that is not on the list. That layer is a single choke point, where outbound policy, TLS origination and traffic logging apply. The complete list of destinations, with hostnames, ports and when each fires, is in Outbound connectivity reference; the mechanics of setting the routes up, including the choice between internet egress and the VPN tunnel, are in Connectivity implementation. What leaves, by category, and whether you can restrict it:
One more property that matters for trust: resilience. Outbound calls carry timeouts,
retries with backoff and circuit breaking, so a slow or failing endpoint of yours cannot
degrade the platform.
Capabilities that can be layered on the egress path, depending on your security and
compliance requirements:
3. Isolation inside the platform
Model 4 reads as the self-hosted column for infrastructure and the private-tenant column for
the platform: the cluster, network and compute are yours, while the isolation the platform
itself enforces is what Galtea runs in a private tenant.
On logical isolation in the shared models. Cross-organization data access is not a
permission that exists and then gets denied; it is absent from the data model. Every query
is bound to the caller’s organization by the API before it reaches the database. Signed URLs
for object storage are minted per request, short-lived and scoped to a single object.
4. Private network access (private tenant)
A private tenant can be configured with no public exposure at all. The dashboard and API are then reachable only through an encrypted VPN built on WireGuard, using NetBird as the overlay network. Properties that answer the usual security questions:- No inbound firewall rule on your side. Every connection to the control plane is outbound from your peer over standard HTTPS 443. This works through strict corporate firewalls.
- The control plane never sees your traffic. It coordinates identity, keys and access policies. Application traffic flows peer to peer over WireGuard.
- The relay cannot read anything. When no direct peer-to-peer path exists, the still encrypted tunnel rides a relay, which forwards packets it cannot decrypt.
- Identity-based access. Every peer authenticates against the identity provider before joining. Access policies are expressed over groups of peers, for example “analysts may reach the dashboard and API, and nothing else”. Removing a user in your directory removes their VPN access.
- Only advertised routes are reachable. Databases and internal services are not advertised and stay unreachable even for a connected peer.
- The tunnel works in both directions. Inbound, your users reach the dashboard and API. Outbound, the platform reaches your AI product endpoint through the same mesh, using a route your side advertises. A fully private setup therefore keeps both directions off the public internet: nothing about the platform is published, and nothing about your product has to be.
- Self-hosted control plane. The VPN control plane runs inside Galtea’s own infrastructure and is dedicated to private-tenant connectivity. It is not a third-party SaaS holding your network metadata.
5. Identity and access control
6. Data protection
Customer-managed keys, if you need them
A private tenant already gets keys of its own. Going further, so that you control the key material, is supported for the services that offer it, with two things to decide up front. Decide it before the tenant is built. The encryption key of a managed database or a disk volume is fixed when that resource is created. Adding customer-managed keys to a tenant that is already running is a snapshot-and-restore migration with downtime, not a setting Galtea flips. Raised during provisioning, it is configuration. Decide whose account holds the key. Two very different arrangements:
The second one is what a strict “hold your own key” requirement means, and it is offered, but
the availability coupling is real and belongs in the contract rather than in a diagram.
Two behaviors run counter to what people expect. Rotating a key does not re-encrypt data
already written, it applies to new writes. Backups inherit the key of the resource they came
from, so a restore needs that key to be reachable, including in a different account for disaster
recovery.
7. What the software sends home
Two channels get asked about in every review, and both have a short answer. Telemetry: none. A self-hosted install runs with no outbound connection to Galtea at all once installed. Tracing is off by default and, if you enable it, points at a collector inside your own cluster; third-party library telemetry is explicitly opted out. This is verifiable in the package you receive, not only a statement on this page: grep the values files for outbound hostnames before you install, and the registry endpoint is the only Galtea-side address in them. The full claim, item by item, is in Model 5: Self-hosted. Error forwarding: opt-in and off by default. You can choose to forward application-level and evaluation-level error events to a Galtea support Slack channel. What is sent: service name, error type and message, and correlation identifiers. What is never sent: your test data, prompts, model outputs and evaluation results. The channel carries failure signals, not payloads, and turning it off is removing the webhook URL from your values. Detail in Observability and operations.8. Galtea support access
This is the question every security review asks. The controls behind these answers, including how access is granted, reviewed and revoked, are published in the trust center linked in Certifications, policies and subprocessors below.
Model 4 reads as the self-hosted column: the cluster is yours, and Galtea’s access is limited
to the scoped, revocable credentials you issue for the platform operation described in
model 4.
Audit logs exist, covering administrative actions and access to production systems. They
are an internal control: the Galtea security and platform teams use them for review and
investigation, and they are not exposed to customers, in any deployment model. So treat
them as evidence that access is accountable, not as a feed you can query. If your compliance
framework requires customer-visible audit records, raise it early and Galtea scopes it with you as
part of the deployment. The access-control and logging policies behind this are in the trust center, linked in
Certifications, policies and subprocessors below.
9. Reporting a vulnerability
Report suspected vulnerabilities to your Galtea contact or to the security address in your contract. Penetration testing is part of Galtea’s annual security audit cycle, which runs under the ISO 27001 programme. Testing that you want to run yourself is possible but must be scheduled with Galtea first: do not test against the shared SaaS platform without written authorization, since it is multi-tenant and your traffic is indistinguishable from an attack on other customers. Against a private tenant or your own self-hosted install there is no such constraint beyond agreeing a window.10. Certifications, policies and subprocessors
Galtea is ISO 27001 certified. The certificate, its scope, the full policy set and the subprocessor list are published and kept current in the trust center, https://trust.galtea.ai, without an NDA. Beyond naming the certification, these pages do not copy the trust center: a certification status, an audit date or a control description reproduced into a document goes stale the moment it changes, and the customer is then holding a file that contradicts the live source. So for certification scope, control descriptions, data-processing terms and subprocessors, use the trust center; for how the platform is deployed and what crosses which boundary, use these pages. Where a section here touches a policy, it names the policy to look for there rather than restating it. The ones these pages lean on:
If you need a signed data-processing agreement, or a report under NDA, ask your Galtea contact
rather than inferring the answer from these pages.