Audit & tighten egress
Read the engine's live egress policy, tighten it with deployment-mode settings, generate a 24-hour privacy report, and audit the redacted egress decision log.
Algenta classifies every outbound network request before it is made and records a redacted decision for it. Three admin endpoints let you see and prove that behavior: read the egress policy the engine resolved from its configuration, generate a privacy report that summarizes the last 24 hours, and page through the egress log of individual allow/deny decisions. Together they answer "what is this deployment allowed to reach, and what has it actually reached?"
The policy itself is set through runtime configuration, so tightening it is a configuration change (a deployment mode plus a few overrides), not an API write. These endpoints are how you confirm the change took effect.
Read, tighten, and prove the policy
Read the resolved egress policy
Start from the truth the engine is running with. The policy reflects the active deployment mode and every derived default.
curl -sS "https://api.algenta.ai/v1/admin/egress-policy" \
-H "Authorization: Bearer $ALGENTA_API_KEY"The response includes the deployment_mode, the raw switches (disable_cloud, disable_telemetry, telemetry_mode, metering_mode, allow_outbound_network, require_local_license, control_plane_url, egress_allowlist), and the derived, human-readable booleans:
{
"deployment_mode": "self_hosted",
"disable_cloud": true,
"disable_telemetry": true,
"telemetry_mode": "local_audit",
"metering_mode": "local_audit",
"allow_outbound_network": false,
"require_local_license": false,
"control_plane_url": "",
"egress_allowlist": ["warehouse.internal", "*.db.example.com"],
"algenta_cloud_enabled": false,
"vendor_telemetry_enabled": false,
"customer_connector_egress_enabled": true,
"undeclared_public_egress_allowed": false,
"mandatory_heartbeat_enabled": false,
"metering_flush_enabled": false
}The privacy_registry object and the algenta_owned_hosts / vendor_telemetry_hosts / private_host_suffixes lists in the same response tell you exactly which hosts each egress class covers.
Tighten it through configuration
If the policy is looser than you want, change it on the engine host and restart. The single highest-leverage setting is the deployment mode: self_hosted and air_gapped disable cloud and telemetry and refuse outbound network by default. Layer overrides on top for a specific connector.
export ALGENTA_DEPLOYMENT_MODE=self_hosted
export ALGENTA_DISABLE_TELEMETRY=1
# Comma-separated; supports exact host, host:port, and *.suffix wildcards.
export ALGENTA_EGRESS_ALLOWLIST="warehouse.internal,*.db.example.com,minio.local:9000"Identity-provider key discovery is auto-permitted. When Microsoft Entra sign-in is configured (ALGENTA_ENTRA_TENANT_ID and ALGENTA_ENTRA_AUDIENCE are set), the gateway automatically allows egress to Microsoft's Entra key-discovery (JWKS) endpoint so it can verify access-token signatures. This is allowed by construction — even under a fail-closed profile and without a manual ALGENTA_EGRESS_ALLOWLIST entry — so an allowed outbound decision to that Microsoft host in the egress log is expected, not a policy gap.
See Deployment modes & privacy for how each mode derives its defaults and Configuration reference for every variable.
Generate a privacy report
The report rolls up the egress decisions from the last 24 hours alongside the current policy — a one-call answer for a compliance or audit review.
curl -sS "https://api.algenta.ai/v1/admin/privacy-report" \
-H "Authorization: Bearer $ALGENTA_API_KEY"{
"deployment_mode": "self_hosted",
"algenta_cloud_enabled": false,
"vendor_telemetry_enabled": false,
"customer_connector_egress_enabled": true,
"undeclared_public_egress_allowed": false,
"local_license_required": false,
"local_license_active": false,
"mandatory_heartbeat_enabled": false,
"metering_flush_enabled": false,
"telemetry_mode": "local_audit",
"metering_mode": "local_audit",
"algenta_owned_egress_count_24h": 0,
"blocked_egress_attempt_count_24h": 3,
"last_outbound_request_at": "2026-07-05T09:12:44Z",
"last_algenta_owned_egress_at": null
}For a locked-down deployment you want algenta_cloud_enabled: false and algenta_owned_egress_count_24h: 0 — proof the engine has not reached Algenta Cloud.
Audit the egress log
Drill into the individual decisions behind those counts. Each entry is redacted — the destination host is hashed and its display value is coarsened — so the log is safe to export.
curl -sS "https://api.algenta.ai/v1/admin/egress-log?page=1&limit=25" \
-H "Authorization: Bearer $ALGENTA_API_KEY"{
"entries": [
{
"surface": "llm-provider",
"egress_class": "undeclared_public",
"destination_host_hash": "9f2c...e1",
"destination_host_redacted": "*.example.com",
"decision": "deny",
"reason": "undeclared_public_egress_disabled",
"timestamp": "2026-07-05T09:12:44Z",
"deployment_mode": "self_hosted",
"service_name": "api-server",
"request_id": "req_01H..."
}
],
"total": 3,
"page": 1,
"limit": 25,
"pages": 1
}page defaults to 1 and limit to 25 (max 100). egress_class is one of algenta_cloud, vendor_telemetry, customer_connector, operator_service, or undeclared_public; decision is allow or deny with a machine-readable reason such as destination_not_allowlisted or destination_allowlisted.
Next steps
Last updated
Was this helpful?