Agentic AI: New Risks From Autonomous Actions

A procurement agent receives a simple instruction: accelerate the purchase of a critical component. It checks inventory, reviews email, compares suppliers, and prepares an order. So far, it resembles a faster digital assistant. The risk changes when it can also execute: create the order, modify records, send messages, or invoke other tools without a person reviewing every step.

Now consider a hypothetical failure. A malicious instruction hidden in a supplier document pushes the agent toward an unintended path. Because its credentials are overly broad, it creates a transaction outside approved parameters before anyone sees the result. The problem is no longer an inaccurate answer on a screen. It is a business consequence.

That leads to the central audit thesis: as autonomy increases, control must move from reviewing outputs to governing authority, actions, and execution.

The critical boundary is moving from generation to action

A generative system can draft the wrong email. A tool-connected agent can send it, update a record, deploy code, move a case to another workflow stage, or initiate a transaction. The NIST AI Agent Standards Initiative, launched in 2026, reflects this shift toward agents capable of autonomous actions and of operating on behalf of users. The NIST AI Risk Management Framework remains a voluntary baseline for managing AI risk; NIST notes that AI RMF 1.0 is currently being revised. Agent-specific NIST work is still evolving and should not be treated as binding requirements.

Not every agent has the same degree of autonomy. For auditors, the marketing label matters less than the combination of action capability, permissions, duration, delegation, and reversibility.

Operating pattern	What the system can do	Primary control focus
Recommend	Produces a proposal; a person acts	Output quality and validation
Prepare	Completes drafts or forms without execution	Data integrity and human review
Execute with approval	Calls tools after explicit authorization	Approval context and segregation
Execute within boundaries	Performs multiple actions without individual approval	Permissions, limits, monitoring, and stopping
Delegate or persist	Chains tools, memory, or other agents	Identity, authority propagation, and end-to-end traceability

The most important change is that risk no longer ends at the model. It extends into identities, APIs, credentials, enterprise applications, authorization rules, retrieved data, and downstream systems. A mediocre agent with tightly constrained permissions can be less dangerous than a technically excellent agent with excessive access.

Four controls become decisive as autonomy grows

1. Identity and permissions: know who is acting and under what authority

The NIST National Cybersecurity Center of Excellence project on software and AI agent identity and authorization starts with a foundational problem: how to identify agents, authorize access, and control the actions they take. The issue is material because agents often connect to multiple datasets, tools, and applications.

A weak pattern is to let an agent inherit a user's full credentials. That makes it harder to distinguish whether an action was taken by the human or by the agent and can grant far more privilege than the task requires. NIST's emerging work points toward first-class agent identities, explicit delegation, least privilege, and authorization that reflects context.

For audit, the question is not simply “does the agent have access?” It is “what exact authority can it exercise, for how long, and over which objects?”

2. Action boundaries: control the transaction, not only the tool

Access to a system should not imply permission to perform every action inside it. A procurement agent may need to query suppliers and prepare purchase orders but should not necessarily be able to alter banking details or exceed a monetary threshold. A development agent may need to run tests but not deploy directly to production.

The most useful controls are often consequence-specific: transaction limits, approved recipient lists, authorized environments, command allowlists, immutable fields, segregation of duties, and additional approvals for irreversible actions.

This is an important distinction from traditional access control. The control object is the proposed action in context, not merely the identity that opened the session.

3. Stopping conditions and recovery: decide when the agent must stop trying

Agents can explore alternative paths to achieve an objective. That flexibility creates value, but it can also amplify error. If one tool fails, the agent may try another. If permission is denied, it may seek a different route. If a result appears incomplete, it may repeat the process.

ISO/IEC 42001:2023 requires organizations to assess and treat AI risk and to document the controls needed for that treatment. Its implementation guidance for the AI system lifecycle addresses topics including human oversight, controllability, operational monitoring, response to failures, updates, and event records. The standard does not prescribe one universal “kill switch” for every agent. For agentic systems, a reasonable risk-based implementation is to define explicit criteria for stopping, escalating, or recovering execution.

Those criteria may include exceeding step, time, or cost limits; attempting an unauthorized tool; receiving repeated denials; detecting a policy deviation; entering an irreversible operation; or losing the ability to verify an outcome. A stopping rule is only useful if the organization also has a mechanism for human takeover, rollback, or compensating action when effects have already occurred.

4. Logs: reconstruct what happened, not only what the model said

When an agent can create consequences, a conversation transcript is not enough. ISO/IEC 42001 includes implementation guidance on keeping event logs or other deployment and operational documentation that can demonstrate intended use and support the communication of concerns. NIST's agent identity work also places emphasis on auditing, non-repudiation, actions, and intent.

An assurance-grade record should make it possible to reconstruct, at minimum, who initiated the task, which identity the agent used, what authority it received, which tools it called, what data it accessed, which actions it proposed and executed, what approvals it obtained, what the result was, and when an intervention or stop occurred.

Agent traceability should follow the chain of consequences, not stop at the chain of messages.

Human in the loop is not an automatic control

Adding an “Approve” button in front of an action does not solve the problem by itself. In August 2026, a NIST publication on identity foundations for agentic AI warned that excessive reliance on human approvals can create consent fatigue. If an agent repeatedly asks for permission, users can become conditioned to approve requests without meaningful evaluation.

Effective approval must occur at material decision points, display enough context, and allow a genuine refusal. For a transaction, the approver may need to see the object, value, counterparty, change from the previous state, and reason for the action. Asking “allow the agent to continue?” twenty times does not create control; it can create a click-through routine.

A stronger design combines tightly scoped preventive authorization with targeted approval for exceptions or consequential actions. The goal is not to insert a human into every step. It is to preserve accountability and intervention authority where risk actually changes.

What an auditor should actually test

An agentic AI review should not stop at policies or architecture diagrams. The control exists in execution. A useful engagement combines configuration inspection, transaction sampling, and scenario testing.

Audit question	Useful evidence	Possible test	Red flag
Does the agent have its own identity and authority?	Service identities, scopes, delegation policies, tokens	Compare effective permissions with the approved use case	Shared credentials or access equivalent to the human user
Are actions constrained by consequence?	Transaction rules, allowlists, monetary limits, segregation	Attempt an out-of-bounds action in a controlled environment	The system relies only on prompt instructions
Can it stop and recover?	Stop rules, runbooks, takeover and rollback mechanisms	Simulate repeated error, unexpected tool use, or loss of verification	No clear stopping criterion or intervention occurs only after irreversible impact
Is execution traceable?	Agent, API, target-system, and approval logs	Reconcile a sample of runs across systems	An action cannot be attributed or its sequence reconstructed
Do changes reopen the risk assessment?	Change records, new tools, permissions, and versions	Review a recent capability change and its approval	New capabilities are added without reassessing authority, limits, or monitoring

Some tests, particularly indirect prompt injection, privilege escalation, sandboxing, or adversarial behavior, will normally require cybersecurity or AI security specialists. Internal auditors do not need to perform every technical test themselves, but they should know which assurance question must be answered, what evidence is expected, and where specialist competence is required.

The design mistake is treating an agent like a very fast user

Agents do more than accelerate known steps. They can select routes, combine tools, and adapt their sequence based on intermediate results. NIST has highlighted how agent speed, scale, and capacity can magnify longstanding identity and access weaknesses. A broad permission that was inconvenient but manageable for a human can become a much larger risk surface when an automated system can explore multiple paths in seconds.

That is why maturity should not be measured by maximizing autonomy. It should be measured by granting the minimum autonomy required to create the intended business value, inside an architecture that limits consequences, records actions, and can stop execution.

The closing question for an agentic AI audit is straightforward: what can this agent do without asking again, how would we know exactly what it did, and how would we stop it before one error becomes a chain of actions?

As agents become embedded in financial, operational, and technology processes, that question will cease to be an AI design issue. It will become a basic governance, internal control, and assurance question.