Pharaoh PHARAOH

ENDPOINT READINESS & LIVE VIEW

Know when an endpoint is safe to act on.

Tickets and alerts are rarely enough context for remote action. Pharaoh helps technicians confirm the machine, read freshness, spot stale or missing evidence, and open live work only when the endpoint is ready.

  • Identity matched Confirm the endpoint behind the ticket before starting work.
  • Freshness checked Last Seen, diagnostics, Sentinel, and screen age stay visible.
  • Action gated Open live work only when the evidence supports it.
Scope a Pilot See endpoint docs

WHERE IT HELPS

Built for the moment before remote work becomes action.

Endpoint Readiness & Live View helps IT teams reduce avoidable change risk by making the readiness question explicit: is this the right machine, is the evidence fresh, and is live work justified right now?

In plain English This helps IT avoid acting on the wrong computer or on stale endpoint evidence before a fix starts.

Use this when

  • A user, client, alert, or ticket points to a machine and you need to verify the endpoint before anyone sends a command.
  • An endpoint looks offline, stale, duplicated, or recently reimaged and you need to know whether the evidence can be trusted.
  • You need a live screen, transport state, approval posture, and session record before asking Pharaoh to investigate or repair anything.

Readiness model

Pharaoh separates endpoint observation from endpoint action so technicians can slow down when evidence is stale, incomplete, or tied to the wrong machine.

No inferred freshness
Pharaoh shows Last Seen, diagnostics, Sentinel status, and live screen age instead of implying the endpoint is current.
Static before live
Inventory and endpoint detail stay separate from live session work so observation does not blur into action.
Session with controls
When live work is justified, the handoff includes approval context, history, Send, Stop, and Close controls.

HOW IT WORKS

Match, check, then decide.

Pharaoh keeps fleet inventory, endpoint detail, and live sessions as explicit stages so technicians can prove the endpoint is ready before they hand work to AI or a remote operator.

  1. 01

    Match

    Start with a ticket, alert, user report, hostname, or computer ID and narrow the fleet to the endpoint that actually owns the problem.

    Ticket intake / identity
  2. 02

    Check

    Read identity, Last Seen, diagnostics, Sentinel state, and live-context freshness before treating the endpoint as safe for remote work.

    Freshness / diagnostics
  3. 03

    Decide

    Open a guarded live session, wait for fresher evidence, escalate a stale agent, or route the issue outside Pharaoh with a clear reason.

    Go/no-go / session

READINESS TRIAGE

Turn a vague report into a verified endpoint

Endpoint work often starts with imperfect evidence: a hostname in a ticket, a user report, an alert, or a similarly named machine. Pharaoh keeps the fleet list searchable and filterable so technicians can confirm the target before they burn time on the wrong device.

  • Search by hostname, computer ID, or OS hint from the ticket
  • Filter by operating system and sort by Last Seen when several machines look similar
  • Use empty states to broaden the query instead of guessing at a near match
  • Connect a computer from the same area when the intended endpoint is not enrolled yet
Filtered endpoint inventory showing an admin narrowing the list before opening a machine

FRESHNESS CHECK

See what evidence is current, stale, or missing

The endpoint detail page is the readiness checkpoint. It shows the machine identity, agent version, Last Seen, Sentinel context, and domain-specific inventory so teams can separate a normal offline laptop from stale collection, partial diagnostics, or a broken live path.

  • Header confirms hostname, Computer ID, OS, architecture, agent version, and Last Seen
  • Diagnostics make collection freshness and domain-level errors visible
  • Sentinel context shows latest health-check status, last run, rules, and escalations
  • Open Sessions remains a deliberate handoff after static evidence has been checked
Endpoint details page with identity, Sentinel context, detail tabs, and the Open Sessions handoff

LIVE GO/NO-GO

Act only when live context can support the work

Live view is useful because it tells the truth about whether the session has enough current context to trust. The workspace keeps screen freshness, transport state, approval posture, session history, and controls together so a technician can act, wait, or stop with the evidence in front of them.

  • Latest screen and transport badges show whether live evidence is fresh or degraded
  • Stale frames and missing transports are called out before a request is sent
  • Approval state, session history, Send, Stop, and Close controls share the same workspace
  • Recent-session recovery preserves the record when work needs a handoff
Dark endpoint session workspace showing live endpoint intelligence, approval posture, session history, and active request controls

Identity first

Technicians confirm the endpoint behind the ticket before opening a session or sending work.

Freshness is visible

Old Last Seen values, stale frames, failed collectors, and missing live transport are surfaced explicitly.

Go/no-go handoff

Live work starts only after the session shows enough current context, approval posture, and controls.

EVALUATE PHARAOH

Scope a governed remediation pilot.

Review the product, active controls, security review questions, integration priorities, and deployment fit across your internal environment or managed client fleet.