Provenance & Attribution in Tabnine CLI

Provenance and Attribution (P&A) enforcement for generated code now applies to the Tabnine CLI.

Overview

Provenance and Attribution (P&A) enforcement for generated code now applies to the Tabnine CLI. This mirrors the existing IDE behavior, preventing non‑permissive open‑source code from being suggested and adding attribution for permissive code.

How it works

All code generated by the CLI is passed through the P&A pipeline before it is shown or applied. Generated output is split into small windows, hashed, and checked against an Attribution Bloom Filter and metadata service.

If a window matches code from a non‑permissive license, that snippet is censored. If it matches code under a permissive license, the code is allowed but accompanied by an attribution notice.

Surfaces covered in the CLI

P&A enforcement covers all CLI code‑generation flows, including:

• write_file output.

• replace output (the new_string content).

• Code blocks returned in Agent chat responses.

• Any generated code that the CLI applies to the filesystem.

The user only sees code that has passed the P&A checks. Blocked snippets are replaced with a clear notice rather than silently dropped.

Censorship behavior

If a snippet matches a non‑permissive license, the CLI censors that part of the output. The CLI displays a message such as:

“A portion of the generated code was removed because it matched code with a non‑permissive license <license>. Source: <repo>.”

The censored code is not written to disk or shown inline. A corresponding event is logged to the attribution log service for audit and analytics.

Attribution behavior

If a snippet matches a permissively licensed source, the code is shown normally. An informational line is printed alongside the output, for example:

“Attribution: This code is similar to <repo> (<license>) — <file>:<line>.”

Attribution messages appear in the CLI output but are not inserted into the generated files. This helps developers track provenance without polluting code with comments.

Admin governance and configuration

P&A censorship uses the existing governance settings from the admin console. Admins can enable or disable censorship mode and control how attribution is displayed.

CLI deployments in EMT / self‑hosted environments use the same P&A endpoints and configuration as the IDE. No separate policy system is required for the CLI.

Logging and analytics

Each P&A event from the CLI is logged with timestamp, organization, user, source (cli), model, and license metadata. Two key analytics events are emitted:

• cli_code_censored – code blocked due to non‑permissive license.

• cli_code_attributed – permissive code with attribution details.

These logs help security and compliance teams monitor how P&A is working across their estate.