The official hardening guide does not offer one master switch - it offers layers. Single sign-on and automated provisioning, device restriction, an extension policy, supported clients, the privacy mode, control of models and personal keys, repository exclusion, restricted scopes for automation, the auto-review mode together with the sandbox, network restrictions, event handlers, file exclusions, review agents and audit logs.
The list looks long, but simple logic stands behind it: every layer closes its own class of risk and does not close the others. Identity answers for who acts. Modes and the sandbox for what they can do. The network for where data goes. Review for what lands in the main branch. Logs for what you will be able to reconstruct after the fact. No layer is a spare for another, and a hole in one is not closed by tightening its neighbor.
It helps to assemble a minimal enterprise baseline as a checklist once. It is given below: sign-on, provisioning and device identity are locked; the privacy mode and the model allowlist are locked; sensitive repositories are excluded or taken out of scope; a review mode or an allowlist is chosen instead of full access; the local sandbox and cloud traffic have explicit policies; external servers, plugins and extensions pass an allowlist and source review; critical handlers run fail-closed; review agents complement the human; logs are exported and inspected; a canary update and rollback are tested.
Ten items are not many for an organization, and each of them is verifiable. It is verifiability that separates a baseline from a declaration: for every item you can present not an intention but observable behavior or a log entry. If there is nothing to present, the item counts as unmet regardless of what the policy says, and during an audit it will look exactly the same.
The item about handlers is worth unpacking, because it is subtle. A handler that must block a dangerous action is obliged to refuse when it fails rather than to let the action through. The difference shows at a single moment - when the handler is unavailable - and at exactly that moment the policy either exists or does not. Hence the second requirement: a critical check must not have a dependency that may be missing. A handler that goes to a network service for its verdict turns permissive when the connection drops; the same check sitting next to the repository and needing no network keeps working. The sign of a wrong setup looks harmless: commands that used to require approval one day pass silently.
One more layer is usually already paid for: existing data loss prevention tools plug into the toolchain in three ways. An agent on the device watches outbound traffic to the service's domains and blocks or alerts by its own rules - it knows nothing about the meaning of the work, but it acts where handlers are not configured, and it is paid for with latency on traffic inspection. Custom logic in handlers checks the prompt before it goes to the model and the generated code before it is written to disk. A call from a handler to the vendor's own service decides by its answer - and that is exactly the network dependency that leaves a check without a verdict when the connection drops. Next to it stands origin restriction for the browser: an allowlist of domains beyond which the agent's navigation is blocked.
What was said about modes needs repeating separately: a probabilistic classifier is not a security boundary. It is useful as a default autonomy governor - it removes routine approvals where the risk is small and thereby preserves the person's attention for the cases where it is needed. But secrets, destructive commands and regulated areas are protected by deterministic means and external isolation rather than by an assessment, because an assessment errs quietly and on rare inputs.
That sentence seems obvious until you see a configuration where the whole defense rests on the review mode. It looks tidy, works most of the time and falls apart exactly when the content of a repository, a page or an external server's answer turns out to be deliberately crafted, that is, in the single case the defense was built for. An assessment layer is good together with hard boundaries and bad instead of them.
The last item on the list looks operational, but it is about security too. A supported-clients policy forces upgrades, and an upgrade changes the tool's behavior for everyone at once, including the behavior of your handlers, rules and integrations. A canary update means the new version first reaches a small group while the rest stay on the previous one until the check passes. Rollback means the way back has been rehearsed in advance and does not call for ingenuity on a bad day. Having rehearsed neither, you will one day get an incident caused not by an attack but by a planned upgrade, and it will have to be untangled across the whole organization at once.
The engineering conclusion is simple: hardening is not a set of prohibitions but a set of layers with a clear owner for each. They are worth deploying in order from identity to autonomy and the network, verifying with negative tests, and revisiting whenever the set of tools changes. Then you get not a feeling of security but its observable signs.
The typical failures are predictable. Building defense on one layer, usually the review mode. Leaving sensitive repositories in scope and settling for rules. Making a critical handler depend on the network and getting a permissive mode when it drops. Not testing handlers in blocking mode. And not rehearsing a canary update and rollback.
The minimal enterprise baseline
[ ] single sign-on, provisioning and device identity are locked
[ ] the privacy mode and the model allowlist are locked
[ ] sensitive repositories are excluded or taken out of scope
[ ] a review mode or an allowlist is chosen instead of full access
[ ] the local sandbox and cloud traffic have explicit policies
[ ] external servers, plugins and extensions pass an allowlist and source review
[ ] critical handlers run fail-closed
[ ] review agents complement the human rather than replace them
[ ] logs are exported and inspected regularly
[ ] a canary update and rollback are tested