MCP is the productivity-agent control point
Productivity agents do real work through MCP tools. Those calls need the same policy path as coding-agent tools.
The tool surface moved
Coding agents made terminal and filesystem actions obvious security events. Productivity agents move the same risk into MCP: read a drive file, draft an email, query a CRM, call a private API, or invoke a local filesystem server.
The user experience is friendlier, but the security question is the same. Who called what, with which arguments, against which data, under which policy?
Normalize server, tool, and arguments
MCP policy needs to preserve the shape of the call. A generic network log cannot distinguish a harmless calendar lookup from a tool call that reads payroll data and writes it somewhere else.
The useful event model names the MCP server, the tool, the arguments, the caller, and the verdict. That gives teams a policy plane that is specific enough to enforce without blocking every useful agent workflow.
Gateway where the agent is not enough
Local hooks work well for coding agents that expose pre-tool events. Productivity agents often need a gateway pattern so MCP calls can be evaluated before they reach the upstream server.
The goal is not to make MCP scary. The goal is to make it accountable, with the same allow, warn, and deny semantics used everywhere else agents take action.