How Gateway works

Your goal: understand and control agent tool use

Gateway sits between an agent's MCP client and a tool server you connect. It checks each routed tool call against the policy you reviewed, records its decision, and either forwards or stops it. Use the Requests page to investigate activity and take action without digging through server logs.

Start with Monitoring & Audit to learn which tools your agents use. This is a recommendation, not a requirement: you can start with Enforcement immediately. Only traffic routed through Gateway is inspected. An agent that can still reach the upstream directly can bypass it; restrict direct upstream access separately when you need enforced protection.

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, and activating a replacement policy ends prior temporary exceptions. 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) also stop requests in both modes. 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.

The beta limits each workspace to 120 authenticated protocol/connection-check requests per minute, 10,000 tool calls per rolling day and eight recent pending tool calls. 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.

Read decisions and outcomes separately

Allowed means the policy permitted forwarding. Flagged means Monitoring found a policy violation but forwarded the request. Blocked means Gateway stopped forwarding. A completed scan elsewhere in Foo Guard is not a Gateway decision.

Response received means the upstream returned a valid protocol response; the tool can still report an application error. Not sent means Gateway blocked the request. Awaiting outcome means the outcome has not been recorded yet. Outcome uncertain means execution may have occurred, for example if a response or outcome write was lost. Never automatically retry the underlying tool call after an uncertain outcome. Use unique tool-call IDs across client restarts; duplicate IDs are rejected after reservation.

Arguments and responses are processed in memory but are not retained in request history. History contains agent/tool identifiers, rule, mode, decision, policy version, outcome and timestamps. Administrators' reasons are recorded for administrative changes; do not put secrets in them.

Investigate and respond

Open Gateway → Requests, filter by agent, exact tool name or decision, and select Investigate. Review the rule and outcome before choosing an action:

• Mark reviewed to dismiss the concern from the loaded in-app alert view.
• Add an expiring exception for this agent and tool when the access is justified.
• Add a deny rule for this agent and tool when it should violate policy.
• Block the agent to stop its future requests in both modes.

Use Load older requests for older history. Refresh explicitly to see new activity. The Agent behavior view summarizes the loaded requests and can flag a configured five-minute volume threshold. It is an observed activity summary, not a trained behavioral fingerprint, and depends on the loaded history and filters.

For alerts without an open browser, configure signed webhook notifications. They cover selected blocked, flagged and uncertain request events. Volume summaries and learned anomaly detection do not currently produce webhook events.

Connect safely and verify the behavior

1. In Setup & policy, choose a mode, allowed tool names and reason, then save a draft. Saving alone does not change live protection.
2. Enter an authorized public HTTPS MCP server URL and its optional bearer credential. Verify the connection, review the exact saved policy and discovered definitions, then activate.
3. Register an agent and securely store its one-time credential. Configure its MCP client to use your Foo Guard site's /api/gateway/mcp endpoint with Authorization: Bearer <agent credential>.
4. Make a harmless allowed tool call and confirm it appears in Requests. Check a harmless disallowed call to verify your chosen mode.

For an inert example, connect https://fooguard.com/api/gateway/demo, allow read_note, and try delete_note. That tool only simulates a deletion. Monitoring should flag and forward the simulation; Enforcement should stop it before forwarding. Never use a destructive production operation as your first enforcement test.

This beta supports stateless MCP 2025-06-18 tool servers using JSON responses, up to 64 tools and the supported closed schemas. It does not support streaming, OAuth, sessions, private-network servers or every MCP implementation. Agent registration is credential-based; it does not attest the identity of the software or person holding the credential.

What Gateway does not claim to detect

Gateway's live checks are separate from Foo Guard's configuration-scan rule catalog and risk 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.