Guardrails, approvals and safety
Agent guardrails, the app-level safety check, tool safety levels, approvals, least privilege for signed-in users and visible failures.
App safety rules. An app's Chat (in) node checks each incoming message, and its Chat (out) node checks the selected agent's answer, against the node's Blocked topics and Deny rules: a rule matches when its text appears in the message, ignoring case. The node's On a blocked input or On a blocked answer setting decides what happens: fail the run, answer with a short error message instead, or continue and record the match.
Tool safety levels. Every tool declares a level from safe read to destructive. Toolbox permission scopes limit which levels a node may call.
Approvals. Tools and toolboxes can be marked as requiring approval. When the model calls such a tool, the run pauses before the call executes and the chat shows an approval card with the tool, its arguments and its safety level. Approve resumes the run and executes the call; reject resumes it with an explicit refusal the model sees, so it answers knowing the call was not made. Builders decide in the test chat and in Logs; end users decide in the widget for their own conversations. The decision, who made it and when are recorded on the tool call, and the run trace shows the pause. While a run waits for the decision, its conversation takes no other message.
Least privilege for signed-in users. Authenticated tools run only with the user's own token, and a toolbox must explicitly allow end-user-token tools.
Visible failures. AgentRow does not hide failures. If a tool fails, the model is told what failed; if a retrieval is empty, the log says so; if a session is invalid, the widget shows why. Runs record errors on the exact step where they happened.
#Outbound requests: public addresses only
Every request AgentRow makes on your organisation's behalf goes through an outbound guard: HTTP API, Webhook and Browser tools (including Run test on a tool's page), Webhook (out) deliveries and server-run callbacks, web page imports into a knowledge base, and model and embedding providers at a base URL you set. The guard refuses:
- schemes other than http and https;
- addresses that are not on the public internet: loopback (
localhost), private networks, link-local addresses (including the cloud metadata service), carrier-grade NAT, multicast and reserved ranges, their IPv6 forms, and public names that resolve to any of them; - internal host names such as
*.internalor*.local, and names without a dot; - ports other than 80, 443 and 1024 or above, and database or infrastructure ports among the high ones;
- URLs with credentials in them (
user@host), spaces, control characters, backslashes or a percent-encoded host; - headers aimed at cloud metadata services, proxy and forwarding headers, a
Hostheader that differs from the URL, and line breaks inside a header.
Redirects are checked hop by hop like new requests. A redirect to a refused address, from
https to plain http, or beyond 5 hops is refused. When a redirect leads to another host,
the request loses its credentials (the Authorization and API key headers, the end
user's token). The Browser tool reads at most 2 MB of a page. An organisation's tool
calls and imports can make up to 300 outbound requests a minute; beyond that they fail
with OUTBOUND_RATE_LIMITED until the minute has passed.
What you see when the guard refuses:
- When you save a tool, a provider base URL or a server run's
callback_url, a refused URL is rejected with the reason on the field, for example "localhost is an internal address; AgentRow does not call it." Names are resolved only when a request is made, so a public name that points at a private address saves, and is refused when it is called. - When a request runs, it fails with a named code and a message instead of a
response. A tool call returns the error to the model, and the run's logs record it on
the tool call; Run test on the tool's page shows the same error. Examples:
OUTBOUND_ADDRESS_BLOCKED("… points to a private, local or reserved network address; AgentRow only calls public internet addresses."),OUTBOUND_HOST_BLOCKED,OUTBOUND_PORT_BLOCKED,OUTBOUND_HEADER_BLOCKED,OUTBOUND_REDIRECT_BLOCKEDandOUTBOUND_TOO_MANY_REDIRECTS. - In a web page import, a refused address is flagged on its line before anything is imported, or the document fails with the reason (Knowledge bases).
To reach a service on your own network, publish it at a public https address with its own authentication. For embeddings without a server of your own, use AgentRow Embedding (Models and providers).
#Tool capabilities
Tool capabilities are the rules for what a tool may be. AgentRow sets them for every
organisation; they are not a setting on a tool or an organisation. Tool types that would
act on the AgentRow server itself are disabled: file (the server's file system),
database (a database file on the server), code_execution (running model-written
code) and agent (calling another agent as a tool). Saving a tool of one of these types
is refused with TOOL_TYPE_DISABLED ("Tool type file is disabled: it would act on the
AgentRow server itself."), and an existing tool of these types does not run: its calls
fail with the same code. A tool the runtime cannot build fails by name; nothing is
substituted for it. The types the dashboard offers are listed in Tools.
Updated 30 September 2026