Action & Tool Use Controls

Each agent has a documented tool allowlist. Tools outside the allowlist cannot be invoked at runtime.

The agent operates against a documented tool allowlist; tools outside the list are inaccessible at runtime. The allowlist is enforced by the integration layer, not by trusting the agent's own judgment. This is the foundational ACT control — without it, no other action-control is meaningful because the agent's capability surface is unbounded.

Each tool has a per-tool authorization policy specifying when it may be invoked, with what parameters, and on what data.

Beyond the binary allowlist, each tool the agent can invoke has a per-tool authorization policy specifying the conditions under which it may be called, the parameters it may receive, and the data it may operate on. This fine-grained control prevents an agent from using an allowed tool in an unauthorized way — for example, using a permitted email tool to send to an unauthorized recipient list.

Actions classified as irreversible or high-impact — including financial transactions, deletions, external communications, permission changes, and public publishing — require pre-execution review.

For irreversible actions (deletions, financial transfers, customer-facing communications above a threshold, permission changes, public publishing), the agent does not act unilaterally. A pre-execution review — either by a human reviewer or by a deterministic policy engine — must clear the action before it executes. Confirmation binding across multi-agent chains is governed by MAS-03.

Rate limits and cost ceilings are enforced on tool invocations per agent, per session, and per tenant.

Per-agent, per-session, and per-tenant rate limits and cost ceilings are enforced on tool invocations and customer-facing actions. The limits are tuned to expected volume and are enforced at the integration layer. Rate-limit breaches are logged and surfaced for review, preventing runaway agents from consuming resources or taking actions at a scale inconsistent with their specification.

Loop and recursion detection is implemented, with automatic suspension on suspicious patterns. In multi-agent topologies, MAS-05 extends detection across agents.

Loops in agent action sequences — repeated tool calls, circular reasoning patterns, unbounded retries — are detected and trigger automatic suspension. In multi-agent topologies, MAS-05 extends detection across agent boundaries. This control prevents runaway agents from consuming resources, taking repeated actions, or entering infinite loops that bypass rate limits through creative variation.

Blast-radius limits are enforced: maximum records modified per operation, maximum dollar value per transaction, maximum recipients per outbound message, and equivalent caps for other action classes.

Blast-radius limits prevent a single agent action from causing irreversible harm at scale. They are enforced by the integration layer (or by a guardrail proxy) rather than by trusting the agent itself. Limits cover records modified, monetary values, recipient counts, and equivalent caps for other action classes. Aggregate caps across multi-agent chains are governed by MAS-07.

A kill switch allows authorized operators to immediately suspend any agent in production. Propagation behavior across multi-agent chains is governed by MAS-08.

Emergency suspend can be invoked by the risk owner or authorized operator and takes effect within a documented latency. The kill switch is the last line of defense — when all other controls have failed, this is what prevents ongoing harm. Propagation behavior across multi-agent chains is governed by MAS-08. The kill switch is tested at a documented cadence.

Tool result validation is performed before consumption: schema validation, sanity checks, and screening against known malicious signatures.

Outputs returned by tools the agent calls are validated before being incorporated into further reasoning or action. Validation includes schema validation, sanity checks (e.g., result size, expected fields), and screening against known malicious signatures. This control prevents a compromised or malfunctioning tool from injecting harmful data into the agent's decision path.

A dry-run or shadow mode is available for newly introduced tools, allowing observation of intended behavior without live effect.

For newly introduced tools or tool-configuration changes, a dry-run or shadow mode allows the agent's intended behavior to be observed without live effect. This control provides a safe path for introducing new capabilities into production without risking unintended consequences, and generates evidence that the tool behaves as expected before live activation.