An unusual action is just behaviour outside the norm. A compromised or harmful one is behaviour that crosses a control boundary, reaches unauthorised data, changes systems, or defeats an intended safeguard. The difference is not the label, it is the evidence showing whether the action stayed inside its delegated authority.
How to tell “odd” behaviour from actual compromise
The practical difference is whether the action can still be explained as a legitimate but unexpected deviation, or whether it shows the agent has crossed a security boundary. An unusual action may look strange in logs, but a compromised one typically exposes evidence of unauthorised reach, policy bypass, or destructive side effects. For agent systems, that boundary is the key question, not whether the behaviour simply feels abnormal.
That distinction matters because autonomous systems can drift, improvise, or take efficient shortcuts without being attacked. A single odd tool call, an unfamiliar API sequence, or an unexpected data lookup may be benign if it remains within delegated scope and produces no protected side effects. A compromised action is different when it reaches data the agent should not see, changes state it should not change, or defeats a safeguard that was supposed to stop it.
The strongest test is evidence of authority. If the behaviour stayed inside its approved task, token scope, environment, and control checks, it is unusual. If it used access that should have been blocked, chained actions that were not authorised, or produced outcomes that the surrounding controls were designed to prevent, treat it as a security event and not a curiosity.
When the phrase “unusual action” is used too loosely, teams can miss the transition from anomaly to incident. The same pattern may move from low concern to high concern if it is paired with a new destination, a privileged command, a bulk export, or an attempt to suppress logging or approval steps.
One useful way to frame the difference is that unusual behaviour is about deviation from baseline, while compromise is about violation of trust boundaries. Baseline tells you what is typical; trust boundaries tell you what is allowed.
Why the control boundary matters more than the label
An AI agent can behave in a surprising but harmless way, especially when prompts are ambiguous, the task is novel, or the environment is noisy. The label “unusual” should therefore trigger review, not assumption. What changes the assessment is whether the action stayed inside the agent’s delegated authority and whether it respected the intended separation between systems, data sets, and approvals.
AI Agent Authorisation Guide is directly relevant here because the core question is per-action authority, not general behaviour. If the agent’s action was valid only because it inherited broader access than it should have had, the issue is not merely unusual behaviour, it is excessive authority.
Zero Trust for AI Agents adds the right decision lens: verify the principal, the request, and the policy outcome before trusting the action. That is what separates an odd but permitted action from a harmful one that should have been stopped by a control.
AI Agent Observability, Audit and Incident Response Guide is useful because evidence quality is what turns suspicion into a defensible conclusion. Without attributable logs, policy traces, and action history, “compromised” becomes guesswork instead of a decision.
What usually proves compromise in practice
Compromise is usually proven by one or more concrete effects: the agent accessed a system or dataset outside its role, changed configuration or content without approval, exfiltrated information, or executed a path that bypassed an intended safeguard. Those effects matter more than the surface shape of the prompt, the model output, or the oddity of the sequence.
In a mature review, the key question is whether the action expanded the agent’s effective blast radius. A strange but harmless action stays inside the sandbox. A harmful one crosses into production systems, sensitive records, or irreversible state changes. In other words, the risk is not that the agent looked odd, but that it could now cause material impact.
Browser and Computer-Use Agent Security Guide is a good example of why session scope matters. If an agent acts through an existing human session, the distinction between “unexpected” and “compromised” may hinge on whether it remained inside the user’s approved browser context or reached beyond it.
RFC 8693: OAuth 2.0 Token Exchange is relevant when delegated authority is in play. If a system is exchanging tokens or acting on behalf of another principal, the question becomes whether the resulting token was appropriate for the action actually taken, or whether delegation was abused to reach something out of scope.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The question turns on when agent action crosses delegated authority. |
| Recommendation — Enforce per-action authorization and least privilege to prevent agent privilege abuse. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Authentication | Agent-to-service actions hinge on authenticating the non-human principal behind the request. |
| AC-6 — Least Privilege | The distinction depends on whether the agent exceeded approved access and authority. | |
| AU-2 — Event Logging | Determining compromise requires audit evidence of the action path and side effects. | |
| Recommendation — Authenticate service-like agent actions with strong, traceable credentials and token scope. Limit agent permissions to the minimum needed for each task and environment. Log agent requests, decisions, and resulting system changes for later attribution. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The answer hinges on continuous verification of request, principal, and policy outcome. |
| Recommendation — Verify each agent action at decision time instead of trusting prior authentication. | ||
Practitioner Guidance
What to verify: Start with the action trace, not the model output. Confirm which principal acted, what token or session was used, which data or systems were touched, and whether any control was bypassed or failed open.
Decision rule: If the action produced access, change, or exfiltration outside approved authority, treat it as compromise until proven otherwise. If it stayed inside scope but looks unfamiliar, classify it as an anomaly and tune detection around the pattern.
What practitioners underestimate: The most important evidence is often negative, for example a missing approval step, missing audit trail, or missing policy check. When those expected controls are absent, the action is harder to defend as merely unusual.
Practitioner takeaway: Do not decide based on how strange the behaviour looks. Decide based on whether the agent’s action remained inside its delegated authority and whether the controls that were supposed to stop unsafe behaviour actually held.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between governing human access and governing AI agent access?
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between workload identity and API keys for AI agents?