Engineering is standing up MCP gateways, OAuth scopes, and approved tool catalogs. That work is necessary. It is not sufficient. A gateway that authenticates a call does not answer the product question: which verbs may this agent invoke, on whose data, under which autonomy ceiling, and who can kill the path when it misbehaves.
The failure pattern is familiar. A connector is added because the demo looked better. Slack send, Jira write, Salesforce update, or browser click arrives as a config change. Within a quarter the agent can act far beyond the tier declared in the original PRD. There is usually no malice — only the absence of a product surface for the grant itself.
Treat every tool, connector, MCP server, and computer-use action as a product. Before the grant, write a Tool Contract: purpose, allowed verbs, data class, autonomy ceiling (must be at or below the declared Agent Autonomy Tier), eval cases for misuse, a named owner, and a kill path. Default is deny. No tool without a row. A new tool, a wider scope, or a new model that can call it is a new ship, not a hotfix.
This is complementary to the other two Agent Ops pillars. Autonomy Tiers answer how much the agent may do. The Context Contract answers what it may see, remember, and cite. The Tool Contract answers what it may touch. Enterprise control planes enforce identity and audit; the Tool Contract is the product artifact those planes should enforce. Steal the one-pager and PRD block at productleading.com/kit — declare the tier, contract the tools, contract the context, name who can stop it.