From search to action: when should your company AI answer, draft, request approval or execute?

Your assistant finds a customer record. Then someone asks it to update the CRM, send a reply, create a refund and close the ticket.

That is not a better search feature. It is a change of authority.

An AI system that reads useful context may still have no authority to decide what happens next. Separate four modes - answer, draft, request approval and execute - and keep authority proportional to the consequence of being wrong.

This part is the n8n implementation of the rules set out in our AI agent security article. That piece defines the product-level controls: a capability contract and friction proportional to consequence. This one shows where each control lives in a company-brain workflow: which n8n features carry the approval step, the error path and the execution evidence, and which decisions no feature can take for you. Once the assistant can find the right context (part 2) and turn meeting decisions into tasks (part 1), this is the step that decides how much it may do with them. The full build path is on the guide page.

The answer in 60 seconds

• Answer when the system only returns authorised information and can show its sources.
• Draft when the output changes nothing until a named person reviews it.
• Request approval when the action is bounded but affects a customer, money, access, production or a hard-to-reverse record.
• Execute only when identity, scope, limits, validation, evidence and recovery are explicit - and the action has proved reliable in that exact operating context.

Write an action contract before connecting the final tool. If you cannot name the actor, allowed verb, target, limits, approval rule, audit evidence and recovery path, keep the workflow in answer or draft mode.

In this article

1. Treat action as a new product boundary
2. Use the four-mode authority ladder
3. Write an action contract before the agent gets a tool
4. Make human approval a real control
5. Engineer execution and recovery
6. Operate the automation as production software

1. Treat action as a new product boundary

Search retrieves. Drafting proposes. Execution changes state.

That boundary matters because a model can produce an apparently reasonable tool call from incomplete, stale, ambiguous or manipulated context. OWASP describes excessive functionality, excessive permissions and excessive autonomy as the three common roots of excessive agency. NIST’s AI Risk Management Framework similarly treats AI risk management as a lifecycle activity, not a final policy review.

Start with three questions:

1. What can change? A private note, a customer message, a permission, a payment or production code do not carry the same consequence.
2. Who is the actor? The employee, a service identity and the AI workflow are different principals.
3. How do we know the action was allowed? Authentication proves identity; it does not establish business authority.

This distinction is visible in the connected products. Slack scopes, GitHub App permissions and Linear OAuth scopes determine technical reach. None decides whether a particular customer message, issue change or repository action is appropriate now.

2. Use the four-mode authority ladder

Do not classify the whole agent as “autonomous” or “human in the loop”. Classify each action.

Move up only after the lower level has produced evidence. A reliable draft does not prove autonomous sending is safe, and a sandbox success does not prove production recovery.

Use impact and reversibility, not model confidence, to set the ceiling. A high-confidence wrong refund is still a wrong refund. A low-confidence classification can sometimes execute safely if it only adds a reversible internal label and the workflow detects exceptions.

3. Write an action contract before the agent gets a tool

An action contract turns “the AI can update Linear” into a reviewable specification. It is the workflow-level counterpart of the capability contract from the agent security article: that one is agreed between product, engineering and security for the whole agent; this one is written per state-changing tool, in the words the n8n workflow will enforce.

For every state-changing tool, record:

• purpose: the business outcome this action supports;
• actor: user identity, service identity and accountable owner;
• verb and target: for example, issue:create in one team - not “write to Linear”;
• allowed inputs: validated fields, classifications and source requirements;
• limits: amount, frequency, recipients, environment and time window;
• preconditions: current state, freshness, permissions and required evidence;
• approval rule: who approves what, when and for how long;
• result evidence: request ID, target ID, final state and operator;
• recovery: cancel, compensate, retry, reconcile or escalate.

The credential must match the contract. GitHub recommends suitable authentication, minimum permissions, secure credential storage and remediation planning in Keeping API credentials secure. In n8n, RBAC and project roles can separate projects, workflows and credentials; supported external secret stores can keep eligible credentials outside workflow configuration. The contract still defines the allowed action.

4. Make human approval a real control

An approval message that says “The agent wants to update the CRM - approve?” is theatre. The reviewer needs the exact action they are authorising.

A useful approval request shows:

• tool and operation;
• target record and current state;
• proposed field-level change;
• source evidence and unresolved uncertainty;
• expected external effect;
• expiry and recovery route.

Bind approval to those parameters. Re-open it if the payload changes, the evidence becomes stale or the approval expires. Separate proposer and approver where the consequence justifies it.

n8n documents a human-in-the-loop tool review that pauses a selected AI tool, presents its proposed input and accepts approval or denial. That is a useful execution mechanism. It is not the business rule that determines who may approve a significant refund, a client message or a production deployment.

Avoid approval fatigue: keep deterministic validation outside the model and route only material exceptions or consequential actions to people.

5. Engineer execution and recovery

Approved does not mean safely executed. Production workflows still need to:

• validate the exact payload at the tool boundary;
• use idempotency keys or duplicate detection where the API supports them;
• compare the target’s current state with the state the reviewer saw;
• distinguish a timeout from a confirmed failure;
• reconcile the final state in the source system;
• route partial failures to an owner;
• preserve enough evidence to replay or compensate safely.

n8n’s error workflows can route execution failures, while execution views expose stored run evidence and retry options. An alert, however, is not recovery. If a CRM update succeeded but the workflow timed out before recording success, a blind retry can duplicate work or overwrite a newer change.

NIST’s AI RMF Core includes monitoring, override, incident response, recovery and change management. Translate that into a named decision: retry, reconcile, compensate, stop or escalate.

An illustrative Atlas workflow

Atlas, a fictional B2B service company, wants AI to process meeting decisions.

1. The assistant may answer questions from authorised meeting notes.
2. It may draft a Linear issue with owner, due date and source link.
3. It must request approval before assigning external commitments or sending a client message.
4. It may execute creation of an internal, reversible issue only when the project, issue type and owner are allowlisted and the source decision is current.

Atlas is illustrative, not an IZZY client case. One workflow can use all four modes without labelling the whole system “autonomous”.

6. Operate the automation as production software

Low-code reduces build time. It does not remove patching, secrets, network, logging or recovery work.

This is where the recent n8n signal is useful. On 25 February 2026, the project disclosed CVE-2026-27577: an authenticated user with workflow create/modify permission could abuse crafted expressions to execute commands on the host in the affected versions. The accompanying security bulletin listed patched branches at that date and advised affected self-hosted users to upgrade.

The professional lesson is bounded:

• know which versions and components are running;
• restrict workflow editing to trusted roles;
• use the vendor’s security audit;
• isolate code execution with measures such as hardened task runners;
• maintain an explicit update process;
• send selected events into an operating process, using external log streaming where the edition and architecture support it.

The advisory does not show that every n8n deployment is vulnerable today. A newer version alone also proves nothing about permissions, secrets, host access or recovery.

Related: IZZY’s AI pilot-to-production governance checklist.

Conclusion: give the AI less authority than the workflow can prove

The right question is not “Can the agent do it?” It is “What authority has this exact action earned?”

Use answer, draft, approval and execution as separate modes. Give every action a contract. Bind approval to an exact payload. Validate at execution. Preserve evidence and recovery.

Frequently asked questions

Sources and evidence boundary

Research checked on 28 July 2026 against the primary or official sources linked in the article. The four-mode ladder, action contract and Atlas workflow are IZZY guidance.

No live agent, n8n instance, credential, approval callback, source record, action, retry, log stream, security posture or business outcome was tested. CVE-2026-27577 is a dated operational example, not evidence about a reader’s environment. Product documentation and security guidance can change after the research date.