Agent Supervision Became a Category: Who Did What, With Which Data, at What Cost

Agents moved into everyday work, and oversight followed

October 2026 is the month agents stopped being a separate product and became a feature of the tools people already use. Google introduced a Gemini workplace agent that works across Gmail, Drive, Docs, and Calendar. Microsoft began rolling out Work IQ in preview, connecting Copilot and autonomous agents to live Dynamics 365 and Power Platform data. Cisco let agents join Webex spaces, meetings, and calls to carry out multistep work. SAP expanded Joule into an agentic work layer.

Every one of those launches widens what an agent can read and do inside a company. And in the same weeks, a new category of products appeared to watch them:

• Classie Supervise, generally available on October 1, 2026, monitors sanctioned and unsanctioned agents as they run and enforces policy in real time. Its runtime transcript records who initiated the activity, what the agent did, what data it accessed, what it cost, and the chain of custody, with rules enforced inline through Open Policy Agent.
• Gurucul AI Risk and Response, announced September 24, 2026, connects AI activity from Claude, Gemini, ChatGPT, Azure AI Foundry, and Microsoft 365 Copilot to identity data for detection and response. Its feature for blocking risky AI interactions is still in preview.
• Zscaler's Agentic SOC, launched September 9, 2026, was read by analysts as the signal that agent oversight has moved from startup niche to enterprise requirement.

The urgency is real. Coverage of the Zscaler launch cited SailPoint's finding that 79% of organisations deploy AI agents but only 2% have the identity security to protect them, and Gartner's prediction that over 40% of agentic AI projects will be cancelled by 2027, largely over security and governance failures.

The five questions every supervision tool is trying to answer

Strip away the vendor language and agent supervision comes down to five questions. Classie's runtime transcript lists almost exactly these:

1. Who initiated it? Which person, team, workload, or other agent started this chain of actions? 2. What did it do? Which models did it call, which tools, with what outcome? 3. What data did it touch? What left the boundary, what came back, what was redacted? 4. What did it cost? In tokens, in money, and against which budget? 5. Can we stop it? Before the action, not after the incident report.

Most monitoring answers the first four after the fact. The fifth is different: it can only be answered by something in the path of the action. And question four has the same property in practice, because a cost you learn about from an invoice is a cost you can no longer prevent.

Why the answers belong in the path

Agents now spend money and take actions through two kinds of calls: model calls and tool calls. If both pass through one gateway, the gateway is the only component that sees every step with full context, before the upstream system executes it.

That changes what supervision can do:

• Deny instead of alert. A tool call outside the agent's grant never reaches the MCP server.
• Redact instead of report. Sensitive values are removed before the prompt leaves, not discovered in a log review.
• Reserve instead of reconcile. Budget is reserved before the provider call, so concurrent agents cannot overspend a window.
• Pause instead of post-mortem. High-impact actions wait for an approval decision, and fail closed if the approver is unavailable.

The cost dimension is not secondary. Gartner warned in August 2026 that inference costs for agentic workflows will rise more than fivefold over two years even as token prices fall, and that advanced reasoning agents can cost up to 150 times more per task than basic chatbots. A supervision programme that cannot cap spend in real time is only half a programme.

How Odock answers the five questions

Who initiated it

Every call to Odock carries a virtual API key, and every key resolves to a principal: organisation, optional team, optional user, and the key itself. Issue one key per agent or workload rather than one per application, and the "who" stops being a guess.

Agents that act on behalf of others need more than a key. Odock's built-in Agent identity and loop ceiling flow template requires x-odock-agent-id and x-odock-agent-iteration headers on agent traffic and rejects requests without them, so every step in a chain is attributed to a named agent and a position in its run.

What it did

Odock writes a usage record for every gateway call: principal, resolved provider and model, HTTP status, latency, gateway request id, tokens, cost, the routing trace showing which candidates were attempted, and the plugin and safety outcomes attached to the call. Prompts, completions, and credentials are never written into a usage record.

MCP tool calls get MCP usage records with server, tool, status, and cost. Every Flow Studio run leaves a node-by-node trace (node, outcome, duration) attached to the request evidence. Metrics, logs, and traces flow into the LGTM observability stack through OpenTelemetry.

What data it touched

Three layers handle data before and after the upstream call:

• SafetySec detects prompt injection and jailbreak patterns, redacts secrets and PII-like values in requests and responses, and detects data leakage in model output.
• MCP semantic filters inspect tool-call payloads before execution, and upstream auth injection keeps tool credentials inside Odock so agents never handle them.
• Plugins and flows add organisation-specific handling: run a masking plugin before egress, or use the built-in Block secrets in model output template to stop API keys or private keys from reaching the caller.

What it cost

Budgets apply to an organisation, team, user, or API key. Odock estimates each request's cost, reserves it against every matching budget before the upstream call, and settles the actual cost afterwards. When a window is exhausted the agent receives 402 budget_exceeded. Quotas cap request and token counts the same way, and routing keeps agents on the cheapest approved model that works, with failover when a provider degrades.

Can we stop it

This is where an inline gateway differs most from an observer:

• Access grants and tool rules stop unauthorised models and tools outright, with allowlists and blocklists per MCP server.
• Abort nodes in Flow Studio block a request with a status code and a clear message, at pre-route, pre-upstream, or post-upstream.
• The built-in MCP external approval gate template calls your policy or approval service before destructive tools and fails closed when approval is denied or unavailable.
• The loop ceiling stops agents that exceed their iteration limit before they spend more.
• Key revocation and rotation cut off a misbehaving agent immediately, without touching other workloads.

Chain of custody

All of the above shares one gateway request id. The usage record, the MCP usage record, the flow trace, the SafetySec evidence, and the OpenTelemetry trace for the same step can be joined without guesswork. That is what turns a pile of logs into evidence an auditor or incident responder can follow.

Gateway and supervision tools work together

None of this makes supervision or SOC platforms redundant. They correlate signals across identity, endpoints, SaaS, and networks that a gateway never sees. What they need from the AI layer is clean, attributed, real-time evidence, and an enforcement point that acts on their decisions.

Odock provides both directions:

• Out: the built-in Incident response fan-out template notifies security and SIEM concurrently for high-risk requests and every MCP tool invocation, after the caller gets its response. Audit and SIEM export plugins run in the asynchronous lane, so they never slow agents down.
• In: an approval or policy decision service, including one run by your supervision platform, can be called from a flow before high-impact actions.

A 30-day supervision rollout

• Week 1: inventory and identity. Route agent traffic through Odock. Issue one virtual key per agent or workload. Revoke shared provider keys.
• Week 2: observe. Turn on SafetySec in observe mode, enable usage records review, and add the agent identity template in a pilot key's Automation tab.
• Week 3: bound. Set team and agent budgets, quotas, and the loop ceiling. Restrict MCP servers to allowlisted tools.
• Week 4: intervene. Add the external approval gate for destructive tools, switch SafetySec from observe to enforce where evidence supports it, and forward evidence to your SIEM or supervision platform.

Agent supervision is becoming a budget line and a board question. The organisations that answer it well will not be the ones with the most dashboards. They will be the ones where every agent action passes a point that knows who asked, checks what is allowed, protects the data, reserves the cost, and can say no, and where the record of all of that already exists when someone asks.

Sources

• VMblog, Classie launches Supervise to track, control and account for enterprise AI agents in real time, October 1, 2026
• Help Net Security, Gurucul connects AI activity to identity data for faster threat response, September 24, 2026
• Forkast, Zscaler's Agentic SOC launch signals the category startups built is now an enterprise requirement, October 7, 2026
• Futurum, Google collapses enterprise AI into a single Gemini agent at Gemini at Work 2026
• AI Agents Directory, AI Agents News Brief, October 6, 2026
• AI Agent Store, AI Agents News, week of October 11, 2026
• Computerworld, AI inference is getting cheaper, but your agents are getting more expensive, August 17, 2026
• Odock security and guardrails
• Odock usage records
• Odock MCP security
• Odock Flow Studio