AI agents now pause for human approval on sensitive Computer Use actions
n8n's Instance AI can now suspend AI agents when Computer Use tools need human permission, showing users exactly what resource is being accessed before granting or denying access.
When n8n's Instance AI uses Computer Use to access files, run shell commands, or automate browsers, it sometimes needs permission first. A new confirmation system now makes that possible — with a critical twist: the AI cannot approve its own requests.
Previously, the AI agent could theoretically supply its own "allow" decision. This PR fixes that gap by routing all permission decisions through human confirmation. When the Computer Use daemon signals that a tool needs approval, the agent suspends — its entire state persisted to the database — and waits. The user sees which resource the AI wants to access (a file path, a shell command, a website) along with options like "allow once" or "always allow." Once the user decides, execution resumes with that decision.
The agent cannot inject its own _confirmation parameter. Any such attempt gets stripped from arguments before the tool runs. This ensures the human remains the gatekeeper, not the AI.
The change lives across the fs-proxy daemon, the Instance AI tooling layer, the backend confirmation API, and a new frontend dialog component.
View Original GitHub Description
Summary
Implements Computer Use tool call confirmation in Instance AI. Because the Computer Use (old name Local Gateway) has own permission checks with configurable allow/deny logic stored on the computer the instance itself does not necessary know which tool calls must be confirmed. When Computer Use operates in confirmationMode: instance tool call execution which require user confirmation will fail with and the confirmation options will be included in the error response. These options contain randomly generated decision id which is stored locally. Once users confirms the request the tool call is executed again with passed decision id. This flow adds a level of protection to prevent the agent from executing tools while bypassing HITL logic (for example by passing "allow" on it's own)
Following diagram shows how the confirmation flow works:
sequenceDiagram
participant FE as Browser (Frontend)
participant SRV as n8n Server
participant DB as Database
participant D as fs-proxy Daemon
Note over SRV: First invocation — tool execute() called by Mastra
SRV->>D: callTool({ name, args }) via LocalGateway
D-->>SRV: { isError: true, content: ["GATEWAY_CONFIRMATION_REQUIRED::..."] }
SRV->>SRV: parse GatewayConfirmationRequiredPayload
SRV->>DB: suspend() — persist agent snapshot + confirmation payload
SRV-->>FE: SSE confirmation-request event<br/>{ inputType: "resource-decision", resourceDecision: { resource, description, options } }
FE->>FE: show GatewayResourceDecision panel
Note over FE: User clicks a decision button (e.g. Allow for session)
FE->>SRV: POST /confirm/:requestId { approved: true, resourceDecisionToken: "<token>" }
SRV->>DB: load agent snapshot, resume with resumeData
Note over SRV: Second invocation — tool execute() called with resumeData
SRV->>D: callTool({ name, args, _confirmation: "<token>" }) via LocalGateway
D->>D: validate token, apply decision, execute tool
D-->>SRV: { content: [...], isError: false }
SRV-->>FE: SSE tool-result / text-delta events
Related Linear tickets, Github issues, and Community forum posts
Review / Merge checklist
- PR title and summary are descriptive. (conventions) <!-- **Remember, the title automatically goes into the changelog. Use `(no-changelog)` otherwise.** -->
- Docs updated or follow-up ticket created.
- Tests included. <!-- A bug is not considered fixed, unless a test is added to prevent it from happening again. A feature is not complete without tests. -->
- PR Labeled with
Backport to Beta,Backport to Stable, orBackport to v1(if the PR is an urgent fix that needs to be backported)