Data governance in an organization begins with a decision about privacy and ends with retention periods. The enterprise tier turns the privacy mode on by default and allows locking it so that members cannot switch it off. What matters here is not the existence of the switch but the guarantee of uniformity: a data-handling policy must be the same for everyone, otherwise it is not a policy but a recommendation, and in a compliance report it would have to be described with the word usually.
Bringing your own model key changes the contractual boundary, and that is worth understanding precisely. When requests go through your provider, retention terms are set by your agreement with them rather than by the tool's settings; a promise of zero retention remains true exactly for the part your contract covers. Two consequences follow. Models without such a mode usually require separate administrator approval, so that the decision is made deliberately. And a ban on personal keys exists not to control spend but so that a promise the organization has given cannot be bypassed in personal settings.
It helps to lay the data governance mechanisms out in a table once. Below is that map: locking the privacy mode, an allowlist of models, restricting personal keys, customer-managed encryption for indexes and cloud data, excluding sensitive repositories entirely, restricting repository scopes for automation, a retention policy and a deletion procedure. Eight mechanisms, each with its own subject, and none of them covers its neighbor.
| Mechanism | Purpose |
|---|---|
| Locking the privacy mode | One data-handling policy for the whole team |
| Model allowlist | Only approved providers and models |
| Restricting personal keys | Not bypassing the shared retention policy with personal keys |
| Customer-managed encryption | The organization's keys for indexes and cloud data |
| Repository exclusion | Removing sensitive code from view entirely |
| Restricting repository scopes | Repositories in the scope are available to automation only from your own teams |
| Retention policy | Limiting the lifetime of cloud data |
| Deletion procedure | The lifecycle of an agent, an account and a tenant |
|---|
Customer-managed encryption deserves a separate explanation, because more is expected of it than it gives. The organization's keys encrypt data at rest - codebase indexes and the data of cloud runs - and revoking a key makes them unreadable. That is a strong lever: it turns deletion from a procedure you have to vouch for into a technical action on your side. But processing does not move to you as a result: the request is still executed where it was executed, and while the work happens the data is visible to the system. Customer-managed encryption answers for data at rest rather than data in motion, and substituting it for the model allowlist or repository exclusion makes no sense.
Retention periods are worth remembering separately, because they affect planning. Codebase indexes expire after six weeks of inactivity and snapshots of cloud run environments after ninety days, while an enterprise policy may set its own retention windows. Deleting a personal account states that associated data is removed within thirty days, but that is not the same as corporate tenant offboarding: a personal procedure closes personal data rather than the traces of the organization's work. Those things get confused, and the confusion is expensive during an audit.
The difference between expiry and deletion matters more than it seems. Expiry is triggered by inactivity: an index lives while the repository is worked on and disappears if it was forgotten. That is an answer to the question of data accumulation but not an answer to a request to delete specific information - there a procedure is needed rather than waiting. There is a practical consequence too: returning to a long-untouched project costs a re-index, and the first interaction with it will be slower than usual. Planning periods around expiry is fine; relying on it as a deletion tool is not.
The difference between excluding a repository and restricting a scope deserves separate mention. The first removes data from view entirely: the repository is as if it did not exist for the tool, it cannot be indexed and cannot be sent by accident. The second leaves access but narrows the circle of those who can run automation on it, that is, it governs people and processes rather than data visibility. For genuinely sensitive code the right choice is usually the first: what is not in scope will not be sent by a configuration error or by an unfortunate wording of a request.
There is also an organizational side that settings cannot solve: a deletion-on-request procedure and the tenant's lifecycle. They are described in advance, because at the moment of a request it turns out that data is scattered across several places - indexes, snapshots of cloud runs, artifacts, audit logs, exports to third-party destinations. The list of those places with an owner and a deletion method for each is exactly the part of the work that cannot be done in a single day once the request arrives.
A separate contractual layer is needed wherever healthcare data enters the work. The agreement covering such data is available on the enterprise tier, is arranged through the sales team and does not appear by itself once a plan is paid for. It covers the desktop environment, cloud agents, Tab, the command line, the mobile client, automations and code review, but only with privacy mode enabled and locked; the list of eligible models is set by a separate configuration guide. The price of this is obligations on your side: signature first and data second, training people on what may be sent and how, and an independent assessment of third-party integrations, because the agreement does not extend to them.
The engineering conclusion is simple: data governance is a map of stores and periods rather than a single privacy switch. Until you can name where exactly your organization's data lies, who processes it under contract and when it will disappear, claims of compliance rest on faith rather than on the system's design.
The typical failures are predictable. Believing a personal model key does not change retention terms. Expecting from customer-managed encryption what it does not give. Relying on personal account deletion as corporate offboarding. Restricting the scope instead of excluding a genuinely sensitive repository. And not describing in advance where data lives and what periods bound it.