AI Agents: What Changes for Internal Audit

An AI assistant drafts an email and waits for someone to send it. An AI agent can draft the message, query the CRM for the right recipient, attach a document, send it, record the follow-up, and schedule the next step. The difference sounds incremental until the system makes the wrong move.

For internal audit, the key shift is straightforward: when AI moves from generating content to taking action, assurance must expand beyond output quality to authority, identity, permissions, tools, memory, decision sequences, and operational consequences.

There is not yet one universally stable definition of an AI agent. NIST's AI Agent Standards Initiative, launched in 2026, focuses on agents capable of autonomous actions and highlights security, interoperability, identity, and authorization as important areas of work. For audit purposes, a practical definition is enough: an agent is an AI-enabled system that pursues an objective, selects or sequences steps, and uses tools to act on information or systems, often while maintaining state or memory.

An agent is not just a smarter chatbot

A conventional generative AI application produces an output: text, code, a classification, or a recommendation. An agent places that capability inside an operational loop. It can decide what to do next, call a tool, observe the result, and continue until it reaches an objective or a stopping condition.

That is why auditors should think of an agent as an architecture, not as a single model.

Component	Practical role	Why it matters to audit
Objective and instructions	Define what the agent is trying to accomplish and the constraints it should follow.	An ambiguous objective can produce behavior that is rational for the agent but unacceptable to the business.
Model and reasoning	Interpret context, propose steps, and choose among alternatives.	Familiar risks remain: errors, inconsistent outputs, context manipulation, and overreliance.
Tools and APIs	Enable search, read/write access, code execution, or interaction with business applications.	A wrong answer can become a transaction, message, data change, or instruction to another system.
Memory or state	Preserve information across steps or sessions.	Memory can introduce stale data, context contamination, information leakage, or decisions based on incorrect prior state.
Permissions and credentials	Determine what the agent can access or change.	Least privilege becomes central: risk depends as much on what the agent can do as on what it knows.
Orchestration and stopping conditions	Coordinate sequences, retries, sub-agents, and execution limits.	Errors can cascade or repeat when limits, escalation, and safe-stop mechanisms are weak.

Autonomy is also a spectrum, not a yes-or-no attribute. One workflow may require human approval before every material action. Another may operate freely inside predefined limits. A third may work for hours with little intervention. Two systems using the same underlying model can therefore have radically different risk profiles because of their permissions and granted autonomy.

Risk changes when an output becomes an action

Consider an organization introducing an agent to support procurement. The system can review requests, consult policies, compare suppliers, and prepare purchase orders. In a cautious design, it only recommends. In a more autonomous design, it can create transactions in the ERP or communicate directly with suppliers.

Model quality still matters, but it is no longer the only question. Internal audit must understand which actions are possible, under whose identity they occur, with what permissions, which approvals apply, what limits exist, and what evidence remains after every step.

NIST's 2026 analysis of AI agent security responses found broad agreement that traditional cybersecurity principles remain relevant but need to be adapted to the distinctive risks created when AI model outputs are combined with software functions capable of acting. NIST has also placed explicit attention on agent identity and authorization. If a system can operate on behalf of a person or business function, the organization needs to know what is acting, what authority it has, and how that authority can be revoked.

This changes control logic. For a low-risk chatbot, human review of the final answer may sometimes be sufficient. For an agent that can modify master data, initiate payments, or approve exceptions, reviewing the final result may be too late.

The greater the system's ability to act, the less adequate it is to control only the quality of generated content.

What internal audit should look for

The objective is not to turn auditors into agent engineers. It is to determine whether the organization has translated autonomy into controls that are proportionate to the risk. A work program can start with six questions.

What can the agent actually do? Go beyond the product description. Obtain the inventory of tools, APIs, connected systems, and permitted action types.
Under what identity and permissions does it operate? Assess service accounts, roles, segregation of duties, least privilege, credential expiry, and revocation.
Which actions require approval? Distinguish reading, recommending, preparing, executing, and reversing. Material actions should have explicit gates and thresholds based on impact.
How are memory and context controlled? Review what is persisted, for how long, who can access it, how it is refreshed, and how unauthorized or incorrect information is prevented from influencing later actions.
Can the agent stop safely? Look for time, step-count, value, frequency, and retry limits, together with escalation and human takeover mechanisms.
Is traceability sufficient? Logs should enable reviewers to reconstruct the instructions received, tools used, intermediate decisions, approvals obtained, and actions executed.

These questions fit the management-system logic of ISO/IEC 42001:2023, which provides requirements for governing responsible AI through risk management, responsibilities, controls, documented information, performance evaluation, and improvement. The standard is not an agent-specific control catalogue, but its lifecycle and risk-based structure is useful for ensuring that autonomy does not emerge outside established governance.

Audit evidence needs to evolve as well

Agents complicate a familiar audit principle: evidence that a policy exists is not evidence that operational behavior is controlled. For an agentic system, governance documents need to connect to configuration and execution evidence.

A useful evidence pack may include the use-case record, owner, risk assessment, architecture, tool catalogue, permissions, technical identities, approval rules, memory configuration, stopping conditions, change history, execution logs, exceptions, incidents, and test results.

The Global Internal Audit Standards reinforce this expectation from the audit side. Internal audit must exercise due professional care, use technology competently, and gather relevant, reliable, and sufficient information to support conclusions. When the auditable object is an agent, a vendor demonstration or architecture slide will rarely be enough. Auditors need evidence of how the system behaves inside its actual operating boundaries.

A practical procedure is to run controlled scenarios: a normal instruction, an out-of-scope request, an attempt to invoke an unauthorized tool, a transaction above an approval threshold, malicious content embedded in an external source, or a condition in which the agent should stop and escalate. The purpose is not to perform specialist adversarial testing. It is to verify that business and technology controls operate when the agent attempts to act.

The most important failures may be governance failures

Organizations can focus heavily on whether an agent “reasons well” while granting it excessively broad permissions. They can add a human approval at the end of a workflow without testing whether the reviewer receives enough information to detect a bad decision. They can also log only the final action and lose the chain of tools, sources, and intermediate choices that produced it.

The IIA's Internal Audit Upskilling for Critical AI Capabilities describes emerging agentic uses inside internal audit itself, including requesting audit information, reviewing responses, and sequencing testing tasks. That matters because the assurance question has two directions. Internal audit must be prepared to audit agents deployed by the business, but it must also govern agents used inside the audit function.

The same principles apply: approved data, constrained permissions, human review, traceability, and retained professional accountability. An agent can prepare an audit test or summarize evidence. It should not become the invisible owner of professional judgment.

Autonomy should be treated as a risk decision

The right level of autonomy is not “as much as the technology can support.” It is the level the organization can justify, control, and monitor in light of the use case's consequences.

For internal audit, that suggests a simple way to frame scope: start with the actions and work backward. Identify what consequences the agent can create, which systems it touches, whose authority it uses, which decisions it can make without approval, and what evidence would allow a problematic execution to be reconstructed. Then assess the model, data, and architecture in that context.

This approach keeps an agent audit from becoming an abstract AI review. It brings the issue back to familiar assurance concepts: objectives, authority, segregation of duties, limits, exceptions, evidence, and accountability. The technology is new. The underlying assurance question is recognizable: can the organization demonstrate that a system with the ability to act remains inside the boundaries it has chosen to accept?