Understand Gateway policy decisions

All Gateway guides

The path a request takes

1. Identify the agent. Gateway validates a workspace-specific agent credential and loads the active connection and policy. Revoked or invalid credentials are rejected.
2. Check the tool. Gateway fetches the upstream tool catalog again, compares the requested tool's definition with the reviewed definition, validates arguments against its supported schema, and checks your allowlist and agent/tool controls.
3. Reserve the decision. Before forwarding, Gateway atomically checks the current credential, agent block, policy revision, request ID and capacity, then stores the decision. If this cannot be done safely, it does not forward.
4. Forward or stop. Allowed requests proceed. Policy violations are flagged and forwarded in Monitoring, or blocked in Enforcement. Certain operational and access failures stop requests in both modes.
5. Record the outcome. Requests show whether a response was received, the request was not sent, or its outcome is uncertain. Signed webhook notifications can be sent separately; a slow receiver does not delay enforcement.

Gateway's decisions are deterministic. An LLM does not decide whether a request is allowed, flagged or blocked.

Checks performed today

Tool allowlist

Rule shown in request history: tool_not_allowed.

You choose the tool names allowed by the active policy. A tool outside that list is a policy violation. For example, a policy allowing read_note will flag delete_note in Monitoring and block it in Enforcement. A tool's name alone does not prove what it actually does; review the tool server and definitions before approval.

Definition changes

Rule shown in request history: definition_changed.

Gateway fingerprints the full reviewed tool definition, including its schema and any supplied description or metadata. It compares the requested tool with the current catalog on each call. A changed, removed, newly introduced or unreviewed tool produces a definition-change finding. Monitoring flags and forwards; Enforcement blocks.

This detects changes to the advertised definition. It cannot prove that a malicious server implements the advertised behavior or detect an implementation change that leaves the definition unchanged. Discovery and tool execution are separate upstream operations, so the check is not an atomic guarantee against a server changing between them.

Argument validation

Rule shown in request history: arguments_invalid.

Arguments are checked against the reviewed input schema. Supported checks include required properties, declared property names, value types, string enums and lengths, numeric minimum/maximum values, and array item types and lengths. Objects must reject undeclared properties. Invalid arguments are flagged and forwarded in Monitoring, or blocked in Enforcement.

The beta supports a deliberately limited JSON Schema subset. Supported types are object, array, string, number, integer, boolean and null. It does not support references, unions, regular-expression patterns or arbitrary JSON Schema keywords. Unsupported schemas are rejected during connection verification rather than silently treated as validated. Tool-call payloads are limited to 64 KiB, with bounded nesting.

Agent/tool deny rules

Rule shown in request history: explicit_deny.

From a request's Investigate action, an administrator can create a deny rule for that exact agent and tool. Monitoring flags matching requests; Enforcement blocks them. An explicit deny takes precedence over an allowlist entry or temporary exception. It does not automatically match semantically similar tools or requests from other agents.

Temporary exceptions

Rule shown in request history: exception.

An administrator can allow an otherwise unapproved tool for one agent, with a reason and expiration of up to seven days. The definition must still match and arguments must still be valid. Exceptions do not override agent blocks or explicit deny rules. Replacing a server ends temporary exceptions for the tools that server stored. Other servers keep theirs. Revoke an exception from Setup & policy → Active request controls.

Agent blocks

Rule shown in request history: agent_blocked.

Blocking an agent stops its future routed requests in both modes. This is different from a deny rule, which is advisory in Monitoring. Use an agent block when you need an immediate stop. Unblock, rotate or revoke credentials under Setup & policy → Agents and credentials. Already-admitted work cannot be recalled.

Operational and access safeguards

Invalid or revoked credentials, disconnected Gateway connections, replayed tool-call IDs, stale policy state, admission/storage failures, and exhausted capacity stop forwarding in both modes. Upstream discovery failures (discovery_failed) stop that server in both modes. A call that names a missing or ambiguous server uses server_unavailable and is blocked in both modes; it is not forwarded. One server's discovery failure, bad credential, or disconnect stops only that server. Monitoring does not bypass these safeguards.

Upstream connections require public, standard-port HTTPS with certificate validation. Gateway resolves and validates every returned IP address before each connection, pins the connection to those addresses, and rejects redirects, private destinations, URL credentials and query parameters. Credentials for the agent and upstream server are kept separate.

Under Setup & policy → Request capacity, administrators can set a shared workspace limit from 0 to 120 authenticated requests per UTC minute. Model requests, MCP protocol requests and connection checks share this capacity. Rejected attempts also consume capacity; changing the limit does not reset the current minute. Zero pauses new admission, while administration remains available. Separate tool safeguards allow 10,000 tool calls per rolling day and eight recent pending tool calls. These tool counts are capacity controls, not token or dollar metering for upstream tool services. Malformed or unauthenticated calls and failures before a request can be reserved may be rejected without a row in Requests or a webhook notification. The request list is an admission history, not a complete network access log.

What Gateway does not claim to detect

Gateway's live checks are separate from Foo Guard's configuration-scan rule catalog and security score. It does not rerun every configuration-scan rule on each tool call or assign a new scan grade to each request.

This release does not inspect prompts or tool results for semantic prompt injection, malicious intent, secret leakage, malware, or harmful business actions. It does not sandbox the upstream tool server, automatically discover traffic that bypasses it, or learn an agent's behavioral identity over time. Use it for the deterministic tool policy and admission controls described above, alongside appropriate server-side authorization and isolation.