Problem description
A customer asked two questions about Neo that I could not answer from the public docs:
- What underlying model(s) power Neo? Which provider(s) and model families are used, whether that can change over time, and whether customers are notified of changes.
- How is Neo "trained"? Specifically, whether customer data (IaC source, stack state, resource metadata, prompts, task transcripts) is ever used to train or fine-tune a model, and whether any of it is retained by the model provider.
The Neo docs currently cover capabilities, tasks, modes, RBAC boundaries, and VCS requirements, but not model provenance or data handling for model inference. The docs do explain that Neo operates within the conversing user's RBAC entitlements and cannot perform actions the user couldn't perform themselves, which addresses authorization but not data flow to a model provider.
The Cloud REST API reference for Neo references a "primary model used by this task" and a context window in tokens, which implies a specific model is in play, but the model is never named or described anywhere in the docs.
This comes up in nearly every security review, so it is likely a recurring blocker for enterprise evaluations.
Affected product version(s)
Pulumi Cloud / Pulumi Neo (GA), current docs as of the date of this issue. Not version-specific.
Suggestions for a fix
Add a section to https://www.pulumi.com/docs/pulumi-cloud/neo/ (or a dedicated "Neo: models and data handling" page linked from the Neo overview and from the Trust Center) covering:
- Which model provider(s) and model family Neo uses, and a statement on how model changes are communicated
- An explicit statement on whether customer data is used for model training or fine-tuning
- Data retention terms with the model provider (e.g. zero-data-retention agreements, if applicable)
- What data is sent to the model on a given task: prompt text, IaC source, stack state, resource metadata, ESC values
- Whether any regional or data-residency guarantees apply to model inference
- A link to the relevant DPA / subprocessor list
Problem description
A customer asked two questions about Neo that I could not answer from the public docs:
The Neo docs currently cover capabilities, tasks, modes, RBAC boundaries, and VCS requirements, but not model provenance or data handling for model inference. The docs do explain that Neo operates within the conversing user's RBAC entitlements and cannot perform actions the user couldn't perform themselves, which addresses authorization but not data flow to a model provider.
The Cloud REST API reference for Neo references a "primary model used by this task" and a context window in tokens, which implies a specific model is in play, but the model is never named or described anywhere in the docs.
This comes up in nearly every security review, so it is likely a recurring blocker for enterprise evaluations.
Affected product version(s)
Pulumi Cloud / Pulumi Neo (GA), current docs as of the date of this issue. Not version-specific.
Suggestions for a fix
Add a section to https://www.pulumi.com/docs/pulumi-cloud/neo/ (or a dedicated "Neo: models and data handling" page linked from the Neo overview and from the Trust Center) covering: