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

At a glance

What this is: ARMO argues that AI attack detection fails when teams log tool invocations but do not inspect the arguments inside those calls.

Why it matters: IAM, AI security, and NHI teams need argument-level visibility because an authorised tool call can still carry malicious contents, making the call log alone an incomplete control.

Context

A tool call is the only way an AI agent can act outside its own reasoning, so the call itself becomes the security boundary as soon as the agent can read, write, send, or delegate through tools. Logging the event is useful, but it does not answer whether the arguments inside that event are normal for the agent, which is where abuse hides.

This matters to AI agent governance and NHI security because the agent’s effective identity is expressed through its allowed tool actions and the contents of those actions. If defenders only observe the invocation layer, they may preserve auditability while missing the one layer that distinguishes routine automation from malicious behaviour.

Key questions

Q: What breaks when AI tool-call arguments are not inspected?

A: Detection collapses to a record of activity rather than a read of behaviour. The tool name, timestamp, and rate can all look normal while the malicious part sits in the value, payload shape, operation, or provenance inside the call. That leaves teams with audit logs but no meaningful way to separate routine automation from abuse.

Q: Why do authorised AI agent tool calls still create exfiltration risk in practice?

A: Authorised tool calls can still leak data because the dangerous part is often the parameter value, not the function name. If an agent is allowed to send email, query a database, or open a ticket, a malicious argument can redirect output, expose secrets, or trigger unintended actions while the request still appears normal to identity, allow-list, and behavioural controls.

Q: How do security teams know whether tool-call analysis is actually working?

A: They should be able to explain why a specific argument was flagged: out-of-range values, abnormal payload size, an unexpected write operation, or provenance from untrusted content. If the control cannot produce that reasoning at the per-agent level, it is probably still only logging invocations rather than analysing attacks.

Q: How should teams govern managed agent platforms with limited telemetry?

A: They should treat missing tool-call internals as a governance constraint, not a monitoring inconvenience. If the platform does not expose argument data, provenance, and operation context, the agent should be restricted to low-impact tasks until visibility improves. Security decisions should follow observability, not precede it.

Technical breakdown

Invocation layer versus argument layer

Tool-call telemetry has two layers. The invocation layer records that a tool was called, at what rate, and in what sequence. The argument layer carries the parameter values, payload size, operation type, and provenance of each field. Most observability stacks stop at the first layer because it is easy to log and correlate. That is enough to confirm that an action occurred, but not enough to tell whether the action’s contents are suspicious. For AI agents, the argument layer is where the security meaning lives because the model does not leave the system through thought alone. It leaves through a tool call, and the contents of that call are what determine whether the action remains routine or becomes abuse.

Practical implication: Instrument framework callbacks and runtime telemetry so the arguments, not just the tool name, are available for detection and review.

Why argument analysis needs a per-agent behavioural envelope

Argument analysis only works when each call is judged against the normal behaviour of the specific agent that issued it. A payload that is routine for a bulk-export agent may be anomalous for a summarisation agent. The same is true for values, operations, and provenance. Static thresholds fail because they ignore workload context, while global allowlists fail because agent behaviour is non-deterministic and role-specific. The better model is a behavioural envelope built from observed runtime data. That envelope captures what this agent usually passes, not what an abstract policy says any agent should pass. In practice, this is what turns a strange parameter from noise into a signal.

Practical implication: Build baselines per agent identity and compare each new call against observed value ranges, payload shapes, and operation history.

Why provenance is part of tool-call security

Argument provenance tells you whether a value came from the agent’s task or from untrusted retrieved content. That matters because a well-formed parameter can still be attacker-controlled if the agent ingested it from a document, ticket, or web page. The call may look syntactically correct and still be malicious in origin. This is especially important in indirect prompt injection scenarios, where the payload is not an obvious command but a piece of content that steers the agent into a dangerous tool call. Provenance analysis therefore extends detection from content inspection to source inspection, which is a more reliable way to spot instruction smuggling.

Practical implication: Track whether argument values originated from trusted task inputs or from retrieved content before allowing the call to execute.

NHI Mgmt Group analysis

Argument-level analysis is the missing control plane for AI agents. Invocation logging proves only that a tool call occurred, which is useful for audit but insufficient for attack detection. The security decision sits inside the parameter values, payload shape, operation choice, and provenance, because that is where authorised action becomes unauthorised behaviour. For practitioners, this means tool-call telemetry must be treated as security data, not just observability data.

AI agents create a new form of identity problem: authorised execution with untrusted contents. In human IAM and classic NHI governance, the question is usually whether the caller is allowed to act. Here, the more important question is whether the contents of the allowed action are within the agent’s normal behavioural envelope. That shifts governance from access review to runtime inspection, and it is a material change for AI agent identity security.

Normal-tool, abnormal-argument is a distinct attack pattern that deserves its own name: argument smuggling. The tool, destination, and sequence can all appear legitimate while the malicious intent is carried in values the log records but the detector ignores. This is not a variant of simple tool misuse, because the action itself may remain permitted. For defenders, the relevant control question becomes whether the platform can read the call deeply enough to distinguish routine automation from hidden abuse.

Managed agent runtimes complicate visibility, not the security requirement. When the runtime hides tool-call internals, teams lose the very telemetry needed to evaluate argument provenance and behavioural drift. That does not reduce the risk; it just pushes organisations toward lower-blast-radius use cases until deeper inspection is available. The governance lesson is straightforward: if you cannot inspect the contents of agent actions, you should limit what those agents are allowed to do.

What this signals

Argument smuggling: AI agent defenders need a named control problem for cases where the tool is legitimate but the contents are not. The security boundary is no longer the existence of the call, but the runtime meaning of the values carried inside it, which pushes governance toward behavioural inspection at execution time.

Teams running agentic systems should assume that invocation-only logging leaves a detection gap whenever the malicious action is encoded as data rather than as a different tool name. The practical response is to align agent permissions with what can be observed, because opaque runtimes create governance debt the moment they are allowed to do more than low-risk work.

For practitioners

• Instrument tool-call argument telemetry Capture parameter values, payload sizes, operation types, and provenance flags for each agent call, not just the tool name and timestamp.
• Build per-agent behavioural baselines Baseline normal argument ranges and payload shapes for each agent identity so anomalies are judged against its own runtime history.
• Flag provenance from retrieved content Treat arguments sourced from untrusted documents, tickets, or web content as higher risk than values coming from the agent’s direct task context.
• Restrict opaque managed runtimes Keep managed agent environments with limited tool-call visibility on lower-blast-radius tasks until argument-level telemetry is available.

Key takeaways

• AI tool-call logs are incomplete when they stop at invocation metadata and ignore the arguments that carry the attack.
• The most useful signal is per-agent behaviour, because the same payload, value, or operation can be normal for one agent and suspicious for another.
• Managed agent runtimes with limited telemetry should be treated as lower-trust environments until argument-level visibility is available.

Key terms

• 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.
• 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.
• Behavioural Envelope: A behavioural envelope is the observed range of normal activity for a specific workload or agent. It includes tools used, destinations reached, volume moved, and processes spawned, giving detection a reference point for spotting deviations that configuration-only checks would miss.
• Argument Smuggling: Argument smuggling is the use of legitimate tool calls to carry malicious content in values, payloads, or provenance that appear acceptable at the invocation layer. The call itself is allowed, but the data embedded in it changes the security meaning of the action.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners build the identity and control foundations needed to govern modern automation and AI-driven access.