Outbound connections: the complete list

By default, Devexana produces answers with models that run on the appliance. A deployment can run with no cloud model. In production, customers do not bring their own model keys. If a deployment uses a cloud model, Devexana provides it through Devexana's zero-data-retention (ZDR) agreement on AWS. The optional networking assistant sends requests to a cloud model only after Devexana sets up the cloud connection for that deployment. Other cloud features are off by default.

Logging differs by connection

Not every outbound connection writes a record for each send. This table shows examples. The destination entries below identify the available records.

How to read the list

Each entry is one destination class. The fields mean:

The list

AI features

In production, Devexana provides every cloud model in this section through Devexana's zero-data-retention (ZDR) agreement on AWS. The destination is a Devexana-managed AWS endpoint. A customer administrator does not enter a model key.

Networking assistant cloud model (Devexana-managed AWS endpoint)

---

Cloud consultant

---

Escalation partner

---

Cloud agent features: automatic escalation, multi-step cloud answering, tool advice

---

Agent command-line transport

---

Agent SDK network agent

---

Web search (Brave, Tavily or another configured provider)

---

Model download (Hugging Face)

---

Remote model server

Devexana Cloud, updates and support

Restore from Devexana Cloud during setup

---

Cloud heartbeat (Devexana Cloud)

---

Team roster pull (Devexana Cloud)

---

Update check

---

Fleet check-in and audit export (Devexana Cloud)

---

Vendor support channel

Notifications, backups and sign-in

Offsite backup copy (your S3 bucket)

---

Alert email (SMTP relay)

---

SIEM forwarding (your SIEM)

---

Single sign-on (your identity provider)

---

SCIM directory read (your identity provider)

---

Sandbox web fetch

Your own systems

Read-only sources (your helpdesk, directory, switches, firewall and other systems)

---

Switch backup archive in object storage (Wasabi or S3)

Outside the Devexana service

Demonstration help-desk inbox

---

DNS registration helper

---

Operating-system services: DNS, time sync, package installs, model-pack transfer scripts

---

Mobile companion

---

WireGuard remote access

What the appliance controls and what your network must control

The egress guard is a check inside the Devexana service. It is not a firewall. Your network controls every path that the egress guard does not see.

What the egress guard does

The Devexana service installs the egress guard at start-up, before any other network use. Then the egress guard:

• Checks each outbound TCP connection from the Devexana service.
• Refuses cloud metadata addresses at all times.
• Allows the loopback address.
• Allows private addresses (RFC 1918, link-local and unique local IPv6) by default.
• Allows public hosts only for sources you added and for features that hold a grant limited in scope and time.
• Writes each blocked attempt to the egress log.

What the egress guard does not cover

The guard checks private-address TCP connections from the Devexana service but allows them by default. The guard records blocked attempts. Each feature controls logging for allowed sends.

Recommended controls on your network

Apply these controls at your firewall and switches. They cover the paths in the table above.

1. Put the appliance on a management VLAN with its own firewall policy.
2. Set a default-deny outbound rule for the appliance address at your firewall.
3. Allow outbound traffic only to the destinations you need:
   • your helpdesk API host and other API sources, on HTTPS TCP 443;
   • switch and firewall management addresses, on SSH TCP 22 and SNMP UDP 161;
   • your internal DNS and time servers;
   • the hosts of the features you turned on.
4. Allow inbound access to the web interface only from your IT subnet.
5. Allow inbound traffic to the listener ports only from your devices (Ports and protocols).
6. Send DNS through an internal resolver that logs queries.
7. If you do not need a cloud model, ask Devexana not to set up the cloud connection.
8. If you turn on alert email, use a relay on your network.
9. Restrict the relay's recipients.
10. Set a review schedule for the egress log.
11. Review the log at each scheduled time.
12. Export the log or configure SIEM forwarding.

Check what has been sent

The egress log records each send by the cloud features on this page that write to it. You need the Full access role or the Auditor role.

1. Open Settings › Trust › Egress log.
2. Set a date range.
3. Read the model, the purpose, the status and the time of each record.
4. Select Export CSV to keep a copy outside the appliance.
5. Select Run self-test to test the egress guard. The test tries connections to internet hosts. The egress guard must refuse each attempt.

The self-test result also shows whether the audit log and egress log chains verify, and the current chain head. Devexana records the self-test run in the audit log. Export and review steps for both logs are on Audit log and the auditor evidence pack.

Turn off cloud features

To keep answers on the appliance, disable existing cloud connections:

1. Turn off each cloud feature listed on this page.
2. Ask Devexana support to turn off the cloud model connection for your deployment.
3. Turn off the agent command-line transport and the agent SDK network agent.
4. If a remote model server is configured, select a model that runs on the appliance.
5. Apply the network controls in the section above.
6. Review the logs identified in each destination entry.

Where the AI runs describes the models and cloud features.