AI Lab Blog

The Tool-Calling Kill Chain

June 25, 2026

Tags: Agentic AI, Tool Calling, Detection Engineering

Tool calling is where agentic AI becomes operational.

A model that writes a paragraph can be wrong. A model that calls tools can change the environment around it. It can search logs, open tickets, query identity systems, enrich indicators, collect endpoint data, revoke sessions, block traffic, draft notifications, or trigger playbooks.

That is useful. It is also the point where security teams need detection engineering for the agent itself.

The right mental model is a tool-calling kill chain. Not because every tool call is malicious, but because every meaningful tool call has stages: intent, selection, authorization, execution, observation, interpretation, and follow-up. If defenders can observe those stages, they can govern the agent. If they cannot, the agent becomes a black box with hands.

Stage 1: intent formation

Before a tool is called, the agent forms intent. It decides that it needs more evidence, wants to validate a hypothesis, or is ready to recommend action.

This stage is often invisible, but it should not be. The agent should state why it wants a tool.

Bad:

Calling identity_search.

Better:

Calling identity_search to verify whether the suspicious source IP was followed by a successful login for the same user within the alert window.

That reason is not just prose. It is a detection signal. If the stated reason does not match the tool, the workflow can pause. If the agent asks for a high-risk tool without a clear reason, the control plane can require human review.

Stage 2: tool selection

Tool selection is where many agent failures begin. The agent may choose a broad tool when a narrow one would do. It may select a state-changing tool before exhausting read-only checks. It may use raw query access when a structured retrieval function would be safer.

Each tool should have a risk tier and a preferred order of operations. A SOC agent should generally move from read-only evidence collection to interpretation to approval-gated action.

For example, before revoking sessions, the agent should probably use tools like:

• identity event lookup;
• recent session inventory;
• MFA event review;
• asset and user context retrieval;
• incident case check;
• approval request.

If the agent skips directly to revocation, that is not just a UX issue. It is a policy event.

Stage 3: authorization

Authorization should not live inside the model’s confidence.

A model saying “I am confident” is not authorization. A model saying “this is urgent” is not authorization. A model saying “the policy allows it” is not authorization unless an external policy system verifies that claim.

Authorization should be enforced by code. The control plane should evaluate the requested tool, input parameters, user role, agent role, current task, evidence state, incident ID, and approval status.

A useful authorization record might include:

Tool requested: revoke_sessions
Risk tier: high
Requested target: user m.rivera
Incident ID: IR-2026-071
Approver required: yes
Approver present: no
Decision: denied pending approval

The agent can receive the denial and continue safely. It can ask for approval, gather more evidence, or recommend a lower-risk action.

Stage 4: execution

Execution is where the system needs strong schemas.

Free-form tool inputs are dangerous. A tool that accepts arbitrary shell commands, raw SQL, broad API filters, or unconstrained natural language creates a large blast radius. Structured inputs reduce ambiguity and make policy enforcement possible.

Instead of this:

run_query("find suspicious activity for this user")

Prefer this:

search_identity_events({
  "user": "m.rivera",
  "start": "2026-07-01T09:00:00Z",
  "end": "2026-07-01T10:00:00Z",
  "event_types": ["login", "mfa", "session"],
  "max_results": 200
})

The second format can be validated, logged, rate-limited, replayed, and tested. The first is a wish.

Stage 5: observation

After a tool runs, the agent observes the result. This is another failure point.

Tool output may be incomplete, stale, noisy, or attacker-influenced. A search returning no results does not always mean nothing happened. It may mean the query was wrong, the time window was too narrow, the source was delayed, or the user identifier was mismatched.

Agents should be trained and prompted to classify tool observations:

• result supports hypothesis;
• result weakens hypothesis;
• result is inconclusive;
• result failed;
• result conflicts with other evidence;
• result requires human interpretation.

This classification should be logged. It helps reviewers understand how the agent moved from raw output to assessment.

Stage 6: interpretation

Interpretation is where fluent output can become dangerous.

An agent might see a successful login after multiple failures and call it compromise. That may be correct. It may also be the legitimate user finally completing MFA. The tool output is evidence, not conclusion.

Good interpretation should connect claims to evidence and preserve alternatives:

The login pattern is suspicious because the source ASN differs from the user's recent baseline and follows 19 MFA prompts. However, endpoint posture and user confirmation are missing. Confidence: medium.

That kind of output is slower than a crisp verdict. It is also more useful.

Stage 7: follow-up action

The final stage is what the agent does next. Does it ask for more evidence? Recommend escalation? Request approval? Draft a brief? Call another tool?

This is where runaway loops can appear. An agent may keep calling enrichment tools without improving confidence. It may chase every new entity. It may produce more activity than value.

Set loop budgets. Limit tool calls per task. Require the agent to explain what new information a tool is expected to provide. Stop when additional calls are not changing the assessment.

A good agent should know when to say:

Additional autonomous enrichment is unlikely to change priority. Human review is recommended before any state-changing action.

Detection engineering for tool calls

Once tool calls are structured, they can be monitored like any other operational telemetry.

Useful detections include:

• high-risk tool requested without required evidence;
• repeated denied tool calls;
• tool call volume spike by agent or user;
• broad target selection;
• use of raw query tools when scoped tools exist;
• state-changing action after low-confidence assessment;
• tool output ignored in final recommendation;
• prompt-injection content appearing near a tool request;
• agent requesting data outside case scope.

These detections do not mean the agent is malicious. They mean the workflow needs attention.

The bottom line

Tool calling turns AI from language into action. That is the moment security teams should stop thinking only about prompts and start thinking about telemetry.

Every tool call has a chain: intent, selection, authorization, execution, observation, interpretation, and follow-up. Each stage can be logged, constrained, evaluated, and improved.

The safest agent is not the one that never acts. It is the one whose actions are narrow, explainable, authorized, and reviewable. If defenders can see the tool-calling kill chain, they can govern it. If they cannot, the agent is operating in the dark.