Tool-call argument analysis is the missing AI attack detection layer

At a glance

What this is: This article distinguishes tool-call logging from tool-call analysis and shows why the argument layer inside an AI agent’s call can carry the attack itself.

Why it matters: It matters because IAM and security teams governing agentic AI need visibility into what an agent passes to a tool, not just which tool it invoked, or compromise can look like normal activity.

👉 Read ARMO's analysis of tool-call argument analysis for AI attack detection

Context

AI tool-call monitoring is often treated as complete when teams can see which tool fired, when it fired, and how often. That is only invocation telemetry, not argument analysis. In agentic systems, the exploitable behaviour frequently sits inside the parameter values, payload shape, operation verb, or provenance of the data passed to a tool.

For IAM and NHI programmes, this is the same governance problem seen with other machine identities: permissions alone do not describe intent or abuse potential. When an AI agent can act only through tool calls, the contents of those calls become the real control surface. That makes argument-level visibility relevant to NHI governance, agentic AI oversight, and runtime access control.

The article’s starting position is typical of current AI security practice: teams instrument the action, but not the meaning inside the action.

Key questions

Q: How should security teams detect malicious AI tool calls without relying only on logs?

A: Security teams should preserve structured arguments, payload metadata, and provenance for each tool call, then compare them to the specific agent’s normal behaviour. A call is only half the signal. The dangerous part may be an out-of-range value, an oversized payload, a write operation from a read-only workflow, or data originating in untrusted retrieved content.

Q: Why do AI agents need behavioural baselines for tool-call analysis?

A: Because the same call can be normal for one agent and malicious for another. Baselines let teams judge the argument layer against what that specific agent usually sends, rather than using fixed thresholds that either over-alert or miss abuse. In practice, per-agent baselines are what turn noisy telemetry into usable detection.

Q: What do security teams get wrong about agentic AI security tools?

A: The most common mistake is treating agentic AI security as an extension of an existing category such as NHI, endpoint, or DSPM. That view misses the fact that agents operate across multiple deployment patterns and require both posture controls and runtime response. A narrow tool can be useful, but it is not comprehensive governance.

Q: How should security teams manage permissions for AI agents?

A: Security teams should regularly assess and update the permissions granted to AI agents to ensure they align with their intended scope. Implementing a governance framework that details access levels and usage policies is crucial to mitigate risks. Moreover, continuous monitoring can detect irregular permissions that may increase exposure.

Technical breakdown

Invocation layer vs argument layer in AI tool calls

A tool call has two separable layers. The invocation layer records the event itself: tool name, order, frequency, and timestamp. The argument layer contains the values passed, the payload size and shape, the operation requested, and where each field came from. Most logging and detection stacks stop at the event record, which is enough to prove a call happened but not enough to show whether the call carried abuse. In agentic systems, that matters because the model cannot change the outside world except by issuing tool calls. The attack often lives in the arguments while the invocation still looks authorised.

Practical implication: Treat tool-call logs as incomplete unless they preserve structured arguments, provenance, and per-agent behavioural context.

Why payload shape and value distribution expose abuse

Argument analysis works because legitimate agent behaviour forms a behavioural envelope. A value outside the normal range, a payload much larger than the agent typically sends, or a write operation from a read-only workflow all stand out against that envelope. These signals are not universal rules. They are comparisons against what that specific agent has historically done. That is why the same call can be normal in one agent and malicious in another. In practice, argument analysis is closer to behavioural detection than to static policy enforcement, and it depends on reliable per-agent baselines.

Practical implication: Build baselines for each agent identity, then flag calls that break its normal value range, payload size, or operation pattern.

Provenance matters when retrieved content steers actions

One of the most important argument-layer signals is provenance. If a tool argument originates in untrusted retrieved content, the agent may be carrying attacker-controlled instruction inside a field that appears syntactically valid. This is the mechanism behind indirect prompt injection paths and related agent hijacking patterns. The tool invocation remains allowed, but the source of the parameter is compromised. That makes provenance a governance issue as much as a detection issue, because a clean allowlist cannot tell whether the value came from the task or from hostile context.

Practical implication: Track where agent arguments come from, and treat untrusted retrieved content as a distinct risk source rather than just another input.

Threat narrative

Attacker objective: The attacker wants the agent to perform harmful work through a normal-looking tool call whose contents, not its invocation, carry the compromise.

1. Entry occurs when an attacker plants malicious content or otherwise influences the agent’s retrieved context so the tool argument is steered from outside the intended task.
2. Escalation happens when the agent issues a permitted tool call whose argument value, payload, or operation crosses the intended behavioural envelope while the invocation itself still looks authorised.
3. Impact follows when the authorised tool executes the attacker-shaped contents, enabling data exposure, state change, or downstream misuse without a suspicious call name or destination.

NHI Mgmt Group analysis

Argument-layer visibility is now a governance requirement for agentic AI. Logging tool invocations gives teams a record of activity, but not a record of intent or abuse. When an agent’s only action primitive is the tool call, the parameter values, payload shape, and provenance become the real control surface. That means AI governance cannot stop at audit logs. Practitioners should treat structured tool-call telemetry as part of identity and access governance for agents, not as optional observability.

Agentic AI creates a new kind of privilege problem: authorised tools with unauthorised contents. Traditional IAM assumes the risky question is whether a subject may call a resource. In agentic systems, the harder question is whether the subject is using an allowed tool to move forbidden data or perform an unintended operation. This is a distinct control gap, and it deserves its own policy, detection, and review model. The practical conclusion is that access approval without argument inspection leaves a live blind spot.

Per-agent behavioural envelopes are the right abstraction for tool-call detection. Static thresholds fail because agents are non-deterministic and workload-specific. A large payload can be normal for one agent and exfiltration for another. The named concept here is argument-layer blind spot: the gap that appears when teams can see the call but not the contents that make it dangerous. Practitioners should baseline each agent’s normal argument patterns before they rely on any detection outcome.

AI security teams should align tool-call analysis with NHI governance, not treat it as a separate novelty domain. Agent identities are still identities, and their tool permissions still need lifecycle control, least privilege, and review. The difference is that runtime behaviour adds another dimension to entitlement review. That makes this a cross-discipline problem for IAM, PAM, AI security, and SOC teams. The practical conclusion is that agent governance must cover what the agent is allowed to do and what it is allowed to pass.

What this signals

Argument-layer blind spot: the next control gap in agentic AI is not whether a tool was called, but whether the contents of that call were governed. Teams that already classify AI agents as non-human identities should extend policy, review, and detection to arguments, provenance, and payload shape.

The practical signal for programmes is that runtime governance must move closer to the agent’s action boundary. That means pairing behavioural baselines with identity lifecycle controls and using the NIST Cybersecurity Framework 2.0 to anchor detect and respond workflows around agent misuse, not just perimeter events.

For practitioners

• Instrument structured tool-call telemetry Capture tool name, arguments, payload size, operation type, and provenance for each agent call so the security team can analyse what the agent passed, not just what it invoked.
• Build per-agent behavioural baselines Define normal value ranges, payload envelopes, and operation patterns for each agent identity, then flag calls that fall outside that observed envelope.
• Track argument provenance from retrieved content Mark whether a parameter came from user task data, retrieved documents, or external context so indirect prompt injection paths can be separated from ordinary input.
• Join tool-call anomalies to runtime evidence Correlate argument anomalies with file access, network calls, and process activity so an odd parameter is evaluated with the action it triggered.
• Review agent permissions as NHI entitlements Treat each agent as a governed machine identity and reassess whether its allowed tools still match its current task scope and risk appetite.

Key takeaways

• AI tool-call logs are incomplete when they stop at invocation and ignore the argument layer that can carry abuse.
• Per-agent baselines, provenance tracking, and structured telemetry are the controls that make tool-call analysis useful.
• Agent governance should be treated as non-human identity governance with runtime inspection, not just access approval.

Key terms

• Invocation Layer: The invocation layer is the visible record that a tool call occurred. It includes the tool name, time, frequency, and sequence, but not the deeper semantics of what the agent passed inside the call. It is useful for audit, but incomplete for detecting argument-level abuse.
• Argument Layer: The argument layer is the content inside a tool call, including parameter values, payload size and shape, operation type, and provenance. This layer often contains the security signal in agentic systems because the call can be authorised while the contents are malicious or manipulated.
• Behavioural Envelope: A behavioural envelope is the observed range of normal activity for a specific agent identity. It includes the values, sizes, and operations the agent usually produces, which lets security teams flag calls that are unusual for that workload even when the underlying tool is allowed.
• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.

What's in the full article

ARMO's full blog covers the operational detail this post intentionally leaves for the source:

• Examples of argument-layer signals such as abnormal value ranges, oversized payloads, and write operations from read-only agents
• How the vendor maps tool-call analysis to runtime correlation across application, container, Kubernetes, and cloud telemetry
• How its Application Profile DNA baseline is used to learn per-agent behaviour before enforcement begins
• The vendor's guidance on handling managed runtimes where tool-call internals are partially opaque

👉 The full ARMO post expands on argument-layer signals, behavioural envelopes, and runtime correlation examples.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners translate runtime behaviour into governed controls.