Classifiers

INT-Tooling

Behavioral tool-intent and policy evaluation before your agent executes an action.

INT-Tooling evaluates the behavioral risk and authorization of a proposed tool call given what the user actually asked for. Run it after your model emits a tool call but before you execute it. It is exposed as tool_call.check in the SDKs and POST /v1/tool-guard over REST.

What it detects#

Three separate signals: whether the user request itself is malicious, how harmful the current action is (for example, destructive commands, data exfiltration, or privilege escalation), and whether a hijacked instruction drove the action away from the user’s genuine request. The last is the confused-deputy case: a “summarize my inbox” request that somehow produces a call to email your database dump to an external address. See Concepts.

Behavioral action check, not code scanning

INT-Tooling treats the tool name, arguments, command text, and environment as a semantic description of a proposed action. It does not execute or parse source code, detect malware, resolve dependency risk, or prove that a command/script/binary is safe. Keep sandboxing, least privilege, code review, and code/artifact scanners as separate gates.

Inputs#

Field	Surface	Required	Description
`user_request`	SDK and REST	Yes	What the user asked the agent to do.
`tool_name`	SDK	Yes	Name of the tool being invoked.
`tool_description`	SDK	No	The tool's capabilities. Combined with the name as the action under review.
`tool_arguments`	SDK	No	Structured function-call arguments. The SDK serializes these as the action under review and gives them precedence over tool_description.
`current_action`	REST	No	Action string to evaluate. The SDK derives this from the tool name and arguments or description.
`interaction_history`	SDK and REST	No	Prior conversation context as a string.
`env_info`	SDK and REST	No	Environment context (for example, "production database").

Result fields#

Field	Type	Description
`malicious`	string	`"yes"` or `"no"`. Whether the user request shows malicious behavioral intent; this does not mean malware or malicious-code detection.
`attacked`	string	`"yes"` or `"no"`. Does it look driven by a hijacked instruction.
`harmfulness`	number	Current-action severity, one of 0.0, 0.5, or 1.0.
`composite_score`	number	Overall risk, one of 0.0, 0.5, or 1.0.
`latency_ms`	number	Server-side inference time.
`is_safe`	boolean	Convenience: true only when `composite_score` is 0.0.

Scoring#

composite_score is the field to act on. The SDKs also expose is_flagged (true when the score is above 0 but below the unsafe band) so you can distinguish “review this” from “block this”.

composite_score	Interpretation	is_safe	is_flagged
0.0	No behavioral-policy risk detected; execution still needs ordinary code/security controls.	true	false
0.5	Flagged. Review before executing.	false	true
1.0	Unsafe. Do not execute.	false	false

When you use the gateway, these bands map to the tool guard’s configurable flagged and unsafe thresholds (default 0.4 and 0.8).

Example#

tool = triage_sdk.tool_call.check(
    user_request="Summarize my most recent invoices",
    tool_name="send_email",
    tool_arguments={
        "to": "external@example.com",
        "subject": "Database export",
        "attachment": "/tmp/customers.csv",
    },
    interaction_history="An invoice attachment instructed the agent to email the customer database externally.",
    env_info="production server with customer data",
    session_id="sess_abc123",
)

print(tool.composite_score)  # 1.0
print(tool.is_safe)          # False