Data Residency & VPC Isolation

InfraSage is built for environments where telemetry data cannot leave your infrastructure perimeter. This page covers the architecture, the data flows, and the compliance posture.

The core guarantee

No telemetry data sent to InfraSage, Inc.

When you deploy InfraSage self-hosted:

• All metrics, logs, traces, events, and profiles stay inside your VPC
• Storage, streaming and all processing run on your infrastructure
• The only outbound calls are to your AI provider, for root cause analysis, the copilot and log-pattern summaries, and you can replace that with a model you host yourself (see below)
• InfraSage, Inc. has no access to your telemetry data

Data flow map

Your VPC / Data Center
┌──────────────────────────────────────────────────────────────────┐
│                                                                  │
│  Your services  ──►  Ingestion Gateway  ──►  Message bus         │
│                                                 │                 │
│                                                ▼                 │
│                                     Telemetry Operator           │
│                                                │                 │
│                                                ▼                 │
│                                           Storage                │
│                                                │                 │
│                                                ▼                 │
│                                         AIops Engine             │
│                                                │                 │
│                           ┌────────────────────┘                 │
│                           │                                      │
│                   RCA triggered?                                 │
│                           │                                      │
│                    Yes ──►│──► AI provider (optional)            │
│                           │    (the evidence for this            │
│                           │     analysis, redacted)              │
│                    No ────┘                                      │
│                                                                  │
│  Admin UI ◄── AIops Engine (internal)                           │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Everything inside the box is your infrastructure.

What leaves your environment

Your AI provider (optional)

Root cause analysis, the copilot and summaries of new log patterns call an AI model. What the model receives is the evidence for the question at hand, and nothing wider:

• Service, metric and dependency names (e.g. payment-service, error_rate, checkout → payment)
• Summaries of the metrics involved around the time of the trouble
• Recent changes: deploys, config changes, feature flags
• Excerpts of the affected services' logs and traces for that time window, a few dozen lines at most per query
• For the copilot, your question and the conversation so far

Secrets and personal data are masked before anything is sent: card numbers, IBANs, email addresses, phone numbers, US SSNs, keys and tokens (REDACT_PROMPTS_ENABLED, on by default). See data redaction for exactly what is matched, and its limits.

The provider is your choice: Anthropic, Google Gemini, or Amazon Bedrock in your own AWS account. See sub-processors.

Running with no AI provider

Leave the provider key unset. Detection, alerting, incident correlation, blast radius and evidence gathering all run as normal. Root cause analysis falls back to a rule-based analysis, labeled analysis_mode: fallback_rules in the API and bannered in the console, and the copilot is unavailable.

Using a model you host

To keep AI reasoning inside your environment:

LLM_PROVIDER=local
LOCAL_LLM_ENDPOINT=http://ollama.internal:11434/v1
LOCAL_LLM_MODEL=llama3.1:70b
LOCAL_LLM_API_KEY=            # if your endpoint needs one

This works with any OpenAI-compatible API: Ollama, vLLM, LM Studio, or an Azure OpenAI private endpoint. Analysis quality depends on the model you run.

Compliance posture

GDPR (EU)

InfraSage self-hosted satisfies GDPR's data transfer restrictions (Articles 44-49) by keeping all personal data processing within the EU. There is no cross-border transfer to a third-country processor for telemetry data.

Customer obligations:

• Deploy InfraSage in an EU-region VPC (e.g., eu-west-1, eu-central-1)
• Bind ClickHouse persistent volumes to EU-region storage
• Review log content for incidental PII; use the log sampling and field exclusion config to strip PII before ingestion

Relevant config:

# Strip fields from log payloads before storage
LOG_FIELD_EXCLUSIONS=user_id,email,ip_address,card_number

BaFin / DORA (Germany / EU financial services)

DORA (Digital Operational Resilience Act) and BaFin BAIT require that ICT third-party service providers either store data in the EU or provide contractual guarantees of equivalent protection.

InfraSage self-hosted removes InfraSage, Inc. from the ICT third-party chain entirely: you operate the software, you own the data. BaFin's concentration risk provisions around cloud providers do not apply to self-hosted software you control.

RBI Data Localization (India)

RBI's guidelines on storage of payment system data require that data related to payment transactions be stored only in India.

With InfraSage deployed in an India-region VPC (e.g., ap-south-1), all telemetry including payment service metrics stays within India's borders. InfraSage has no servers or data pipeline outside your deployment region.

HIPAA (US healthcare)

HIPAA's Security Rule requires that PHI be protected at rest and in transit. With InfraSage self-hosted:

• No PHI transits to a third-party SaaS vendor
• ClickHouse storage encryption is configurable at rest
• mTLS is available for all internal service communication
• Audit logs of all API access are written to ClickHouse

No BAA is required with InfraSage, Inc. InfraSage, Inc. never processes your PHI: the software runs in your environment.

Network architecture recommendations

No inbound exposure required

InfraSage does not require any inbound internet access. All components communicate over internal cluster networking. The Admin UI can be served internally and accessed via VPN or bastion.

Outbound egress (optional)

Destination	Purpose	Required
Your AI provider (e.g. api.anthropic.com:443)	Root cause analysis, copilot, log-pattern summaries	Optional
PagerDuty API	Incident creation	Optional
Slack API	Alert notifications	Optional
Jira API	Ticket creation	Optional

All integration endpoints are configurable. Use a model you host (or none) and disable unused integrations for zero required egress.

Recommended network policy (Kubernetes)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: infrasage-egress
  namespace: infrasage
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    # Allow internal cluster DNS
    - ports:
        - port: 53
          protocol: UDP
    # Allow internal cluster communication
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: infrasage
    # Allow your AI provider (remove if you host the model or use none)
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
      ports:
        - port: 443
          protocol: TCP

Encryption

In transit

All inter-service communication within InfraSage supports mTLS. Configure via:

MTLS_ENABLED=true
MTLS_CA_CERT=/etc/certs/ca.crt
MTLS_SERVER_CERT=/etc/certs/server.crt
MTLS_SERVER_KEY=/etc/certs/server.key

At rest

Self-hosted, encrypt InfraSage's storage at rest with:

• Filesystem-level encryption (recommended: your cloud provider's disk encryption)
• ClickHouse's per-column encryption codecs, for the most sensitive columns

Ask us which columns hold free text (log bodies, attributes) if you want to encrypt those specifically.

Audit logging

Every API call to InfraSage is recorded in the audit log: who, which tenant, what action on which resource, from which IP, and the result. Read it on the console's Audit Log page or through the API:

curl "$INFRASAGE_URL/api/v1/audit-log" -H "Authorization: Bearer $ADMIN_JWT"

Audit records can't be edited or deleted through InfraSage. They are kept for 365 days.

Penetration testing & security reviews

InfraSage is open to customer-initiated penetration testing against self-hosted deployments. Contact [email protected] if you need architecture documentation for a third-party security review or vendor assessment.