# 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. Source playbook: https://aigovernance.com/playbook/governing-agentic-developer-tools --- ## Approved AI developer tool register _The 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 | |---|---|---|---|---|---| | | T1 / T2 / T3 | SaaS / private cloud / on-prem | YYYY-MM-DD | | 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. --- ## Data boundary review template _What 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. --- ## Developer access tier matrix _Tier 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. --- ## Vendor policy change monitoring log _A 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 | | | 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 - **DGC-006**: The tool register and conditions govern AI-generated code and its license and provenance implications. - **PRC-014**: Egress-based discovery and the register are the shadow-AI inventory for developer tools, including local CLIs. - **AGT-019**: The data boundary review is the AI tool and plugin supply-chain risk assessment for dev tools. - **SEC-003**: The access tier matrix keeps sensitive code and credentials out of third-party inference pipelines. - **PRC-007**: The policy change log is the vendor governance-change monitoring process for dev tools.