Implementation Kit
AI Developer Tool Register and Data Boundary Checklist
Which AI coding tools are allowed, for whom, and under what conditions. An approved tool register, a data boundary review template, a developer access tier matrix, and a vendor policy-change log. Locally installed CLIs are the blind spot this kit is built around.
Who this is for: The platform, security, or engineering-governance owner setting policy for AI developer tools.
1. Approved AI developer tool register
SpreadsheetThe allowlist, with the conditions attached to each tool and each developer tier.
Template
| Tool | Approved for tiers | Deployment mode required | Data boundary review date | Conditions | Next review |
|---|---|---|---|---|---|
| <tool> | T1 / T2 / T3 | SaaS / private cloud / on-prem | YYYY-MM-DD | <e.g. no prod creds, telemetry off, repo allowlist> | YYYY-MM-DD |
Worked example
| Tool | Approved for tiers | Deployment mode | Boundary review | Conditions | Next review |
|---|---|---|---|---|---|
| Cloud IDE assistant | T1, T2 | SaaS (enterprise tenant) | 2026-08-10 | training opt-out on; no files matching secret patterns | 2027-02-10 |
| Local coding CLI | T1 only | SaaS, zero-retention endpoint | 2026-08-12 | not permitted on machines with prod credentials; context scoped to the working repo | 2026-11-12 |
| Self-hosted model plugin | T1, T2, T3 | on-prem | 2026-09-01 | none beyond standard | 2027-03-01 |
Acceptance criteria
- ✓Only tools on the register may be used; anything else is a policy exception.
- ✓Each tool has a deployment mode and conditions matched to the developer tiers allowed to use it.
- ✓Every tool has a data boundary review date and a next-review date.
2. Data boundary review template
SpreadsheetWhat actually leaves the machine per request, and what the vendor does with it.
Template
| Question | Finding |
|---|---|
| What code or data is transmitted per request (open file, whole repo, diffs, terminal output)? | |
| Is transmission scoped by config, and does the scope hold in practice? | |
| Does opt-out operate at transmission or only at retention? | |
| Is submitted code used for model training? Is opt-out the default? | |
| Retention period for prompts and code context? | |
| Where is data processed and stored? | |
| Vendor breach notification SLA? | |
| Telemetry and analytics: what is collected, can it be disabled? |
Worked example
| Question | Finding |
|---|---|
| Transmitted per request | open file + up to 20 nearby files + last terminal command |
| Scoped by config? | yes, "workspace only"; verified with a proxy capture |
| Opt-out level | retention only; content is still transmitted for inference |
| Used for training? | no on the enterprise tier; opt-out is the default there |
| Retention | 0 days on the zero-retention endpoint; 30 days otherwise |
| Processing location | US; EU option not available |
| Breach SLA | 72 hours |
| Telemetry | usage metrics; can be disabled via MDM policy |
Acceptance criteria
- ✓The review is based on observed behaviour (a proxy capture), not only vendor documentation.
- ✓It distinguishes transmission-level from retention-level opt-out.
- ✓The completed review is retained as a vendor due diligence artifact.
3. Developer access tier matrix
SpreadsheetTier developers by what they can reach, and match tool strictness to the tier.
Template
| Tier | Access held | Permitted tool categories | Required deployment mode |
|---|---|---|---|
| T1 (highest sensitivity) | production credentials, customer data, signing keys | on-prem or private-cloud AI only; no third-party SaaS inference on those machines | on-prem / private cloud |
| T2 | internal APIs, proprietary source, no prod creds | enterprise-tenant SaaS with training opt-out and secret filtering | SaaS (enterprise) |
| T3 | sandbox and public code only | any approved tool | any approved |
Worked example
Applied to three developers.
| Developer | Tier | Access held | Tool decision |
|---|---|---|---|
| Platform SRE | T1 | production credentials | Local coding CLI removed from their machines; on-prem model plugin only |
| Product engineer | T2 | internal source, no prod | Cloud IDE assistant on the enterprise tenant; secret filtering enforced |
| Contractor on the public SDK | T3 | sandbox + public code | Any approved tool |
Acceptance criteria
- ✓Every developer is assigned a tier based on actual access, reviewed when access changes.
- ✓T1 machines do not run third-party SaaS inference tools.
- ✓The matrix is enforced by device policy where possible, not left to the honour system.
4. Vendor policy change monitoring log
SpreadsheetA record of vendor data-handling policy changes and the re-approval they trigger.
Template
| Date noticed | Tool | Change | Affects our data boundary? | Action | Re-approved on |
|---|---|---|---|---|---|
| YYYY-MM-DD | <tool> | <what changed> | Y / N | re-review / restrict / no action | YYYY-MM-DD |
Worked example
| Date noticed | Tool | Change | Affects boundary? | Action | Re-approved |
|---|---|---|---|---|---|
| 2026-08-28 | Cloud IDE assistant | default retention changed 0 to 30 days on standard tier | Y | confirm enterprise tenant unaffected; re-review | 2026-09-02 |
| 2026-09-10 | Local coding CLI | added optional agent mode with shell execution | Y | restrict: agent mode disabled by policy pending review | pending |
Acceptance criteria
- ✓There is an active way to notice vendor policy changes (change-watch, release notes feed), not only annual review.
- ✓Any change affecting the data boundary triggers re-approval before continued use in sensitive environments.
- ✓The log ties each change to an action and a re-approval date.
Governance controls this kit produces evidence for
Completing the artifacts above gives you a head start on the evidence requirements for these controls.
The tool register and conditions govern AI-generated code and its license and provenance implications.
Egress-based discovery and the register are the shadow-AI inventory for developer tools, including local CLIs.
The data boundary review is the AI tool and plugin supply-chain risk assessment for dev tools.
The access tier matrix keeps sensitive code and credentials out of third-party inference pipelines.
The policy change log is the vendor governance-change monitoring process for dev tools.
This kit backs one playbook. Read the full guidance for the reasoning behind each artifact.
Decide what to implement next
Assess your governance gaps, then create an action plan with owners and target dates. Build and export without an account; sign in when you want to save your plan.
Start the AI governance assessment →