How local agent approvals survive remote desktop access

A local approval has one job: it tells a system that the person at the machine chose a specific action. Remote desktop software complicates that claim. Once another person can view the prompt, move the pointer, type into the session, or direct the person at the keyboard, a green button no longer tells you much about whose authority you received.

Teams often solve this with a broad rule such as “support staff must ask before taking control.” That is good etiquette and weak security. The decision that permits remote control and the decision that permits an agent to call an API, run an SSH command, or change a production setting are separate decisions. Treating the first as a proxy for the second creates untracked authority.

The useful rule is plain: remote access can help a person inspect and repair a machine, but it must not silently give the remote operator the ability to approve an agent's external actions. Put that rule into the remote-tool configuration, the approval design, the identity model, and the audit record. If one of those layers is missing, somebody will eventually click through a prompt during a support call and discover afterward that nobody can say who authorized it.

Remote presence changes what an approval means

An approval is trustworthy only when it identifies the decision maker, binds them to a meaningful request, and leaves enough evidence to review the decision later. A remote desktop session can weaken every part of that chain.

The remote operator may have direct pointer and keyboard control. They may be able to see an approval code, a one-time link, an API target, a command preview, or an error message that contains more information than the product team expected. They may have asked the local user to click something quickly, turning the local person into a rubber stamp. In an unattended remote-management session, the operator may not need the local user present at all.

Do not blur three facts that look similar in a log:

• A user allowed someone to view their screen.
• A user allowed someone to control their desktop.
• A user personally approved a specific external action.

Those facts carry different authority. The first should not grant the second. The second should not grant the third. A system that records only “approval granted” throws away the fact most likely to matter in an incident review.

This is not a theoretical distinction. Apple’s Remote Desktop documentation describes screen control as its most powerful capability and warns that it can enable unauthorized screen control or file deletion if assigned carelessly. Apple also separates observing a logged-in display from connecting to a separate virtual display. That separation is useful because the desktop that holds a developer’s active agent session should not double as the desktop an administrator uses for routine maintenance.

A remote session does not automatically make every approval invalid. A developer may be in a video call with a teammate who is only observing. A help desk worker may need to watch a user reproduce a problem. The right response is to define what the session can and cannot do rather than pretending every screen-sharing product has the same risk.

Classify remote tools by control, not by vendor

The name of the remote tool does not decide the policy. Its current capabilities do. One product can switch among view-only sharing, interactive control, file transfer, clipboard sync, background management, and session recording. A policy that says “Tool A is approved” gives people a false sense of precision.

Classify each session into one of four states:

1. View only. The other party can see the display but cannot send input.
2. Attended control. The other party can see and operate the logged-in desktop while a local user is present.
3. Unattended management. The other party can reach the device or an administrative account without a local user participating.
4. Unknown. The approval service cannot reliably determine the tool’s state or capabilities.

For agent approvals, use the state rather than a guessed identity. View-only sessions may allow ordinary, low-impact approvals if the request display does not expose secrets. Attended control should block approvals that create durable access, move data outside the organization, change production state, or spend money. Unattended management should never approve through the developer’s interactive session. Unknown must behave like attended control, not like view-only.

The popular alternative is a blanket exception for corporate remote-support software. It is popular because support teams need to fix machines quickly, and exceptions feel cheaper than designing a handoff. It is wrong because a trusted support product can still put an untrusted person, contractor, compromised support account, or screen recorder in control of the approval surface. Trust in the transport does not establish authority for the action.

Write the classification into a small policy document that people can apply during an incident. Keep the language operational:

Remote session state: attended control
Agent action class: production write
Decision: deny interactive approval
Allowed paths: end remote control, or invoke break-glass approval
Audit fields: remote state, support ticket, agent session ID, approver ID

That artifact avoids the usual hand-waving. It tells the developer what to do, tells the support worker why they cannot click through, and tells the reviewer what evidence should exist.

A click proves UI access, not local intent

A clickable prompt is suitable for routine friction. It is a poor proof of local intent when a remote party can drive the desktop.

Consider a common support failure. A developer has an autonomous coding agent open in a terminal. The agent needs to call an internal deployment API to read an environment setting. A support technician connects to investigate a separate issue with a build tool. While the technician controls the screen, the agent requests approval for an API call. The technician reads the destination, decides it looks normal, and clicks Allow. Later, the agent follows a malformed instruction and changes the setting instead of reading it.

Every person in that sequence may have acted in good faith. The developer gave support access. The technician believed they were fixing a local problem. The agent appeared to ask for permission. Yet the audit trail says only that an approval occurred. It cannot distinguish the developer’s authority from the technician’s desktop access.

The failure gets worse when approval cards omit enough detail to fit comfortably in a small dialog. “Allow deploy API” is not a decision. The person needs the method, destination, account or credential scope, and a bounded description of the operation. For SSH, they need the host and command. If a prompt cannot present that information in a way a human can understand, do not ask the human to approve it.

A good prompt should make a remote operator pause because it states the boundary they do not own. For example:

Approval blocked

This agent requested: POST https://deploy.example.internal/v1/releases
Credential: production-release-bot
Remote-control state: attended control

End remote control and retry, or use the documented emergency approval path.

The block must be a block. Avoid a “Continue anyway” button protected by an extra warning. That design turns a meaningful boundary into a speed bump and trains people to bypass it when a support call runs long.

Require an approval factor the controller cannot operate

For sensitive actions, the approver must provide something that a remote operator cannot produce through the shared desktop. This usually means a local hardware interaction, a separate trusted device, or an approval workflow outside the controlled session.

Local biometrics can help, but only if the system verifies the actual circumstance. Apple’s FaceTime remote-control documentation states that Touch ID is disabled while remote control is active. That is a sensible safeguard because a remote controller should not be able to turn a biometric prompt into a routine desktop click. Other tools and configurations may behave differently, so do not write a policy that assumes every biometric prompt remains local by magic.

Do not use a local password as the sensitive approval factor during remote control. The remote party may watch it being typed, capture it through input control, or persuade the user to enter it. A password is still useful for unlocking a session, but it does not restore independent approval when another person can operate or observe that session.

A separate-device approval can work if it gives the approver enough context and binds the decision to the original request. The phone notification should not say “Approve agent action?” It should repeat the action summary, target, credential identity or scope, agent session identifier, and expiry. It should also say why the local desktop approval was unavailable. That lets the person make a decision without relying on the remote operator’s interpretation.

Use a short expiry. An approval that remains usable after a support technician disconnects has become a bearer token with a friendly name. Bind the approval to one request or a small, explicit batch. Bind it to the agent process that made the request. Revoke it when that process exits, the screen locks, or the session changes state.

Sallyport keeps the vault gate absolute while locked and can require a per-call local approval for individual credentials. That model is useful here because a remote session should never turn one session-level consent into permission to reuse a sensitive credential indefinitely.

Separate support access from the developer’s working desktop

The cleanest design keeps the administrative session away from the desktop that contains the agent, its instructions, and its approval surface. This is less convenient than taking over the user’s exact screen, and it avoids a class of confusion that policy text cannot fix afterward.

Apple Remote Desktop documents two distinct modes: sharing the current display and connecting to a virtual display for the account used to authenticate. For routine administration, give the support worker a dedicated administrative account or virtual desktop where possible. They can inspect configuration, install approved updates, and collect diagnostics without seeing or controlling the developer’s current agent session.

That separation also reduces accidental data exposure. A remote controller who sees the developer’s display may see source code, customer data, terminals, notifications, password-manager prompts, or approval details. Even if they never intend to act as the approver, the session has already widened access beyond the ticket.

Do not solve this by running the agent as an administrator. Agent privileges should match the action it needs, not the convenience of the remote-support workflow. A standard user can request a tightly scoped external action. A separate administrative account can repair the machine. Those roles should meet only through a documented escalation, not through a shared desktop.

For teams that must provide unattended management, use it to maintain the device, not to continue work already running in a developer’s identity. If maintenance requires stopping an agent, stop it. If recovery requires an external call, have an identified owner approve it through a separate channel. The goal is not to keep every task alive through an interruption. The goal is to preserve who had authority at each point.

Remote-control detection must fail closed for sensitive actions

Detecting remote control is imperfect. Some products expose a local state, some do not. Browser-based sharing, virtual displays, hardware capture devices, and unusual accessibility setups can defeat a simple check. That uncertainty does not justify ignoring the condition.

Make the policy proportional to impact. For a read from a low-sensitivity development endpoint, you may allow a session approval if the remote state is unknown and the request exposes no secret material. For a production write, credential rotation, user export, firewall change, payment, or SSH command with administrator privileges, unknown means deny interactive approval.

A practical decision table looks like this:

The table should live beside the agent operating rules, not in a remote-support runbook that developers never read. Support staff need it too, because they will be the people facing the frustrated user who asks why a normally familiar approval has disappeared.

Never conceal the reason for a denial. Explain the state the system observed and state the available path. If the detector reports unknown, say unknown. Pretending certainty creates bad incident evidence and encourages people to find a bypass.

Emergency approval needs its own path

Some actions cannot wait for the remote session to end. A production outage can occur while a developer is traveling, a laptop is unstable, and an incident responder has remote access. That is the case for an emergency path, not an exception button on the ordinary prompt.

An emergency approval should require two independently identified roles: the person requesting the action and the person authorizing it. They must use separate authenticated channels. The approver should receive the exact request, expected effect, expiry, and agent identity. The system should issue a narrow authorization that can satisfy only that request or a defined command set for a short period.

Keep the support technician out of the authorization role unless their incident role explicitly grants it. They may execute a recovery procedure. They should not quietly become the developer’s delegate because they happened to hold the mouse.

Record the support ticket or incident identifier with the request. That is not bureaucracy for its own sake. It gives the later reviewer a way to compare the action log against the incident timeline and determine whether the emergency authority covered the work performed.

A break-glass flow also needs a revocation story. If the agent process restarts, the request content changes, or the incident commander closes the incident, discard the authorization. A reusable emergency exception will be reused for ordinary work, usually at the worst moment.

The audit record must preserve the contested facts

A tamper-evident log is useful only if it answers the questions a reviewer will ask. For remote approvals, “user clicked allow” is not enough.

Store the agent process identity, its code-signing authority where available, the session identifier, the action type, the target, the credential scope, and a representation of the request that a reviewer can understand. Store the remote session state at decision time, the detection source, the local user identity, and whether the decision used a local hardware factor, a separate device, or emergency approval.

For an SSH request, a concise record might look like this:

2026-07-22T16:43:10Z action.requested
agent_session=9c13b8
process_authority=Developer ID Application: Example Team
channel=ssh
host=build-prod-02.internal
command="systemctl restart worker"
credential=ops-deploy
remote_state=attended_control
result=blocked
reason=remote_control_requires_escalation

The date format is deliberate. Use an unambiguous timestamp with a time zone. Incident reviews go sideways when one person reads a local time and another reads UTC, especially when the remote operator sits elsewhere.

Capture state transitions too. “Remote control began,” “remote control ended,” and “screen locked” explain why a request received a different decision five minutes later. Do not claim you detected a remote session unless you can name the signal. If the source is an operating-system notification, say that. If the tool reported its own state, say that. If the state was unknown, log unknown.

Sallyport projects its session and activity journals from a write-blind, encrypted, hash-chained audit log, and its sp audit verify command can verify that chain offline over ciphertext. That is the kind of evidence worth preserving when a team needs to establish whether a blocked request stayed blocked or an approved action came from a known session.

Screen-sharing settings need deliberate defaults

The approval design cannot compensate for a machine configured to accept broad remote control. Review the computer’s remote-access settings with the same care used for external credentials.

Apple’s current Mac guidance distinguishes Screen Sharing from Remote Management and says they cannot both be enabled at once. It also allows access to all users or only selected users, and it offers a setting where anyone may request permission to control the screen. “Anyone may request” is reasonable only when the user understands that a request is not an approval to act on their behalf. Limit the accounts that can initiate sharing, and disable remote services that the team does not use.

For managed fleets, set these defaults:

• Disable unattended remote control for developer workstations unless a documented support need requires it.
• Restrict remote-management accounts to named administrators, preferably with a separate administrative identity.
• Disable file transfer, clipboard sync, and remote printing when a support task does not need them.
• End remote control when the screen locks, the support ticket closes, or a short inactivity limit passes.
• Require a new remote-control request after reconnecting instead of silently restoring control.

A screen-sharing banner is still worth having. It reminds the local user that the desktop is observable and gives them a way to end the session. It does not solve authority. The approval service must receive the remote state independently rather than trusting that somebody noticed the banner.

Train people to end control before they approve

The policy fails if it asks people to infer subtle security states under pressure. Give them one simple habit: before approving a sensitive agent action, end remote control. Viewing may continue if the request contains no sensitive material and the policy permits it. Control ends first.

Support scripts should include the same instruction. A technician who says “I need you to click Allow so I can finish this” is asking the user to make a security decision without enough context. The better script is: “I need control to fix the local issue. If the agent requests an external action, I will stop control and you can review it yourself, or we can use the incident approval path.”

Run a short exercise with the people who use agents and provide support. Start a real screen-sharing session, request a harmless external action, and confirm that the system blocks or changes the approval route exactly as the written policy says. Then inspect the record. If reviewers cannot tell who controlled the desktop, which agent requested the action, and why the system allowed or denied it, the design needs work.

Do not accept a remote desktop session as a vague background condition. It changes the person who can operate the machine. Your approval rules need to acknowledge that change before an agent sends the request, not after a production setting has already moved.