RiskMandate v1.34.4
The business case · Gateway and egress proxy for agent traffic

agentgateway, by the risk it changes

An open-source proxy for agent traffic, run by the deployer. Its documentation describes three things an agent deployment would feel: outbound destinations allowed only by route, MCP tools filtered by policy so an agent never sees the ones it is not allowed, and access logs kept in a database. Its documentation also says where it fails closed and where it fails open, which is part of the case.

Open source: Apache-2.0 · Linux Foundation (Agentic AI Foundation) · get involved

The deployment: The model's typical deployment, with the answers this project addresses stated as they are without it: can reach the general internet; can read and change the data in its reach; what it did cannot be reconstructed.

The model: the RiskGraph Explorer's 49 facts, 49 risks and 10 roles, copied into this site with its provenance; the register below is computed, not written. How.

01 · What it does

In its own words, and nothing more.

  • An egress proxy that decides where outbound traffic may go. “The destinations that clients are allowed to reach. A destination that matches no entry has no route.” · agentgateway.dev, read 24 September 2026
  • Authorisation on MCP tool calls, with disallowed tools removed from what the agent is shown. “If a tool or other resource is not allowed, the gateway automatically filters it from the list response, so unauthorized clients never see it.” · agentgateway.dev, read 24 September 2026
  • Access logs, to stdout by default and to a database when configured. “If neither config.logging.database nor config.database is set, no database log store is initialized and access logs are written to stdout only.” · agentgateway.dev, read 24 September 2026
02 · The answers it changes

Same deployment, different answers.

The model asks sixteen questions about an agent deployment. A product’s effect is written as the answers it changes, and each change says what kind of change it is: a statement of what is true, an expectation the agent is asked to meet, a setting, or a boundary enforced by something the agent’s grant does not include.

The questionWithout itWith itHow, and who holds it
Can it reach anything outside your network?Yes, general internetAllow-listed onlya boundary, held by the deployer. Only for traffic that uses the proxy. A client selects it through the standard environment variable; blocking direct egress for an agent that ignores that variable is left to the deployer. “The destinations that clients are allowed to reach. A destination that matches no entry has no route.” · agentgateway.dev, read 24 September 2026
What can it do with that data?Reads and changes itReads ita boundary, held by the deployer. Only if the policy leaves the write tools out, and only for tools reached through the gateway. Rules match on the tool name. “If a tool or other resource is not allowed, the gateway automatically filters it from the list response, so unauthorized clients never see it.” · agentgateway.dev, read 24 September 2026
Could you reconstruct what it did last Tuesday?NoPartlya setting, held by the deployer. Partly: the log covers what passed through the gateway, and nothing is persisted unless a database is configured. “If neither config.logging.database nor config.database is set, no database log store is initialized and access logs are written to stdout only.” · agentgateway.dev, read 24 September 2026
03 · The register, before and after

7 retired, 1 new, 22 unchanged.

Computed from the model for the deployment above: every risk that holds without it, and every risk that holds with it. A new entry is either one the change brought to light, where an answer replaced a don’t know, or a narrower risk in place of a wider one, where the answer moved from no to partly. Either way the register is more exact, and a register that grows because something was found is working.

7retired
1new
29 → 23entries on the register

Retired

RISK-13
What the agent did cannot be reconstructedoperational · SRE / platform on-call, CISO
RISK-16
Regulated data is modifiable by an agentoperational · CISO, DPO, Customer-facing service owner, Chief Product Officer
RISK-26
Records the organisation answers for can change without a person deciding they shouldoperational · Board
RISK-28
The agent can reach systems outside the estateoperational · CISO, CFO
RISK-33
The organisation could not account for what its agent didoperational · Board
CORP-4
Unquantified financial exposure — the organisation cannot price its own downsidecorporate · CFO, Board
CORP-5
Accountability failure — the organisation cannot demonstrate who decided whatcorporate · CEO, Board

New

RISK-24
Only part of what the agent did can be reconstructedoperational · SRE / platform on-call
04 · From the operator to the board

Who carries less, and who carries the same.

Each risk is assigned to the roles it belongs to, and each role reports to another until the board. The count beside each role is the entries it holds without the product and with it.

Operators

who run it, and are paged when it goes wrong
SRE / platform on-call9 → 9retired RISK-13 · new RISK-24
Customer-facing service owner3 → 2 −1retired RISK-16

Owners

who own what it may touch, and can say what happened
Platform owner3 → 3
CISO11 → 8 −3retired RISK-13, RISK-16, RISK-28
DPO7 → 6 −1retired RISK-16

Executives

who answer for speed, product, cost and the whole
CTO3 → 3
Chief Product Officer5 → 4 −1retired RISK-16
CFO2 → 0 −2retired RISK-28, CORP-4
CEO4 → 3 −1retired CORP-5

The board

who must be able to defend how it is run
Board8 → 4 −4retired RISK-26, RISK-33, CORP-4, CORP-5

At the board: the corporate register

Corporate risks have no facts of their own. They hold while any risk that leads into them holds, so a single product rarely retires one. What it changes is how many reasons the board is being given.

CORP-1
Regulatory exposure — the organisation may be operating outside obligations it is subject tostill holds · risks leading into it: 4 before, 2 after
CORP-2
Customer harm — customers may be affected by decisions or changes nobody madestill holds · risks leading into it: 4 before, 2 after
CORP-3
Operational resilience — the organisation may be unable to restore a service it depends onstill holds · risks leading into it: 1 before, 1 after
CORP-4
Unquantified financial exposure — the organisation cannot price its own downsideretired · risks leading into it: 1 before, 0 after
CORP-5
Accountability failure — the organisation cannot demonstrate who decided whatretired · risks leading into it: 1 before, 0 after
CORP-6
Loss of control — the organisation operates a system it may not be able to stop or explainstill holds · risks leading into it: 2 before, 2 after
06 · What it adds

Every product is also a new thing in the estate.

By design it is a proxy in the request path. For guardrails its pages state failClosed (default): Deny the request… failOpen: Allow the request. For HTTP authorisation rules they state both: a require expression that errors denies, and a deny expression that errors does not deny. No page read says what happens to agent traffic when the gateway itself is down.

Free, but not free

What adopting it takes, before any of this is true.

An open-source project costs nothing to download and something to adopt. Every change above depends on the work below, and most of it is customisation to your own deployment.

  • Route the agent's model, tool and outbound traffic through it, and block the routes around it.
  • Write the MCP authorisation rules for the tools you actually expose.
  • Configure the log database, and decide who reads it.
Where its pages disagree

Published unresolved, for Linux Foundation (Agentic AI Foundation) to settle.

Each pair was read on the same day. We have not tested which is true, because that would mean testing somebody else’s system.

  • binds or gateways. The configuration overview says binds is the deprecated predecessor to gateways; the egress-proxy page's examples are written with binds. overview · egress-proxy
What this does not claim

The limits of the case, stated by the case.

  • That it can stop an agent. No page presents a feature as a way to stop one, so the stopping questions are left as they were.
  • Anything about Solo.io's commercial products, which are not this case.
  • That it was tested. Nothing was installed or run; every change rests on the documentation quoted beside it.
  • That the register is complete. It is one model, for one stated deployment. A different deployment changes the answers, and so the case.

Next. Published, and sent to the project's maintainers at the same time. If a change is wrong, or another answer should move, the case changes with the date they said so.

The same method, for your product

Make the case in the register’s own terms.

If you build a security product for agents, the case for it can be written the same way: what it does in your own words, the answers it changes, and the register before and after. If a case here is wrong about you, tell us and it changes with a date.

All the casesWrite to us