What breaks when organisations do not measure AI-generated code by developer and assistant?

When organisations do not measure AI-generated code by developer and assistant, they lose the ability to identify power users, adoption patterns, and the real footprint of each coding assistant. That makes it difficult to compare productivity, detect risky usage, or explain AI impact to leadership. The result is weak accountability and controls that are too generic to be useful.

Why This Matters for Security Teams

Measuring AI-generated code only at the team or repository level hides the operational reality that different developers and assistants create different risk profiles. One engineer may use a coding assistant for boilerplate, while another uses it for sensitive refactors, secrets handling, or infrastructure code. Without per-developer and per-assistant attribution, security leaders cannot separate adoption from exposure, and governance becomes too coarse to answer basic questions about accountability, drift, or control effectiveness.

This matters because modern code security depends on traceability, not just volume. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls expects organisations to maintain auditable control over access, activity, and security-relevant events, which becomes harder when assistant output is blended into normal developer work. NHIMG research on The State of Secrets in AppSec shows how quickly secrets risk becomes material when developer behaviour is not measured well enough to target controls.

In practice, many security teams discover assistant-driven risk only after a leak, unsafe commit, or compliance question has already forced them to reconstruct who used what, when, and for which task.

How It Works in Practice

Effective measurement starts by treating AI assistance as a distinct source of code activity rather than as a vague productivity layer. The goal is to attribute generated code and related actions to both the human developer and the assistant model or tool, so leaders can compare behaviour across users, teams, and use cases. That does not mean labelling every keystroke. It means capturing enough telemetry to answer who initiated the prompt, which assistant responded, what code was accepted, and whether the output touched sensitive assets.

In mature environments, this is usually implemented through IDE plugins, code platform telemetry, prompt logging with appropriate privacy safeguards, and policy-as-code controls that classify risky patterns at commit or review time. The measurement layer should also connect to identity and access records so the organisation can correlate assistant use with privileged repos, secrets exposure, or unusually high acceptance rates. That gives security teams a way to identify power users, outlier behaviour, and assistant-specific control gaps.

For code security governance, the practical benchmark is not simply “AI used or not used.” It is whether the organisation can distinguish assistant output from human-authored code and evaluate the downstream impact. That aligns with control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and with NHIMG analysis in DeepSeek breach, where uncontrolled code and data pathways amplified downstream exposure.

• Track usage by developer, assistant, repository, and code path.
• Measure acceptance, rejection, and editing rates for generated suggestions.
• Tag prompts and outputs that involve secrets, infrastructure, or privileged logic.
• Correlate assistant usage with defects, review findings, and policy violations.

These controls tend to break down in large monorepos and shared developer environments because attribution gets blurred when multiple people, bots, and assistants touch the same files in rapid succession.

Common Variations and Edge Cases

Tighter measurement often increases privacy, tooling, and governance overhead, so organisations must balance visibility against developer friction. There is no universal standard for this yet, and current guidance suggests measuring enough to support security and accountability without turning telemetry into indiscriminate surveillance.

One common edge case is pair programming or shared workstation use, where developer attribution is noisier and assistant actions may be misclassified. Another is offline or local model use, where central logs may not capture prompt content even when code output is later committed. In those cases, organisations should rely on lightweight identifiers, repository-linked metadata, and review workflows rather than trying to force full content capture. The same is true for regulated environments where prompt logging may be constrained by policy.

Measurement also breaks down when organisations treat all assistants as equivalent. Different models, extensions, and workflows generate different risk levels, so assistant-level reporting should include the tool name and version, not just a generic “AI used” flag. NHIMG research such as Schneider Electric credentials breach and Google Firebase misconfiguration breach reinforces the point that weak attribution and weak control granularity quickly become operational exposure, not just reporting noise.

Related resources from NHI Mgmt Group

• What breaks when organisations treat AI-generated code as automatically trusted?
• What breaks when organisations rely on static checks alone for AI generated code
• What breaks when organisations rely on post-code scanning alone for AI-generated code?
• What breaks when organisations do not control AI connectors to corporate data sources?