Give the Agent One Key at a Time

The signal this week

PromptArmor demonstrated a GitHub Copilot CLI case where an instruction in a README led to a shell command running through an auto-approved path without another user prompt. The disclosed command-parsing flaw is specific to macOS. PromptArmor reports its February 25 disclosure and GitHub's response. The public page doesn't establish how common this is in deployments or show a customer incident.

Microsoft's October 7 Windows announcement describes agents taking actions on behalf of users with permission. That's vendor product direction, not a deployment result for a small business. It still makes the line between recommendation and action an operating question now rather than later.

Two other sources point the same way. Stack Overflow describes a production design that separates an agent's proposed decision from a tested component that applies the change after checks and required approval. Treat that as implementation guidance, not proof of safety or return. GitHub documents approval controls and sandbox options for Copilot CLI, and current documentation may differ from the version PromptArmor tested.

The sources support action-level controls, explicit approval and separated state changes. They don't establish an incident rate, a universal safe configuration, an SMB savings rate or a threshold for unattended execution.

Govern the action, not the agent

The useful unit of governance is the action. Access to a ticket is different from permission to close it. Drafting a response is different from sending it. Recommending a restart is different from changing production.

Broad labels such as "agent enabled" or "human in the loop" hide the decision that matters. Write down the exact action, the data boundary, the approval point and the rollback. Then collect local evidence before expanding authority.

Climb the One Action Permission Ladder

Four levels. An action moves up one rung at a time, and only on evidence.

READ. The agent uses only approved data for the named task and makes no system change. The owner names permitted sources and prohibited data.

RECOMMEND. The agent proposes one action and explains the basis. A person still decides and acts. The owner records the recommendation, the human decision and the difference.

PREPARE. The agent drafts the command, message or change set. A person verifies and submits it. The owner confirms identity, scope, destination and rollback.

EXECUTE. The agent performs one exact, reversible action inside the approved boundary. The owner requires logs, stop rules, a named approver and a review date.

This is a proposed SML operating framework. It isn't an externally validated safety methodology.

The counterargument that matters

A small team can spend more time documenting and checking an action than the action itself takes. That's a valid reason to keep the action human-led or leave the agent in recommendation mode. Existing vendor controls may already block the specific path shown in a research demonstration.

Choose a frequent, low-consequence action only when the review is cheap enough to produce useful evidence. If the boundary or rollback is unclear, don't grant execution authority.

Fill in one authority card

Use one Agent Action Authority Card for one action, completed with the person who does the work today. Don't use a single card to authorize a group of related actions. The card records the exact action and system, the business and technical owners, allowed and prohibited data, the approval point and approver, the impact and rollback, where the audit record lives and the trial and decision standard.

A worked example

This is the illustrative service-desk scenario, not a client result. The action under review is proposing a restart of a noncritical service. The agent stays in recommendation mode while the current owner does the work.

The alert arrives. The agent recommends a restart. The operator holds because a scheduled vendor change is underway. In the shadow log that case gets a row with the recommendation, the human action, the reason they differ, verification minutes, exception-handling minutes and whether the data boundary and rollback stayed intact.

That one row is the point. The recommendation wasn't wrong in isolation. The agent lacked context the operator had. Under the ladder, that's a case for staying at RECOMMEND until the exception can be detected before execution.

Run the shadow test

Choose one frequent, reversible action, such as classifying an inbound service request or proposing a restart of a noncritical service. The owner sets the review period and the acceptable mismatch threshold before the trial starts.

Passing means every case is accounted for, the pre-agreed decision standard is met, no prohibited data is used, required checks remain intact and the rollback path is confirmed.

Stop if the data boundary is breached, an action can't be reversed as recorded, the log is missing or verification costs more time than the original step.

Two local measures keep the result honest. Agreement rate is matching recommendations divided by reviewed cases. Net minutes per case is prior human minutes minus verification minutes minus exception-handling minutes. Returned time is capacity. It becomes cash savings only if an actual expense changes.

Five prompts to run this week

Use these in sequence on one workflow, with data your business permits in the chosen tool. Each prompt drives one decision.

I will describe one workflow and the current human steps. Identify the single business action being considered for an AI agent. Separate reading, recommending, preparing and executing. Name the system state that would change. List related actions that must remain outside scope. Do not assume permission from the agent's general role.

For the confirmed action, draft an authority boundary. Include allowed inputs, prohibited data, agent identity, required approval, impact if wrong, rollback steps, audit location and stop rules. Mark every missing fact as OWNER INPUT REQUIRED. Do not recommend unattended execution.

I will provide consecutive cases from the approved trial. Create one row per case. Record the agent recommendation, human action, reason for any difference, verification minutes, exception minutes and boundary status. Do not hide unresolved cases or infer missing decisions. Calculate agreement only from reviewed cases.

Using the completed shadow log, group differences by cause: missing context, prohibited data, ambiguous instruction, model error, human override, system failure or unclassified. Show verification and repair time for each group. Do not treat human agreement as proof that the action was correct.

I will provide the authority card, trial standard and completed shadow log. Compare the observed result with the pre-agreed standard. Report agreement rate, verification time, exception time, every boundary failure and missing evidence. Recommend continue shadow mode, keep human-led or allow the exact action with its existing controls. Do not generalize to other actions.

How to read the result

Ready for a bounded execution test when the action, data, approval, logs and rollback are explicit, the pre-agreed decision standard is met and exceptions can be detected before harm.

Extend shadow mode when the action is bounded but the sample, comparison or exception record isn't yet strong enough for an execution decision.

Keep human-led when the action depends on context the agent can't reliably access, verification erases the capacity gain, the data boundary fails or the consequence is too high.

The result should end with one named owner, one decision, the controls that remain in force and a review date. A successful action doesn't authorize the next one.

What to do this week

A fair limit on all this

PromptArmor's case is a researcher-reported demonstration, not an incident-rate study, and GitHub's current controls may differ from the version tested. Microsoft's announcement is product direction. The Stack Overflow piece is expert design guidance, not a controlled study. The LogicMonitor interview was carried from publisher show notes only. No source establishes a universal permission threshold, incident frequency or customer ROI. The service-desk scenario, permission ladder, trial structure and pass conditions are SML recommendations, not measured client results. A small trial supports a local decision. It doesn't prove general safety or savings.