An AI agent can answer a customer, retrieve an order, check an account and initiate a transaction through connected systems. The more useful it becomes, the more it can affect what happens outside the conversation. That creates a difficult question for the organization deploying it:
When an agent does something unexpected, how do you establish what actually happened and decide what to do about it?An alert may show that an agent called an API it rarely uses. It may not tell you whether the request succeeded, what information was accessed or whether another system acted on the result. The agent might have made a routine operational error. It might have bypassed a business requirement. Or its behavior might indicate a genuine security incident.
Those are different problems, and they require different responses. Treating every unusual action as a major incident creates unnecessary disruption. Treating a consequential action as just another software error can be far more costly. As AI agents gain access to enterprise applications, organizations need more than controls over what an agent is allowed to do. They need a reliable way to investigate what it did, understand the consequences and verify that the right response followed.
Nearly half report unintended AI-agent actions
Research published by Salt Security on 13 October 2026 points to a growing challenge. Its "State of Agentic AI and API Security 2H 2026" report surveyed more than 380 security and technology professionals.
Among respondents, 49.8% said they had confirmed or suspected that an AI agent in their organization had taken an unintended, unexpected or unauthorized action during the preceding 12 months. Only 12.5% said they could consistently trace an agent's complete path, from its initial instruction through the tools and APIs it used to the final outcome. Just 17.5% reported being able to automatically stop an agent behaving unexpectedly in production.
One qualification matters: the 49.8% figure combines confirmed and suspected actions reported by survey participants. It is not a verified count of security breaches. Nor does every unexpected action mean that an agent has been compromised.
The more revealing finding is the gap between agent activity and an organization's ability to reconstruct it.
Salt reported that more than 60% of respondents would need hours or days of manual work to reconstruct a particular agent's activity from the previous day.Consider what that means in practice. An agent may interact with an internal application, call an external API and pass information into another workflow. Each system might retain its own logs, but investigators still need to connect those records and establish which events belong to the same sequence. A log can tell you that a request happened. It may not tell you why the agent made it, whether the action was appropriate, what the receiving system actually did or who is responsible for deciding the next step. That is where the operational challenge begins.
Detection is not the same as prevention
Salt Labs also described a proof-of-concept attack against the Manus agentic AI platform in September 2026. According to Salt's account, a malicious email containing obfuscated JavaScript could cause the agent to execute code and expose access tokens associated with connected services, including email, cloud storage and code repositories. Salt reported that the platform's guardrail detected the attack but did not prevent the code from executing.This was a researcher-described proof of concept involving a particular platform, not evidence that all AI agents are vulnerable in the same way. But it illustrates an important distinction: detecting suspicious behavior does not necessarily prevent the resulting action.
Once an agent can interact with other systems, the consequences may extend beyond the original event. A tool call might access information, a connected service might accept a change, or a downstream workflow might act on the result. The initial alert is only one part of the picture. The response must establish what happened across the affected systems, not simply confirm that an alert was raised.
Not every unexpected action is a security incident
Before deciding how to respond, an organization needs to understand what kind of failure it is dealing with. Three categories provide a useful starting point, although they can overlap.
- An operational error occurs when an agent does something unintended without evidence of a security compromise. For example, a support agent might create a duplicate draft after retrying a request that timed out. The team needs to establish whether the duplicate affected a live record, correct it if necessary and investigate the retry behavior. Disabling the entire agent would not automatically be justified.
- A control failure occurs when an agent or its surrounding workflow fails to enforce an established business requirement. Imagine an agent submitting a customer application while a mandatory verification status is missing. The team must determine whether verification actually occurred, whether the receiving system accepted the submission and whether other applications could be affected. The appropriate correction might involve changing the workflow, reviewing affected applications or strengthening a validation step.
- A security incident involves suspected or confirmed malicious activity, unauthorized access, compromise or another event that meets the organization's incident criteria. If an agent accesses information outside its authorized scope, for instance, investigators need to establish what was accessed, how access occurred and whether further activity is possible. Containment should follow the organization's security procedures and the assessed risk.
From alert to verified outcome: a practical response framework
The NIST AI Risk Management Framework's Manage guidance emphasizes documented risk treatments, incident response, recovery, change management and processes for tracking and responding to AI incidents and errors. It does not prescribe a single response sequence for every unexpected agent action.Organizations can use those principles to build a practical process around four questions: What happened? What did it affect? Who must decide what happens next? How will we know the issue has been resolved?
1. Establish what the alert actually tells you
An alert is a signal to investigate, not proof of a breach.
Suppose a monitoring system flags an agent for sending a refund request above a configured threshold. That alert alone does not establish whether the request was rejected, accepted or completed. The threshold might represent a hard technical restriction, a business rule requiring approval or simply a condition that warrants review. The response depends on how the system is designed.
The initial investigation should identify the agent, the event, the relevant tool or API, the available timestamps and the evidence supporting the alert. If the event meets the organization's security incident criteria, the established incident-response process should take over. Otherwise, the relevant technical or business owner may be best placed to investigate.
The objective is simple: establish the facts before deciding what the facts mean.
2. Reconstruct the action across systems
An agent's execution trace is useful, but it may not establish the complete outcome. The receiving application and any downstream services have their own records, and those records matter.Return to the refund example. The agent's logs might show that it submitted a request. The payment or order system must establish whether the refund was accepted or processed. Approval records may show whether the required authorization existed. Together, these records can distinguish an attempted action from a completed transaction.
Investigators should connect the agent's instruction, tool calls, API requests, receiving-system responses and resulting changes wherever that evidence is available. They should also record gaps. If the organization cannot establish whether a transaction completed, that uncertainty is itself relevant to the response.
This is more useful than collecting logs without connecting them. The aim is to reconstruct the sequence well enough to explain what happened and support a defensible decision.
3. Assess the impact before choosing a response
Once the sequence is clearer, the organization can assess what was affected and what action is warranted.
That assessment may include whether data was accessed or changed, whether a customer or business process was affected, whether the action can be reversed and whether similar actions could have occurred elsewhere. Where malicious activity or continuing harm is suspected, the security team should follow the appropriate containment and escalation procedures while the investigation continues.
Not every event requires the same response. A duplicate draft may need correction and a software fix. An incorrectly submitted application may require a review of affected records and a change to the approval workflow. Suspected unauthorized access may require security-led investigation and containment. The response should be proportionate to the evidence and risk. It should not be determined solely by how alarming an alert looks.4. Assign corrective work and verify completion
An investigation is not complete just because the team understands the initial event. Someone must own the corrective action, and the organization needs evidence that it worked.The technical team might correct a retry condition or strengthen an API validation. A business owner might review affected applications. Security might investigate possible unauthorized access. Risk or compliance specialists may need to assess obligations if the event meets the relevant criteria.
These responsibilities can overlap, but they should not remain ambiguous. Each action needs an owner, a defined outcome and a way to verify completion. If a workflow is changed, for example, the team should test whether the original failure can still occur. If affected records are reviewed, the outcome of that review should be documented.
A closed ticket is evidence that someone marked work complete. It is not, by itself, evidence that the underlying problem has been resolved.
What should the incident record contain?
A useful record should allow someone who was not involved in the original investigation to understand the event, the decisions made and the evidence supporting closure. Record and What it should establish:
- Trigger and initial evidence: What raised concern and why the event was investigated
- Agent and systems involved: Which agent, tools, APIs and receiving systems were implicated
- Reconstructed sequence: What the agent attempted, what each system returned and what actually changed
- Impact assessment: Which records, processes, people or services were affected, including relevant uncertainties
- Decision and rationale: Why the organization chose a particular response, including escalation or containment where applicable
- Corrective actions: What needs to change, who owns it and what completion means
- Closure evidence: How the organization verified the correction and whether any unresolved risk remains
This becomes especially important when an event crosses team boundaries. Security may understand the access path, technology may understand the API behavior, and the business owner may understand the consequence of the action. The incident record connects those perspectives into one account.
Test the response before a real incident
Organizations do not need to wait for a serious failure to discover whether their response process works. A tabletop exercise can reveal gaps using a scenario grounded in the systems and permissions the agent actually has.- Choose an agent already operating in the organization and examine a plausible event: a tool call fails, a retry occurs, a connected application records a change, and an alert is raised. Ask the relevant teams to establish what happened using the evidence they would genuinely have available.
- Can they determine whether the action succeeded? Can they identify the affected records? Who decides whether the event requires security escalation? Who owns the correction? What evidence would be sufficient to close the investigation?
The exercise is valuable precisely because it may expose mundane weaknesses: disconnected logs, unclear ownership, missing approval records or no agreed way to verify that a fix worked. Those are problems an organization can address before an unexpected action becomes a consequential incident.
Where continuous AI assurance fits
Runtime security, access controls and monitoring help prevent, detect or contain unsafe activity. They remain essential. An assurance process serves a different purpose: it connects the event and its evidence to the organization's assessment, decisions, corrective actions and proof of completion.That is the gap KlaritiQ's continuous AI assurance approach is intended to address. When an event or control failure has been established, the organization needs a traceable path from what changed to what it affected, what decision was made, who acted and what evidence demonstrates the outcome. This does not replace runtime detection, security investigation or the judgement of the people responsible for the response. It helps make the resulting work and accountability visible.
The distinction is important. An organization can have sophisticated monitoring and still struggle to demonstrate how an alert was resolved. It can also maintain detailed incident records without knowing whether the corrective action remains effective. Assurance connects those activities so that a decision does not disappear into a ticket, a meeting or an undocumented handoff.
The question to ask before deploying the next agent
Before giving an AI agent access to another application or business process, ask more than what it is permitted to do. Ask whether the organization could reconstruct a consequential action, determine its impact, identify the person responsible for the next decision and prove that the resulting corrective work was completed.An agent taking an unexpected action may be a technical problem, a business-process failure or a security incident. The organization cannot know which one it is until it establishes the facts.
Securing an AI agent means controlling what it can do. Assuring its operation means being able to explain what it did, understand the consequences and demonstrate what the organization did in response.
Both are necessary when AI begins acting inside the systems a business depends on.