AI agent execution graphs need a triage model, not just visibility

At a glance

What this is: ARMO says AI agent execution graphs are useful only when they feed a triage model that maps runtime behaviour to document, investigate, or page decisions.

Why it matters: This matters because SOC and platform teams need a repeatable way to govern AI agent behaviour without drowning in visibility data that does not translate into action.

Context

AI agent execution graphs are runtime records that combine prompts, tool calls, API interactions, data access, and egress into a single chain. The governance problem is not whether teams can see the chain, but whether they can decide fast enough what that chain means for containment, investigation, or documentation.

For identity and security practitioners, the key issue is that the graph only becomes operationally useful when it is compared with a behavioural baseline tied to the agent’s permissions and normal integrations. Without that comparison, unusual behaviour, attack probing, and completed compromise can look too similar to drive a defensible response.

Key questions

Q: What breaks when AI agent execution graphs are visible but not triageable?

A: Teams end up with runtime detail but no consistent decision path, so analysts either over-escalate every unusual chain or under-react to real probing. That failure is operational, not cosmetic. A graph only supports security when it is tied to explicit thresholds and a response choice that is stable across shifts, incidents, and analysts.

Q: Why do behavioural baselines matter for AI agent triage?

A: Because the same graph can represent legitimate novelty, early probing, or a completed attack, and the difference is only visible when compared with what the agent normally does. A baseline turns raw runtime telemetry into a decision about whether the behaviour is inside, at the edge of, or beyond expected scope.

Q: What signals show an AI agent chain is moving from unusual to malicious?

A: Repeated tool calls with changing arguments, edges to destinations outside the approved integration list, and successful actions that cross a boundary the agent has not crossed before are the clearest signs. The practical test is whether the chain is still unresolved or has completed an unauthorised action.

Q: Should SOC teams page on every AI agent alert?

A: No. Paging should be reserved for completed boundary crossings that show the agent has already done something outside its historical scope, such as writing where it only read or egressing to an unapproved destination. Probing and unusual-but-contained chains should be investigated first, not escalated automatically.

Technical breakdown

How execution graphs become triage inputs

An execution graph is the assembled runtime sequence of an agent’s actions, usually including prompt handling, tool invocations, API requests, data access, and network egress. By itself, the graph is descriptive. Triage requires the graph to be evaluated against a learned baseline of what that agent normally does, including which tools it calls, which resources it touches, and which destinations it reaches. The article’s core point is that visibility only becomes security value when the graph is mapped to a decision model. In practice, the control problem shifts from collection to interpretation, and then from interpretation to action selection.

Practical implication: Use the graph as an input to a runbook decision, not as an end state.

Why behavioural baselines matter for AI agent triage

A baseline is the reference model that tells a defender whether an agent’s behaviour is ordinary, suspicious, or already beyond its expected boundary. That matters because AI agents can look anomalous while remaining legitimate, or look subtle while actually probing for access they should not have. The article treats the baseline as the bridge between detection and response. This is especially important for production agents because their normal behaviour can change over time, which means the baseline must be learned, maintained, and queryable at the moment a decision is made.

Practical implication: Maintain agent baselines as operational security artefacts, not one-time onboarding data.

What turns a graph from unusual to actionable

The decisive factor is not graph complexity, but whether the chain stays inside or crosses the agent’s allowed boundary. A short, odd chain may still be legitimate if it fits historical behaviour. A repeated probe can remain below the threshold for a completed attack. The article separates these cases into three tiers: info-only, attack attempt, and active attack. That separation works because it ties the observed pattern to a prescriptive response rather than a severity label. In other words, the graph is not asking how bad the event looks. It is asking what the engineer must do next.

Practical implication: Anchor triage on boundary crossing and repeatability, not on how alarming the graph appears.

NHI Mgmt Group analysis

Baseline-driven triage is now a governance control, not a logging feature. The article shows that AI agent execution graphs only become decision-grade when defenders compare them with learned behaviour and enforce a response tier. That changes the role of observability from retrospective explanation to live control selection. For practitioners, the implication is that runtime visibility without triage logic is incomplete security.

Decision latency is the real control gap in agent operations. The problem is not whether the SOC can see eleven nodes or seven tool calls. The problem is whether the team can classify the chain fast enough to separate benign novelty from a probing attack or a completed boundary crossing. In agentic environments, delay is itself a governance failure. Practitioners should treat the decision window as part of the control surface.

Agent execution graphs expose a new form of identity governance debt. Once an agent has permission to call tools, query data, and reach external services, the question becomes how quickly abnormal behaviour can be distinguished from authorised autonomy. That is an identity issue because the graph is only meaningful when every action is tied back to a service account, its scope, and its approved integrations. The practitioner conclusion is that agent identity and runtime triage must be governed together.

Triage models need escalation thresholds that are explicit, stable, and reviewable. A framework that says “investigate” without defining the transition from info-only to attack attempt leaves too much judgement to individual analysts. The article’s value is that it pushes teams toward deterministic escalation rules. For security operations, the practical outcome is a runbook that can be defended to auditors, incident responders, and platform owners alike.

What this signals

Execution graph triage is becoming the missing operational layer for agent governance. Security teams already know how to collect runtime signals, but collection alone does not separate curiosity from compromise. The more AI agents are allowed to call tools and reach external services, the more the SOC needs a classification model that converts behaviour into response.

Agent identity and permission scope are now inseparable from runtime monitoring. If every graph node cannot be tied back to a service account and an approved integration set, the team cannot tell whether a chain is drift, misuse, or compromise. That means identity context must travel with telemetry from the start, not be reconstructed after the fact.

For practitioners

• Define a three-tier triage runbook for agent execution graphs Map info-only, attack attempt, and active attack to specific actions such as document, investigate, and page. Make the escalation thresholds explicit so analysts are not guessing under pressure.
• Pair runtime graphs with behavioural baselines Record normal tool calls, API interactions, data access paths, and egress destinations for each production agent so the SOC can compare every new chain against expected behaviour.
• Separate investigation from containment Treat completed boundary crossings as containment events and unresolved probes as investigation events, then route each to a different response path in the runbook.
• Link every agent action to identity and scope Make sure each execution graph can be traced back to the service account, permissions, and approved integrations that allowed the action in the first place.

Key takeaways

• AI agent execution graphs only reduce risk when teams can classify them into a small number of response states, not when they simply render more detail.
• Behavioural baselines are the practical control that separates legitimate novelty from probing and from completed compromise in agent runtime data.
• The operational priority is to make triage fast, deterministic, and identity-aware before agent activity reaches a boundary-crossing stage.

Key terms

• Execution Graph: A record of how an agent or multi-agent workflow made decisions and called tools over time. It is more than an event log because it connects action sequence, policy application, and outcomes, which makes it useful for audit, incident response, and compliance validation.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.
• Attack Attempt: A runtime chain that shows suspicious probing but has not yet produced a completed unauthorized action. The useful distinction is that the chain has crossed into abnormal behaviour without yet producing a successful boundary crossing.
• Boundary Crossing: A completed action that moves an AI agent outside its authorised operational or permission envelope, such as an unauthorised write, an external egress to an unapproved destination, or successful data extraction. In triage, boundary crossing is what often justifies escalation to containment.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and agentic AI identity. It helps practitioners connect identity controls to the runtime decisions that govern modern AI agents.