Events around the shell and files deserve particular attention - most substantive policies are built on them. Checking a command before execution, reacting to a file change, controlling reads of sensitive paths: those three points cover the bulk of requirements and, importantly, are available in the cloud too. The reason is simple: a command, a file and its contents exist identically on both surfaces, while the editor and its suggestions do not. The common subset is determined by what actually happens in an autonomous run rather than by what somebody decided to port.

Events around the agent's output - the response, the thought, the stop - are used for auditing more often than for prohibition. That follows from where they sit in time: they occur after the decision has been made and the text formed, and there is nothing left to forbid. Recording what exactly the agent decided and how it finished, on the other hand, is cheap and useful. Such a log answers the question of why it did that more precisely than any transcript, because it captures not the correspondence but the sequence of the agent's own steps.

There is one more detail of cloud execution that the list of events does not show. A cloud agent does not pick up user handlers; it runs command-based handlers from the project, and on the enterprise plan also team and enterprise-managed ones - everything configured in a personal profile stays on your machine. Beyond that, handlers do not take effect from the first second: the early stage of a run passes in a read-only mode, and the policy switches on after the transition into an environment where writing is allowed. In practice that means your controls will not see the agent's first actions, and counting on them as a continuous tape is not possible.

The sign by which real work reveals that a policy was not applied is emptiness where records were expected. So it helps to begin a handler with a mark of its own invocation: a line with the event name and a timestamp costs almost nothing but turns silence into a measurable fact. The diagnostics after that are simple: the same scenario is run locally and autonomously and the logs are compared. If the marks are there locally and absent in the cloud, the question is not about configuration but about the surface, and it is resolved by choosing a different event rather than by editing the handler.

From this follows the rule for porting a policy between surfaces. A requirement that must apply everywhere is built on events from the common subset: the shell, files, tools, the prompt. A requirement that is inevitably local, tied to editor suggestions for example, is recorded explicitly and next to the rule itself, so that nobody counts on it in autonomous runs. Writing that boundary down costs one line and removes a whole class of false expectations.

The engineering conclusion is simple: the list of events is a map of attachment points, and the availability column is a map of applicability. Together they answer the two questions asked when designing any policy: where can I intervene and will my intervention work where it is actually needed. The answer to the second question is the more expensive one, because a mistake in it does not present itself as a mistake.

The typical failures are predictable. Building a policy on events unavailable in the cloud. Trying to block an action with an event that fires after it. Treating a handler not being called as a configuration error rather than a property of the surface. Counting on personal handlers where only those defined in the project are executed. And not recording explicitly that part of the policy applies only locally.