Your AI agent can act. Can your organisation still explain why?

ARTIFICIAL MIND INSIGHTS · 29 OCTOBER 2026

Autonomous AI changes more than the speed of work. It changes who can act, what must be checked and what the business must be able to prove.

By Milo Izzinosa

Imagine an AI agent that reviews a supplier request, checks records, updates a business system and sends a confirmation. The task completes in seconds. The dashboard shows success.

Two weeks later, somebody discovers that the agent used outdated supplier information, interpreted an instruction from an untrusted document as a command, and changed a record it should only have recommended for review.

This is an illustrative scenario, not a reported customer incident. It exposes an important distinction: a technically completed task is not necessarily an authorised, correct or valuable business outcome.

As AI moves from generating answers to taking actions, organisations need to govern not just the output, but the authority, evidence, consequences and recovery path of each action.

On 29 September 2026, NIST’s National Cybersecurity Center of Excellence published a summary of comments on software and AI-agent identity and authorisation. Its planned implementation work focuses on identifying, authenticating and authorising agents within a software-development lifecycle. This is a project direction, not evidence that a universal agent identity standard has already been deployed.

On 19 October, Microsoft described the emerging risk of AI agents acting as ‘agentic insiders’: systems with access to organisational data and tools whose behaviour requires continuous supervision. Microsoft also sells security products in this area, so its analysis is useful technical context, not independent proof of market outcomes.

OWASP’s Agentic Security Initiative addresses risks such as goal manipulation, unsafe tool use and compromised context. Together, these sources point to a practical management problem: once an agent has permission to act, a successful API call tells you too little about whether its action was appropriate.

1. Define the decision boundary. Specify what the agent may suggest, prepare or execute. Separate reversible, low-impact actions from activities involving money, customers, regulated data, external communication or irreversible changes. Technical capability is not the same as managerial authorisation.

2. Give the agent an identity and limited permissions. An agent needs traceable access appropriate to its task, not an administrator account shared across workflows. Permissions should have owners and a lifecycle, and they should be withdrawn when no longer required.

3. Decide what evidence must survive the action. Preserve the task request, relevant input provenance, tool calls, approvals, outcomes and exceptions in a proportionate, privacy-conscious record. This enables reconstruction of the operational path. It does not mean claiming to reveal a model’s hidden internal reasoning.

4. Make intervention real. Escalation should be triggered by business impact, ambiguity, conflicting evidence or a control breach—not merely by a model’s self-reported confidence. Human reviewers need the authority, context and time to reject, correct or stop an action.

5. Make recovery part of the workflow. Ask how an incorrect update is detected, who is notified, whether it can be reversed and how dependent systems are reconciled. For irreversible steps, prevention and approval matter even more.

Suppose a procurement team uses an agent to process changes to supplier contact details. Low-risk changes could be drafted automatically. Changes to payment accounts might require independent verification and an explicit human approval before any system update. The agent should not obtain broader privileges simply because a user says the change is urgent.

A useful test is to introduce conflicting supplier records or an instruction embedded in a document that asks the agent to skip verification. Does the workflow reject or escalate the request? Can the team see what happened? Can it correct the record without losing the evidence?

The purpose is not to create friction everywhere. It is to concentrate meaningful safeguards where the impact of an error justifies them.

An agent can complete more tasks while leaving the organisation with more rework, escalations, security exposure or operating cost. Usage and throughput therefore need to be read alongside the outcomes that matter.

For each workflow, compare against a credible human or human-plus-AI baseline: successful end-to-end outcomes, quality and error rates, exception-handling time, actual running cost, customer impact and the amount of human review still needed. Keep a non-AI option in the comparison when that is a realistic alternative.

Where evidence does not support continued autonomy, the rational decision may be to narrow permissions, redesign the workflow, retain human control or stop the use case. That is responsible portfolio execution, not failed innovation.

Governance cannot be reduced to a policy document, and observability cannot be reduced to a green dashboard. Both become useful only when they inform operational decisions.

Before granting an AI agent permission to act, leaders should be able to answer three questions:

1. Who is accountable for the business outcome and the authority the agent receives?
2. What evidence would let us verify, challenge and, when necessary, reverse its actions?
3. How will we know whether autonomy improves the workflow compared with a realistic alternative?

An AI agent may execute a task. The organisation remains accountable for what happens next.

Sources and further reading

• NIST NCCoE — Comments on Software and Agentic AI Identity Concept Paper (29 September 2026).
• Microsoft — Securing the Agentic Insider (19 October 2026; vendor perspective).
• OWASP — Agentic Security Initiative (2026 resources).
• NIST — AI RMF Generative AI Profile (26 July 2024).

Original LinkedIn newsletter edition: Artificial Mind Insights · 29 October 2026