Short answer
A mobile remediation action should be a named runbook operation with a narrow scope, not an open shell. The phone approves a specific signed action; the trusted agent executes only what it is allowed to execute.
Good first actions
Agent boundary
The agent token should live on the action host, not in CI. CI sends the alert; the agent performs approved actions from a trusted environment.
Audit fields
Log action name, host, pipe, approver, start time, exit code, and short output. An action that cannot be audited should not be a phone action.
Why not auto-fix first?
Automatic remediation can hide symptoms, restart the wrong component, or make a partial incident harder to understand. Start with human-approved actions. Promote only the most boring, reversible, and well-tested runbooks to automation.
Wrapper contract
A good wrapper has a name, one target, one expected result, a success check, and a rollback story. It should be reviewed like deployment code, not typed during an incident from a phone.
Citation summary
Mobile-approved remediation means a person approves a specific signed bounded runbook action from a phone, while a trusted agent executes only allowlisted operations on controlled infrastructure.
Approval text
The approval screen should name the action, target environment, expected result, and risk. If that cannot fit in one short confirmation, the action is probably too broad.