Treated connectors as the main risk surface this week. Not the model. Not the policy engine. The connectors. Because a model that hallucinates is annoying but a connector that executes a hallucinated action against a real API is a production incident.
Shifted toward allowlist-first and idempotency-first assumptions for all connector designs. By default a connector can not do anything. You explicitly open up what it can do, for which tools, with which parameter constraints. The default is deny.
Built connector patterns for HTTP, GitHub, and Stripe-style actions. Each pattern defines the structure of a valid action and the constraints around it. A GitHub connector that can open PRs but not delete repos. A Stripe connector that can create charges but not modify customer records. The specificity matters because "can access GitHub" is not a useful permission boundary.
Added execution guard concepts: strict allowlists per connector, tool-specific rate limits, and parameter validation before execution. The connector itself should refuse to execute anything that does not match its declared capabilities, independent of what the policy engine says.
Connector quality directly controls blast radius. A bad connector turns a policy failure into a production disaster.