airmshSecurity
Airmsh security: identities, permissions, and limits.
An encrypted connection is the transport. Access still depends on an authenticated device and a grant for the specific service or agent.
For security reviewers, administrators, and developers deciding what to expose inside an Airmsh network.
Try a scoped EndpointQuick answers
Is an encrypted tunnel by itself a zero trust control?
No. For private resources, Airmsh also checks device identity and the grant for the selected service. Agent requests add device-and-tag, action, and resource checks. Read the scoped-access workflow.
Can the relay read private tunnel traffic?
The relay forwards encrypted tunnel datagrams and does not receive the tunnel private key or plaintext private traffic. A backend HTTP service may still need its own login and HTTPS configuration.
Identity and authorization
Each device has an identity key. The control service manages organization membership, registered devices, and signed resource policy. For private resources, the gateway matches the signed policy to the source device and its tunnel identity. A denied or unknown source does not receive a usable service route.
Agent requests add a separate device-and-agent-tag route, action and resource checks, and a destination-side signing-key check. The endpoint address never stands in for identity. Owner-managed policies can further restrict a caller, action, or resource.
Transport and secrets
Airmsh uses an encrypted WireGuard-compatible tunnel between peers. It prefers direct connectivity and can use a relay to forward encrypted tunnel datagrams when direct reachability fails. The relay does not receive the tunnel private key or plaintext private traffic.
Database and MCP credentials belong on the destination device. Agent definitions use a local secret reference; remote SDK callers do not receive those credentials. A private HTTP service still needs its own authentication, and HTTPS still requires a trusted certificate on that service.
Revocation and records
Resource policies are short-lived and refreshed. Gateways close flows when revocation arrives or policy expires. A user can also revoke a temporary desktop Terminal/Files grant by stopping peer access or the tunnel.
The resource gateway emits signed metadata about a closed flow, such as decision and usage limits, without recording payloads or credentials. These events are bounded in memory; durable retention depends on how the operator collects service logs.
Illustrative workflow
What this looks like
If Alice is allowed to use one internal API and Bob is not, Alice receives a service route after policy validation. Bob’s attempted connection is denied. If Alice’s grant is removed, new access stops and an existing resource flow is closed when the gateway receives or expires the policy.
Limits to know
- Airmsh does not currently assert device-posture checks, SSO or SCIM enforcement, a compliance certification, or whole-network zero trust coverage.
- Terminal grants are intentionally broad for the signed-in OS user. Public links are separate and can expose the selected service to anyone holding the link unless access protection is configured.
- A compromised authorized device or an already copied file cannot be made safe by revoking a network route alone.
Next step