2.3 Monitoring, sessions and activity
Three different records, from three different sources:
| Page | Source | Needs |
|---|---|---|
| Agent Sessions | The transcripts the agent writes on disk anyway | Nothing |
| Agent Records | The monitoring hook Gateway installs in the agent | Monitoring on for that agent |
| Outbound traffic, on an agent's page | The network connections of the agent's own processes | Windows |
None of them is the same as LLM Records, which is what Gateway itself relayed.
Agent Sessions
Every session those agents have had, read from their own transcripts: the whole conversation, message by message, with the tokens each turn used.
The page counts how many sessions there are, how many ran today, and how many came from a transcript rather than from monitoring, and filters down to one agent or one of those two sources.
Because transcripts are written whether or not Gateway is in the path, this covers sessions that never went through Gateway — an agent on its own subscription included.
Monitoring
Monitoring is turned on per agent, from its card or its own page. Gateway installs a hook in that agent's own configuration, and from then on records what the agent did: prompts, tool calls, and the permission prompts it showed you.
It is audit-only. Nothing an agent does waits on Gateway, and no answer changes because monitoring is on.
Not every agent supports it — the Monitoring column of the table in the README is the current list.
Turning monitoring off removes the hook from that agent's configuration again. casbin-gateway uninstall does the same for every agent at once (5.5).
Agent Records
Agent Records is what a monitored agent is doing as it does it: each tool call, its target, and how long it took.
This is the page to open while an agent is running — a long agent run reads there as a list of what it actually touched, rather than as a wall of output in a terminal.
Outbound traffic
The proxy only sees what an agent sends its model. An agent can send data somewhere else entirely: a whole repository posted straight to cloud storage never passes through any proxy. Outbound traffic, on each agent's own page, is where that shows.
Gateway watches the network connections of every agent's own processes from the moment it starts. Monitoring does not have to be on. Watching connections is Windows only for now. On other systems the section appears only for a workspace packed up whole, which is read from disk.
What it records
An upload is recorded as suspicious when it is either of these:
| Finding | When |
|---|---|
| Object storage | Any connection to an object-storage upload endpoint: Aliyun OSS, Amazon S3, Tencent COS, Volcano Engine TOS, Huawei OBS, Google Cloud Storage, Azure Blob, Cloudflare R2 and the like. A client posting there is usually sending a file with a credential its vendor signed |
| Large upload | 5 MB or more sent to one destination within a minute, anywhere but a model API, where an agent is expected to send its context |
A finding is written once its destination has been quiet for a minute, so one upload is one row however many connections it took. Each also lands on Agent Records, and the agent's card on Agents carries a red dot beside its name.
Where it connected
Destinations folds out every place the agent's processes connected to since Gateway started watching: the host, its kind, how many connections, and the bytes sent and received.
| Kind | What it is |
|---|---|
| Model API | A model vendor's API |
| Object storage | An object-storage upload endpoint |
| Telemetry | Error reporting and analytics services |
| Local process | Another process on this machine, usually a proxy, which hides where the bytes go next — it is named |
| Other | Anything else |
Host names are read from the system's DNS cache, so a bucket shows by the name the agent asked for rather than as the address of the CDN node behind it.
Counting bytes needs administrator
Windows only counts bytes per connection for a process running as administrator. Without that, the section says Bytes not counted: destinations and object-storage connections are still watched, but sizes show as - and a large upload cannot be recognised.
A workspace packed up whole
Some agents pack the whole workspace before uploading it. ZCode builds up to 3.12.x pack the working tree, its .git included, before each prompt and post it to Aliyun OSS. What that packing leaves on disk outlives the upload, so Gateway reads it back even for an upload that happened while Gateway was not running, and shows the workspace, the size, how many files came from .git, and any failed attempts.
The package holds the full commit history. Rotate any secret that ever appeared in it, including ones deleted since.
The hook is also an enforcement point
An agent that does not route its model traffic through Gateway is still held to its tool switches, because the hook Gateway installed asks Gateway before the tool runs and refuses a call the switches do not allow.
The model and provider rules are different: those can only hold requests that come through the proxy. The Permissions page says which of the two an agent is in (4.1).
Next: 2.4 Skills, MCP & Prompts.