A Confirm Button Is Not a Coding-Agent Security Boundary

A coding agent requesting permission to modify a package does not inherently determine system security boundaries. Clicking "Approve" does not guarantee the intended action aligns with the user's intent when the system's execution may differ due to factors like symlinks or indirection layers. Approval and execution must refer to the same action for a confirm button to function as a true security boundary.

Compliance with this principle requires a narrower approach than the general "keep a human in the loop" advice. Ensuring approval and execution match necessitates binding approval to specific, invariant facts about the operation, not just presenting a narrative about it. This approach requires separating the user's intent, the model's description of the plan, and the operation the runtime will execute.

The model's narration provides context but is not the authorization object. The runtime knows precise details about the effective resource, operation, credentials, network access, and environment that will carry out the action. If any material fact changes, the approval becomes invalid, necessitating a new proposal and request. A concise approval envelope containing enough information to identify the proposed effect is sufficient.

It should include elements like the proposal ID, requested resource, resolved resource, operation, capabilities, tool version, and expiry. Application-specific details, such as the target database or deployment environment for different tasks, must also be included. When preparing the proposal, resolve resources, operation, capabilities, and tool identity before displaying the computed facts alongside the agent's explanation.

Bind consent to a single proposal and invalidate it after material changes. When the action executes, use the declared workspace, credentials, network policy, and lifetime. After execution, verify that the actual effects match the approved proposal, and record the decision, result, exceptions, and review evidence. A hash can help detect mutations, but it does not prove safety; it only confirms that the bytes did not change.

The user still needs a readable view of the facts being authorized, and the runtime must enforce them. Skills, which are part of the action, must also be bound to the proposal using the package or skill name, source, owner, version, immutable revision, review or trust status, and capabilities. Installation trust and run-time authority are distinct decisions.

A team may allow a reviewed skill to exist without permitting every invocation to access credentials or the network. Conversely, approving a task does not guarantee the trustworthiness of a newly substituted dependency. If the skill revision changes after approval, the proposal has changed, requiring a new approval. While isolation contains mistakes but does not validate consent, it does limit the blast radius.

An agent can execute the wrong command within a correct sandbox, write to an unexpected resolved path, or use an untrusted skill with limited permissions. Approval integrity is a separate property from containment, but both should be treated as complementary to ensure secure and reliable operation.