Conceptual scenario

Reach the build host from your working laptop.

Keep the development workstation where it is and work from an approved laptop elsewhere. Follow the private access plan, the application checks and what happens when access ends.

Explore products ↗

A worked planning example. Mira and the resources below are conceptual, not a customer case study or released installation instructions.

The working situation

Mira’s build workstation

Mira works from a laptop. The build workstation stays in the office. She needs its build dashboard and development service; neither needs a public URL for the rest of the internet.

fibmeshAccess GroupsIllustrative product model

Private path

Mira’s private build host

  1. Mira’s laptop
  2. Engineering group
  3. Build workstation
Source
Mira’s enrolled working device
Resource
Office build workstation
Application
Build dashboard login retained

An identity outside the engineering group has no grant.

Example configuration, not a connected account or release confirmation.

Resource plan: the private build host

Each resource has an owner and a boundary. Scroll sideways to compare all columns. With a keyboard, focus the table region and use the arrow keys.

Resource ownership
ResourceOwnerIntended boundary
Mira’s laptopMira, approved workspace memberSource identity
Build workstationDevelopment teamPrivate target
Build dashboardBuild administratorApplication login still required
Contractor laptopSeparate, unapproved identityNo grant in this example

01 / Approve

The connection decision

Assess Networks for the approved laptop-to-workstation path.

The workspace administrator controls the grant. Supported native executors validate backend policy and apply local configuration.

Permission
The approved engineering member can reach the selected private target. The contractor’s separate, unapproved identity has no grant.
Private name
A private name may identify the host where supported. Name resolution and permission are separate checks.
Application
The build dashboard’s login, roles and session permissions still apply after the network path is available.

02 / Use

Evidence to collect in an evaluation

Test the build tool, then test the boundary around it.

  1. Confirm both endpoints.

    Verify the supported release on the laptop and workstation, their enrolled workspace identities and the intended group membership.

  2. Reach the actual application.

    Check the local firewall and application port. Test Mira’s permitted connection and confirm that the dashboard still requires its own login.

  3. Try an identity without permission.

    An unapproved identity must not gain the same resource path. A successful connection from Mira’s laptop alone does not demonstrate that boundary.

03 / Diagnose

Diagnose the boundary before changing it.

If the result differs, inspect redacted policy and apply state, DNS and local conflicts before broadening permissions. No direct P2P path or platform-universal procedure is assumed.

The private name does not resolve.

Check the supported workspace DNS state and correct resource name separately from the access grant. Test the application listener and avoid substituting a public exposure as a quick fix.

The name resolves, but the build dashboard rejects the session.

A network path is not an application account. Inspect the build tool’s login, role and session permissions before broadening the workspace grant.

The contractor’s old laptop is offline.

Remove the intended membership and revoke a retired enrollment as appropriate. Record that fresh local state is unavailable; do not claim instantaneous deletion on an offline device.

04 / Withdraw

Removing the temporary path

End permission, then observe the result.

When access is no longer needed, remove the grant or membership and revoke a retired enrollment as appropriate. Verify the intended gateway state and observed resource reachability.

Record any offline resource that cannot yet report a fresh state. A requested withdrawal does not establish that an offline device has applied it.

Acceptance criteria

Three results worth recording.

Keep the permitted connection, denied identity and removal evidence together. This is a conceptual evaluation, not released installation instructions.

  • Permitted

    Permitted connection

    Mira can reach the selected build tool using the approved path.

  • Denied

    No unintended grant

    An identity outside the access group does not gain the same resource path.

  • Removed

    Clean removal

    Temporary access is removed and the resulting state is checked.

Read Networks for the mechanism and limits.

Explore Networks →