At what point does a team treating AI security as plumbing, meaning nobody wants to investigate, debug, or test it because that would slow the work down, fail? At the tool call.
A dangerous question that must be answered at every tool call: who is acting, which resource is canonical, what grant applies, which capability is being invoked, where the output can flow next, and what receipt exists if the runtime says no.
Connectivity to such resources is becoming easier to set up. The recent MCP SDK betas for the 2026-07-28 spec release candidate make that point plainly. So security needs to move from the setup of connection to a resource to control of execution within that resource.
The HCP paper, From Tool Connection to Execution Control, first defines eight runtime invariants that MCP-style systems need to satisfy: metadata non-authority, grant-backed approval, canonical resources, principal binding, scoped capability invocation, source-and-target data-flow authorization, deny-path audit, and explicit protocol state. For a long time these read like abstract requirements. In reality each of these is the minimum viable security invariant for an action that an agent is performing by updating CRM records, creating a customer, creating a sales process, or reporting on data in CRM. The runtime has to resolve the canonical resource, bind the principal to a grant, invoke only the scoped capability, authorize data flow, and make every denial auditable.
