The relay makes a path
A relay helps compatible OmniTerm clients reach an enrolled machine across networks where a direct connection is unavailable or inappropriate. The enrolled agent establishes an outbound connection to the configured service, and the relay carries traffic between the participants.
In a native agent-relayed connection, the path is your device → relay → enrolled agent → approved destination. The agent and destination may be on the same machine.
This can avoid opening an inbound port for the agent. It does not automatically make every service on the network reachable, remove firewall policy, or replace authentication on the destination.
Connection checks happen in layers
- Admission to the route. The service checks the account or relay credentials and the applicable access policy. Managed services can also check usage allowances.
- Recognition of the agent. The client checks the enrolled agent's trusted identity rather than treating a relay address as proof of identity.
- Permission to use the agent. The connecting client proves it has the required authorization before an approved destination is opened.
- Authentication to the destination. SSH still verifies the destination host and authenticates the remote user. Other protocols have their own requirements.
These layers solve different problems. A valid relay token is not an SSH password. An account login does not unlock every vault. A familiar server name does not replace fingerprint verification.
Where encryption ends matters
For a native client-to-agent protected tunnel, the forwarding relay carries encrypted traffic rather than needing access to the terminal contents. The relay still participates in routing and can observe connection metadata. The client, agent environment and destination must remain trustworthy for the parts of the connection they handle.
A Gateway-hosted session is different. When a Gateway operates the remote protocol on your behalf, it is a trusted endpoint. Decrypted session data and credentials may be present there while in use. A secure browser-to-Gateway connection does not make the session secret from a compromised Gateway.
| Party | What to understand |
|---|---|
| Forwarding relay | Carries traffic and can observe routing information, connection timing and traffic volume. It also affects availability. |
| Your device | Receives usable session data and handles input. An unlocked or compromised device remains a risk. |
| Enrolled agent and destination | Enforce local access and handle the services they provide. Their administrators remain part of the relevant trust boundary. |
| Protocol-handling Gateway | Is trusted with the protocol data and credentials it handles; do not treat it as an opaque forwarding relay. |
Disconnection is not remote undo
Revocation can deny new access and end supported active connections. A network outage, unsupported route or unconfirmed result must not be interpreted as proof of immediate cutoff everywhere. Check the status of the actual action.
Ending access cannot retract output already seen or undo commands already executed. A detached remote process may continue after its connection ends. Verify remote state separately when stopping work is important.
Continue with managed versus self-hosted relay, transport selection, or the broader privacy and trust guide.