Tools and MCP
Govern which tools AI agents are allowed to use.
Tool governance is the practice of deciding which tools an AI agent may invoke and against which resources, instead of granting an agent every tool its runtime exposes. Oconee Runtime detects tool-invocation activity — including MCP tool calls — as named signals, evaluates them against policy, and records the decision. A write-capable tool and a read-only one are different risks and can carry different rules.
No sales call required.
Least privilege stops at the agent boundary
Identity systems are careful about what a person may do. An agent acting on that person's behalf typically inherits the whole tool surface its runtime was configured with, and nothing between the agent and the tool asks whether this particular invocation, against this particular resource, was intended.
The unit that matters is the invocation, not the connection. Connecting a tool is a configuration decision made once; invoking it is an action taken repeatedly, in contexts nobody reviewed.
Example scenario
One action, evaluated
Proposed action
AI assistant
use_mcp_tool — write-capable toolContext
- Actor
- Developer
- Agent
- AI assistant in a supported surface
- Requested tool
- Write-capable
- Action
- Tool invocation
- Signals
- external_tool_use, mcp_tool event type
Policy decision
WARN
Tool invocation is surfaced as a signal and evaluated against policy like any other action, with the enforcement mode the organisation's plan permits.
Recorded as evidence
- actor
- agent
- action
- resource
- context
- policy
- decision
- timestamp
What Oconee sees today
This page describes a narrower capability than the phrase 'MCP governance' is often used to mean, and the distinction is worth stating plainly. Oconee recognises MCP tool activity as an event type and detects tool-invocation signals such as external_tool_use within the surfaces it integrates with. It does not sit in front of an MCP server as a proxy, and it does not transparently intercept every MCP call made anywhere on a machine.
MCP-specific blocking is an enterprise enforcement mode. Detection and audit evidence are available more broadly.
- mcp_tool modelled as a first-class event type in the ingestion pipeline
- external_tool_use signal detection on supported surfaces
- MCP blocking available as an enterprise enforcement mode
- Tool activity recorded with the same evidence fields as any other action
- Actor
- Agent
- Action
- Resource
- Context
- Policy
- Decision
- Evidence
Relevant capabilities
- Tool-invocation signals on supported AI surfaces
- MCP tool activity modelled in the event pipeline
- Policy evaluation and decision evidence for tool use
- Enterprise enforcement mode for MCP blocking
Where this is heading, and where it is now
Treating tool invocation as an action to authorise, rather than a capability to configure, is the right model. Oconee implements the detection and evidence side of it today and blocks at the enterprise tier. If your evaluation depends on proxying MCP traffic directly, that is not what this does, and it is better to know that now than after a trial.
Common questions
- What is MCP tool governance?
- Deciding which tools an AI agent may invoke, against which resources, and under what conditions — rather than granting the agent the entire tool surface its runtime exposes. In practice it means treating a tool call as an action to be authorised and recorded.
- Does Oconee proxy MCP servers?
- No. Oconee detects MCP and tool-invocation activity as signals on the surfaces it integrates with, evaluates them against policy, and records the decision. It does not sit in the connection path as an MCP proxy.
Related
Other use cases
AI coding agent governance
Agents now run commands, change files and install dependencies, not just suggest them.
Prevent sensitive AI actions
Risk appears after the prompt, in what the agent reads and assembles.
For security teams
Dashboards report AI activity after the fact and change nothing about it.