2026-10-09 · ~20 min read · Decision records

The AI coding assistant governance decision record: why the adoption model you chose determines your IP exposure surface and your security review calibration failure mode

The AI coding assistant governance decision is not a decision about which tool to use. It is a set of founding decisions about which service tier your team uses and what data handling commitments that tier provides, which code contexts are appropriate for AI suggestions and which are excluded, and what review standard applies to AI-generated code in security-critical paths. These decisions together determine two structural properties that are invisible during normal sprint work but visible the moment an enterprise prospect requests a data processing agreement or a penetration test surfaces a timing-attack vulnerability: the IP exposure surface — the set of code that may be transmitted to an AI provider's API without the team having decided whether that transmission is acceptable under their enterprise customer obligations — and the security review calibration failure mode — the systematic reduction in security scrutiny that AI-suggested code receives because the suggestion anchors reviewers to verifying correctness rather than auditing safety. Three failure patterns: a company with no AI coding policy discovers mid-SOC 2 prep that engineers have been transmitting schema files and proprietary algorithms to a provider they cannot name in an enterprise DPA, stalling a $180k deal for six weeks; a company that bans all AI coding tools company-wide generates shadow usage by the same engineers the ban was designed to protect, producing worse security outcomes than a calibrated policy; and a company that deploys GitHub Copilot for Business without specifying a review standard for security-critical code ships a HMAC timing-attack vulnerability into production webhook delivery that passes code review because the AI suggestion anchored the reviewer to correctness verification rather than security auditing.

A 38-person SaaS company built contract lifecycle management software for mid-market professional services firms. Their engineering team had grown from 5 to 12 engineers over 14 months. During that growth period, individual engineers had independently adopted AI coding tools: six were using GitHub Copilot on personal subscriptions, two were using Cursor on personal subscriptions, and one was using Claude's API directly with a personal account and a custom Neovim plugin they had built. There was no company policy. The CTO was aware that engineers were using AI tools and considered it a productivity positive — he used Copilot himself on a personal subscription. When engineers asked whether they should use the individual or business tier, the answer was "individual is fine for now, we'll sort out the enterprise tier when we're bigger." That conversation happened four times across 14 months and produced no written decision.

In month 15, the company entered a sales process with a 620-person financial services firm. The deal size was $180k annually. In week 3 of the procurement process, the financial services firm's vendor security team sent a standard questionnaire. Question 14 asked: "Does your engineering team use any third-party AI services that receive access to code implementing features used in our account?" The answer was yes — GitHub Copilot, Cursor, and a custom Claude API integration were all transmitting code context. Question 15 asked for the data processing agreements with each AI service used, specifying data retention, training data usage, and subprocessor list. The individual and personal tiers of all three tools either did not offer DPAs or offered DPAs that explicitly did not cover usage for model training opt-out. The company could not produce the agreements.

The security team escalated to the financial services firm's legal department. The deal did not fail — the financial services firm valued the product enough to continue — but the procurement process extended by six weeks while the engineering team switched to enterprise tiers for GitHub Copilot and Cursor (the Claude integration engineer rebuilt their plugin to use Anthropic's enterprise API tier), the security team reviewed which code had been transmitted during the previous 14 months (not possible to reconstruct exactly, but the team could confirm which proprietary algorithm implementations existed in the affected engineers' primary working directories and therefore could have been included in inline completion context), and legal produced a retrospective attestation acceptable to the financial services firm's vendor management team. The six-week extension cost the company two additional sales engineer months and delayed renewal negotiations with an existing customer whose contract renewal timing had been coordinated with the new deal close. The total cost was estimated at approximately $40k in engineering time plus the opportunity cost of a delayed existing renewal. Connect this to the SOC 2 compliance decision record: SOC 2 Type II audits require evidence of third-party vendor assessments for all subprocessors that receive access to customer data or code implementing customer-facing features; the AI coding tool tier decision is a vendor assessment decision, not just a developer experience decision; engineering teams that make the tool tier decision informally — "individual is fine for now" — are making a subprocessor management decision without the security and legal review that a formal vendor assessment would require; the gap surfaces not at audit time but at enterprise deal time, when the prospect's questionnaire asks questions the team has never formally answered.

A 44-person developer tools company built a static analysis platform for enterprise engineering teams. Their engineering team had 11 engineers and a strong culture of security-first development — their product analyzed customer codebases, so they took code handling seriously. In October of the company's fourth year, a competitor's blog post circulated widely in engineering leadership Slack groups: the competitor had discovered that one of their engineers had been using a personal AI coding tier to iterate on a novel program analysis algorithm, and the algorithm logic — including the intermediate research approaches that were explicitly not productized — had appeared in a blog post from the AI provider's technical team, attributed to "patterns observed in developer usage." The competitor's legal team was investigating. The story was later found to be substantially exaggerated (the AI provider's blog post made no claim of user-specific training, and the coincidence between the competitor's algorithm and the blog post content was more likely parallel development than extraction), but the CTO of the developer tools company read the story during a particularly stressful sprint week and made an immediate decision: all AI coding assistants banned, company-wide, effective immediately, no exceptions.

The ban was technically enforced where possible — the company's GitHub organization had Copilot disabled, the engineering manager sent a policy update to all engineers, and the CTO mentioned it in the following week's all-hands. What the company could not technically enforce was engineers' personal devices, engineers' personal accounts on tools that did not authenticate through the company's GitHub organization, and browser-based AI chat interfaces. Within three weeks, a survey sent by a senior engineer (not officially sanctioned but shared openly in the engineering Slack) found that 7 of 11 engineers were continuing to use AI coding tools via workarounds — personal laptops, personal accounts, or browser-based alternatives. The 7 engineers using workarounds were the same engineers who had the strongest pre-ban AI coding tool habits: they had developed effective prompting techniques, knew which code patterns benefited from AI assistance and which required careful human implementation, and relied on AI suggestions for test generation, boilerplate reduction, and documentation drafting. The 4 engineers who complied with the ban fully were the engineers who had been lighter users before the ban.

The security outcome was worse under the ban than a calibrated policy would have produced. The 7 workaround users were using personal tier accounts with no DPA, no audit log, and no context scope controls — exactly the configuration the ban was intended to prevent. The 4 compliant engineers were not using AI coding tools. Fourteen months after the ban, when the CTO lifted it after the competitor's legal case concluded with no finding of AI provider misconduct, the 7 engineers who had used workarounds resumed immediately with effective habits; the 4 engineers who had complied with the ban took 3 to 4 weeks to redevelop effective AI-assisted development patterns. The engineers most harmed by the ban were the ones who had followed the policy. Connect this to the security scanning decision record: the failure mode of a blanket ban on developer tools is structurally identical to the failure mode of an overly aggressive SAST policy that generates so many false positives that engineers disable the scanner for their directories — in both cases, the security control generates a compliance cost that exceeds the perceived security benefit, engineers route around the control, and the shadow usage is worse than the controlled usage the policy was designed to replace; the correct model for both is a policy calibrated to the actual risk profile (tool tier and context scope for AI tools; scan scope and suppression policy for SAST), with a visible exception process that keeps shadow usage to zero by giving engineers a path to compliant non-default behavior rather than forcing them into non-compliant workarounds.

A 52-person fintech built a payment orchestration platform for e-commerce companies. Their engineering team had 14 engineers. The company had a mature engineering culture: Architecture Decision Records for major technical decisions, a code review policy requiring two reviewers on any PR touching payment logic, and a security champion program where one engineer per team was designated as the first reviewer for security-sensitive changes. In January of the company's fifth year, the VP of Engineering approved a company-wide deployment of GitHub Copilot for Business. The decision was made carefully: Business tier was chosen specifically because it did not use customer code for training and offered a DPA acceptable to the fintech's compliance team. The deployment announcement specified that Copilot for Business was approved for use across the team, with the reminder that engineers should follow their normal code review and security review processes. No additional guidance was provided about AI-generated code specifically — the assumption was that normal review processes were sufficient.

Four months after deployment, a senior engineer on the integrations team was implementing webhook delivery for a new payment processor integration. The webhook system needed to verify incoming webhook signatures using HMAC-SHA256 — a standard implementation for webhook security. The engineer prompted Copilot for the verification function. The suggestion was syntactically correct, logically coherent, and consistent with the team's conventions: compute the expected HMAC from the raw request body and the shared secret, convert both to hexadecimal strings, compare. The comparison was implemented with JavaScript's strict equality operator: computedHmac === receivedHmac. The engineer reviewed the suggestion, confirmed that the computation was correct, and submitted the PR.

The PR was reviewed by two engineers, one of whom was the security champion for the team. The security champion was a strong engineer with good security instincts. He reviewed the PR and approved it after one pass. He later described his review experience: "I saw the Copilot suggestion icon in the diff, verified that the computation was correct — the HMAC construction, the hex encoding — and moved on. I didn't think about timing attacks because I was verifying that the code was doing what the comment said." The code shipped to production. Seven months later, a penetration test commissioned as part of a Series B enterprise readiness review flagged the comparison as a timing-attack vulnerability. A sufficiently motivated attacker who could measure the API response time difference between a signature that matched at byte 0 and a signature that matched at bytes 0–15 could incrementally determine the correct HMAC value without knowing the shared secret. Remediation was straightforward — replace the string equality with crypto.timingSafeEqual(Buffer.from(computedHmac), Buffer.from(receivedHmac)) — and took two hours. But seven months of production webhook traffic had processed signatures using a non-constant-time comparison, during which a sophisticated attacker with network access could have extracted the shared secret. No evidence of exploitation was found, but the remediation required a disclosure to two enterprise customers whose contracts specified notification of security vulnerabilities affecting their integrations.

The structural cause was not that Copilot generated an insecure suggestion — Copilot's training distribution on HMAC implementations reflects the prevalence of string equality in examples that are logically correct but not hardened for adversarial environments. The structural cause was that the team's review process, as applied to AI-generated code, optimized for verifying correctness of the stated intent rather than auditing whether the stated intent was safely and completely specified. The security champion review, which would have been more likely to catch a timing vulnerability in human-written code — because the human author's presence in the code review creates the implicit question "what might they have missed?" — was applied to AI-generated code with the implicit assumption that the AI had already applied a correctness optimization. The assumption is partially valid (the AI did produce logically correct HMAC computation code) and specifically wrong in exactly the category where it matters most (the comparison function is the security-critical boundary, not the computation). Connect this to the code review policy decision record: a code review policy that specifies "two reviewers on payment logic" is specifying a quantity requirement — the number of eyes on the code — without specifying a quality requirement for what those eyes are looking for; for AI-generated code in security-critical paths, the quality requirement matters more than the quantity requirement; a single reviewer using a security-specific checklist for cryptographic code will catch a timing vulnerability that two reviewers without the checklist will miss, because the checklist forces the explicit question ("is any secret-dependent comparison using constant-time comparison?") that the AI suggestion anchoring effect causes reviewers to skip when they are verifying intent rather than auditing safety.

Structural properties set by the AI coding assistant governance decision

Three structural properties are determined by the founding decisions about which AI coding tool tier to allow, which code contexts are in scope for AI suggestions, and what review standard applies to AI-generated code in security-critical paths. None of these properties are visible in the weekly sprint metrics or the quarterly engineering health dashboard. They are set at adoption time and become visible at the first enterprise procurement review, the first penetration test, or the first post-incident code review that traces a security finding to an AI-generated suggestion that passed normal review.

Property 1: The IP exposure surface and the confidential context scope. The IP exposure surface is the set of code and context that may be transmitted to an AI provider's API under the team's current usage model, without the team having explicitly decided whether that transmission is acceptable under their enterprise customer obligations. The surface is invisible unless measured because individual engineers make the tool-usage decision at the file-open level — which files they have open in their editor when they request an inline completion or a chat suggestion — not at the policy level. The surface grows as adoption grows: more engineers adopting the tool means more working directories in scope; engineers moving from inline completion to AI chat modes transmits more context per interaction because chat sessions include the entire active file plus adjacent open tabs rather than just the surrounding function. The surface is shaped primarily by tool tier: personal tiers without DPAs transmit code context under terms that may allow usage for model training and that do not satisfy enterprise customer DPA requirements; business and enterprise tiers provide DPAs, no training data usage by default, and audit log access. The surface only becomes visible when an enterprise prospect requests a vendor security questionnaire that asks which third-party AI services receive code access — a question that every enterprise technology company with a meaningful vendor security program asks as a standard qualification. The surface is not primarily a legal risk — it is a sales risk. Enterprise deals stall not because AI coding tools are prohibited by law or by most enterprise policies, but because the company cannot produce the paperwork that the enterprise security team requires: a DPA specifying what is transmitted, a subprocessor list naming the AI provider, and a data retention policy from the provider. These documents exist for enterprise tiers and do not exist for personal tiers. Connect this property to the data classification decision record: the data classification model and the AI coding tool context scope decision are the same decision viewed from different directions; the data classification model specifies which data types require controlled access — proprietary algorithms, internal pricing logic, database schemas with PII fields — and the AI coding tool context scope decision specifies which of those classified types may appear in code that an AI tool uses as suggestion context; organizations that have a data classification model but no AI coding tool context scope are implicitly deciding that all classified code types are in scope for AI transmission, because engineers will use the tool in their normal working context without a scope exclusion list to consult; the practical implementation is an exclusion file committed to the repository (.copilotignore, .aiexclude, or the tool's equivalent) that patterns from the data classification model — exclude **/migrations/** because migration files contain schema evolution history, exclude **/crypto/** because cryptographic implementations are excluded from AI suggestion context regardless of tier.

Property 2: The security review calibration failure mode and the AI suggestion anchoring effect. The security review calibration failure mode is the systematic reduction in security scrutiny that AI-suggested code receives in security-critical paths relative to human-written code, driven by the implicit assumption that the AI model has already optimized the suggestion for correctness. The calibration failure is present in cryptographic implementations (HMAC comparison, signature verification, random number generation for security tokens), authentication and session management (session regeneration after privilege escalation, cookie attribute specification, OAuth state parameter validation), and payment processing (idempotency handling, decimal precision for financial calculations, concurrency behavior under retry). The failure is observable in code review behavior: reviewers of AI-generated code are more likely to approve in one pass, less likely to ask "why was this implementation chosen rather than the alternative?" and less likely to apply the security checklist they would apply to code they are reviewing for a human author who might have missed something. The calibration failure is not a failing of the reviewers and it is not unique to inexperienced engineers — the timing-attack story's security champion was a strong engineer with good security instincts who caught security issues routinely in human-written code. The failure is structural: the AI suggestion changes the reviewer's mental model from "what might the author have missed?" to "is the author's intent correctly implemented?" Both questions are valid review tasks. Only the first question reliably catches security vulnerabilities in cryptographic code. The AI suggestion anchoring effect shifts reviewers from the first question to the second because the suggestion exists as a completed artifact — the "author" has already answered the implementation question, so the reviewer's attention moves to verification. The mitigation is not to remove AI suggestions from security-critical code (they are often correct) but to require that security-critical code receives a review pass using an explicit checklist that asks the first-question type queries regardless of whether the code was human-written or AI-generated. Connect this property to the API security decision record: the security review calibration failure mode is most acute in API authentication and webhook signature verification code — exactly the code where the API security decision record specifies review requirements — because these are the paths where AI models produce syntactically correct and logically sound suggestions that implement the security primitive correctly while omitting the security hardening that distinguishes a correct implementation from a safe one; the checklist for webhook signature verification is short (constant-time comparison, raw body integrity before JSON parsing, timestamp freshness validation to prevent replay, secret rotation procedure) and any security-aware reviewer who applies the checklist will catch a timing vulnerability; the AI suggestion anchoring effect is the mechanism that causes the checklist to not be applied.

Property 3: The policy uniformity surface and the productivity shadow. The policy uniformity surface is the gap between the company's stated AI coding tool policy and the policy engineers actually follow, which exists when the official policy imposes a cost that significantly exceeds the perceived risk of non-compliance. A blanket ban with no exception path generates shadow usage at a rate proportional to the productivity gap the ban creates. A permissive policy with no review standard generates security surface accumulation at a rate proportional to how security-critical the codebase is. Neither extreme is calibrated to the actual risk profile. The uniformity surface is not primarily a compliance risk — most companies do not audit individual tool usage closely enough to detect and act on shadow usage. The uniformity surface is a feedback loop quality problem. The company that has a blanket ban and significant shadow usage cannot measure whether their policy is calibrated to their actual risk, because the shadow usage is invisible: the engineers using personal tier tools on personal devices are not generating audit logs the security team can review, they have no channel to report a security concern discovered via an AI suggestion without revealing the policy violation, and the security team has no way to distinguish a team that has zero AI coding tool usage from a team that has significant shadow usage. The company that has a permissive policy with no review standard cannot improve their standard because they have no baseline: they do not know what fraction of their codebase was AI-generated, which AI-generated code was reviewed with normal review vs security-specific review, or which security findings in production traces had AI-generated code in their blast radius. The calibrated policy — specifying tier, context scope, and review standard — produces measurably better outcomes than either extreme not because it eliminates AI-generated security vulnerabilities but because it makes the usage visible enough to audit, improve, and calibrate over time. Connect this property to the security scanning decision record: the policy uniformity surface for AI coding tools is structurally identical to the false positive management problem in security scanning — an aggressive SAST policy that generates 200 scanner alerts per PR causes engineers to mark alerts as false positives without reviewing them, which makes the scanner's findings invisible and produces a policy-compliant codebase that is less secure than a codebase scanned by a calibrated SAST policy generating 10 actionable alerts per PR that are reviewed and resolved; the AI coding tool version of this failure is a blanket ban that causes engineers to use personal tier tools invisibly, which produces a policy-compliant audit log that shows no AI tool usage and an actual codebase where AI-generated code from unconfigured personal tier accounts is deployed in payment-critical paths without the context scope controls or review standard that the company would have specified if the usage were visible.

The AI coding assistant governance ADR: five sections

Section 1: Tool tier selection and data handling. The tool tier specification is the first and most consequential section of the AI coding assistant governance decision record because it determines the legal and contractual foundation for every downstream section. Three tiers have materially different characteristics for enterprise customer obligations. Personal or individual tiers (GitHub Copilot Individual, Cursor free/personal, Claude personal API account) typically do not offer a data processing agreement covering transmission and retention of code context, may use code context for model training improvement by default, and do not provide audit log access. Business tiers (GitHub Copilot Business, Cursor Business) offer DPAs, disable training data usage by default, and provide organization-level audit logs of feature usage. Enterprise tiers (GitHub Copilot Enterprise, Cursor Enterprise, Anthropic's enterprise API) offer more granular DPAs, dedicated infrastructure options, and often include provisions for custom retention policies and subprocessor management. For companies selling to enterprise customers — defined practically as any company whose prospects routinely send vendor security questionnaires — the minimum viable tier is business. The DPA and the training data opt-out are not about risk of model memorization (the actual risk of a specific code snippet appearing verbatim in another user's suggestions is low on large models trained on large datasets); they are about the paperwork that enterprise procurement teams require to complete vendor approval. A company that uses personal tier tools and cannot produce a DPA will stall enterprise deals at the vendor security questionnaire stage regardless of whether any actual transmission risk exists. The tier specification should include which tools are approved at which tier, who has authority to approve use of a tool not on the approved list (typically the CISO or VP Engineering), and the process for adding a new tool to the approved list when an engineer identifies a tool they believe would be valuable. The exception process matters: without one, engineers who want to use an unapproved tool will use it anyway and generate shadow usage, which is worse than a controlled exception where the engineer discloses the tool and the security team evaluates it. Connect this section to the SOC 2 compliance decision record: the AI coding tool tier specification is a vendor management decision that affects the SOC 2 third-party vendor assessment list; every AI coding tool used by engineers that may receive code context is a subprocessor for the purposes of enterprise customer DPAs; the SOC 2 audit will ask for the vendor assessment process and the DPA documentation for each subprocessor; the tier specification should be maintained in the company's vendor management registry and reviewed at each vendor assessment cycle, not stored as an engineering team policy document that the SOC 2 auditor may not discover without specifically asking for it.

Section 2: Confidential context scope and excluded file patterns. The context scope specification defines which code is permitted to appear in AI suggestion context and which is excluded, and how the exclusion is technically enforced. The scope decision is more nuanced than the tier decision because the same tool at the same tier may be used safely in one context and unsafely in another. The scope has two dimensions: data handling acceptability (is the code in a category that the DPA covers for the relevant enterprise customers?) and security risk (is the code in a category where AI-generated suggestions in this context carry elevated security vulnerability risk?). The first dimension is satisfied for most code at business tier — schema files, application logic, test code are all within the scope of normal business-tier DPA coverage. The first dimension is relevant for code containing embedded secrets, proprietary algorithm implementations where the novelty itself is IP, and code in directories that contain unpublished research. The second dimension is relevant for cryptographic implementations, authentication logic, payment processing code, and session management — regardless of tier, these code paths benefit from an exclusion not because the transmission risk is higher but because the security review calibration failure mode is highest in exactly these contexts. The practical enforcement mechanism is a configuration file committed to the repository: GitHub Copilot respects a .copilotignore file in the repository root (using .gitignore syntax), which causes Copilot to exclude matching files from inline completion context. Cursor and other tools have equivalent configuration mechanisms. The configuration file should be committed to the repository (so it is version-controlled and applied consistently across all engineers' environments), reviewed when the data classification model changes, and specified as a required file in the repository template so new repositories inherit the exclusion list. The exclusion list should include at minimum: cryptographic implementation directories, directories containing unpublished proprietary algorithms, migration files (because migration histories reveal schema evolution that may expose internal data model decisions), and any directory containing embedded secrets that have not been rotated to an external secret management system. Connect this section to the secrets management decision record: the context scope exclusion list and the secrets management migration are related decisions — code that contains embedded secrets should be excluded from AI coding tool context not because the AI provider will extract the secret (enterprise tier DPAs explicitly cover this), but because normalizing the pattern of AI tools processing files that contain embedded secrets reduces the urgency of migrating to an external secret management system; the context scope exclusion creates a friction signal that reinforces the secrets management decision: when engineers notice that their secrets-containing files are excluded from AI assistance, they are more likely to migrate the secrets to an external system so the file can be brought back into scope, which is the correct outcome.

Section 3: Review standard for AI-generated code in security-critical paths. The review standard specification is the section that prevents the security review calibration failure mode. It specifies which code paths require a review pass against an explicit security checklist rather than normal review judgment, how a reviewer signals that the checklist was applied (not just that the code was reviewed), and which checklist applies to which path type. The standard should cover at minimum three path types. Cryptographic code (HMAC computation and comparison, digital signature verification, symmetric and asymmetric encryption, random number generation for security tokens, key derivation functions): the checklist for cryptographic code should ask whether any secret-dependent comparison uses constant-time comparison rather than string equality; whether the implementation uses library-level cryptographic primitives rather than compound operations on lower-level primitives; whether the key derivation parameters are explicitly specified rather than using library defaults that may change between library versions; and whether error paths in cryptographic operations avoid leaking information through error message content or timing differences in the error response. Authentication and session management code (login flow, session token generation and validation, MFA implementation, OAuth and OIDC flow): the checklist should ask whether session tokens are regenerated after privilege escalation (login, role change, MFA completion); whether cookie attributes are explicitly specified (HttpOnly, Secure, SameSite with the specific value documented for the request patterns in use); and whether any OAuth state parameter or CSRF token is validated before the callback is processed. Payment processing code (amount calculation, transaction recording, idempotency handling, reconciliation logic): the checklist should ask whether all financial calculations use fixed-point arithmetic or decimal types rather than floating-point; whether the idempotency key is validated before any state mutation; and whether the reconciliation logic handles partial failure states without producing double-counting or dropped records. The signal that the checklist was applied should be explicit in the code review: a PR comment from the designated security reviewer that references the checklist and confirms the items were evaluated, not just an approval from someone designated as security champion. Connect this section to the code review policy decision record: the code review policy specifies who reviews what and how many reviewers are required; the AI coding assistant governance decision record extends the code review policy specifically for AI-generated code in security-critical paths, adding the checklist requirement that the code review policy does not specify; the AI coding assistant governance section should be referenced from the code review policy so that reviewers who know the code review policy requirements also find the AI-generated code checklist requirement, rather than treating the governance record as a separate document that only applies when someone specifically remembers to look it up.

Section 4: Exception and escalation process. The exception process specifies how engineers request and receive approval to deviate from the standard policy — use of an unapproved tool, use of an approved tool in an excluded context, or use of a lower tier than the standard requires. The exception process design is the mechanism that determines whether shadow usage develops. An exception process with low friction (request via a Slack channel, security team responds within 1 business day, approvals are tracked in a shared spreadsheet) produces almost no shadow usage because the cost of the exception process is lower than the cost of maintaining shadow usage hygiene on a personal device. An exception process with high friction (written justification reviewed at a monthly security meeting, approval requires VP Engineering signature, exception expires after 30 days requiring renewal) produces significant shadow usage because the friction cost exceeds the productivity benefit for most individual use cases. The exception process should specify: who receives exception requests (the CISO, security champion, or a shared security alias), what information the request should include (tool name, tier, specific use case, estimated duration), the maximum response time (24 hours for standard requests, 4 hours for requests blocking active sprint work), and how approved exceptions are tracked (so the security team can audit the exception log and identify patterns that indicate the standard policy is miscalibrated). The escalation process specifies what happens when an engineer discovers that a colleague is using a tool outside the approved configuration — shadow usage, personal tier in a production codebase, or an excluded context being used with an approved tool. The escalation path should not be anonymous reporting only; it should include a direct conversation path (engineer talks to security champion, not HR or management) that preserves the relationship while allowing the security team to identify and remediate shadow usage without treating policy violations as personnel issues. Connect this section to the production access control decision record: the exception process for AI coding tool policy follows the same design principles as the JIT access process for production system access — friction calibrated to the risk level of the exception request, approval within a time window that does not impede the work the exception enables, and an audit trail that allows the security team to identify patterns in exception requests that indicate the standing policy is miscalibrated; both exception processes fail when the friction exceeds the productivity benefit of the exception, because both failures produce the same outcome — engineers route around the process and generate shadow usage that is invisible to the security team and therefore impossible to audit or improve.

Section 5: Policy review cadence and shadow usage detection. The policy review cadence specifies how often the AI coding assistant governance decision record is reviewed against the current landscape of available tools, enterprise customer requirements, and observed security findings. The landscape of AI coding tools changes significantly faster than most other engineering tool categories: tool capabilities (inline completion, chat, multi-file editing), tool tier structures (pricing and DPA availability), and enterprise customer requirements (DPA specifics, training data opt-out requirements) have each changed materially in the 18 months prior to this writing and are likely to continue changing. A governance decision record for AI coding tools that is reviewed annually will be stale within two review cycles. The practical review cadence is quarterly for the tool tier and DPA landscape (a quick check of whether approved tools have changed their tier structure or DPA terms) and semi-annually for the full record (context scope exclusion list, review standard, exception process). The shadow usage detection mechanism specifies how the security team determines whether the actual AI coding tool usage across the engineering team matches the approved configuration. Three detection mechanisms have different cost-benefit profiles. Audit log review: business and enterprise tier tools provide organization-level audit logs of feature usage, which can be compared against the approved user list to identify engineers using the tool on personal accounts (not appearing in the audit log) or using tool surfaces that generate higher context transmission than normal inline completion; this is the lowest-cost detection mechanism and should run monthly as a 15-minute audit log review. Periodic engineering survey: a quarterly anonymous survey asking engineers which AI coding tools they are currently using, on which tier, and for which types of code; anonymous surveys generate more accurate responses than direct questions because they decouple disclosure from policy enforcement; the survey results should be compared against the approved configuration to identify drift. Anonymous reporting channel: a low-friction path (Slack bot, email alias) for engineers to report shadow usage they observe — their own or a colleague's — without triggering a personnel process; the reporting channel is the most targeted detection mechanism but the lowest-volume, because most shadow usage is not visible to colleagues. Connect this section to the open-source extractor: the AI coding assistant governance decision is one of the clearest examples of a decision that is made in an AI chat conversation — the initial discussion between the CTO and VP Engineering about whether to allow Copilot and at which tier, the follow-up conversation about whether to exclude the crypto directory from suggestion context, the debate about whether a blanket ban or a calibrated policy is the right response to the competitor's blog post story — and produces no written artifact beyond a Slack message or a short email, because the decision feels like a policy preference rather than a technical architectural decision that warrants an ADR; the consequence is that the reasoning behind the tier choice (why business rather than enterprise, what specific DPA provision was the deciding factor), the scope exclusion list (why migrations but not schema files, why crypto but not authentication), and the review standard (why the checklist applies to HMAC but not to OAuth flow code) are not recoverable from the configuration files that implement the decisions; when the enterprise deal's vendor security team asks for the reasoning behind the tier selection, or when a new security champion inherits the role and wants to understand which review checklist to apply to a new payment integration, the decision reasoning is not in the .copilotignore file or the Copilot Business subscription receipt — it is in the conversation threads that preceded both, which are the exact context that WhyChose's extractor surfaces from AI chat export history.

FAQ

What is the difference between GitHub Copilot Individual, Business, and Enterprise for code governance?

The difference that matters for enterprise customer data handling obligations is the data processing agreement and the training data policy. Copilot Individual (the free or paid personal tier) may use your code suggestions and context to improve GitHub's AI models by default, and does not offer a DPA that specifies what data is transmitted or retained. Copilot Business and Enterprise provide a DPA, do not use your code for training by default, and offer audit log access. For companies selling to enterprise customers who require a SOC 2 Type II report or who request a data processing agreement as a condition of purchase, using a personal AI coding tier without a DPA creates a disclosure gap: if the enterprise customer asks "does any third-party AI service receive access to code that implements features we use?", the accurate answer on a personal tier is "yes, but we do not have a DPA specifying what is transmitted or retained" — which many enterprise procurement teams will treat as a blocker. The governance decision record should specify which tier is required, who has authority to approve exceptions, and what the audit process looks like for confirming tier compliance across the team.

Which types of code should be excluded from AI coding assistant context?

The exclusion list should be driven by the code's sensitivity classification rather than its file type. Four categories warrant exclusion from suggestion context regardless of tier. First, cryptographic implementations: HMAC computation, signature verification, encryption key derivation, and any code whose correct behavior depends on constant-time comparison or careful bit-level implementation — AI models optimize for logical correctness, not for resistance to timing and side-channel attacks. Second, authentication and session management: login flow logic, session token generation, password hashing parameter selection, MFA implementation — the AI's training distribution on authentication code skews toward common patterns that may omit critical security hardening steps. Third, payment processing and financial calculation: any code touching account balances, transaction amounts, tax computation, or reconciliation logic — precision errors in financial code are difficult to detect in review and expensive to remediate in production. Fourth, code containing embedded secrets or novel proprietary algorithm implementations. The exclusion list should be maintained in a configuration file committed to the repository (.copilotignore or equivalent) so it is version-controlled and applied consistently rather than stored as informal team knowledge that is not enforced technically.

What review standard should apply to AI-generated code?

The same standard as human-written code for normal paths, and a higher standard for security-critical paths. The reason a higher standard is needed for security-critical code is not that AI models produce worse security than humans on average — they may not — but that the code review process applies systematically lower scrutiny to AI-suggested code because the suggestion anchors the reviewer to verifying intent rather than auditing safety. The practical mitigation is to require that AI-generated code in security-critical paths be reviewed by a designated security-aware reviewer using an explicit checklist rather than normal review judgment. For cryptographic code: does this use constant-time comparison for any secret-dependent value; does this use library primitives rather than compound operations; are key derivation parameters explicitly specified? For authentication code: is the session token regenerated after privilege escalation; are cookie attributes (HttpOnly, Secure, SameSite) explicitly specified? For payment code: does financial calculation use fixed-point or decimal types; is idempotency validated before state mutation? The checklist items are not complicated — they are questions any security-aware engineer would ask. The point of the checklist is to make them mandatory rather than optional for the reviewer, so that the anchoring effect of the AI suggestion does not cause the reviewer to skip questions they would have asked of human-written code.

What should an AI coding assistant governance decision record specify?

Five specifications. First, tool tier selection and data handling: which AI coding tools are approved at which service tier, and the data handling commitments from each provider that satisfy the company's enterprise customer obligations. Second, confidential context scope: which directories, file patterns, or code classifications are excluded from AI suggestion context, how the exclusion is enforced technically, and who maintains the exclusion list. Third, review standard for AI-suggested code in security-critical paths: which paths require a designated security-aware reviewer, what the review checklist covers for each path type, and how a reviewer signals that the checklist was applied rather than normal review judgment. Fourth, exception and escalation process: how an engineer requests an exception to the tier policy, who approves exceptions within a defined response time, and how approved exceptions are tracked for audit and policy calibration. Fifth, policy review cadence and shadow usage detection: the quarterly and semi-annual review schedule for the tool landscape and the full record, and the detection mechanisms (audit log review, periodic survey, anonymous reporting channel) that allow the security team to identify shadow usage and calibrate the policy against actual rather than assumed usage.

Structural properties set by the AI coding assistant governance decision

The AI coding assistant governance ADR: five sections

FAQ

Further reading