Identify the exact usage model
Bind the admission decision to a specific version, contract, configuration and use case. Reassess when product tier, deployment region or configuration changes.
- Public cloud assistants: verify submitted content, retention, training use and enterprise account controls.
- Enterprise cloud or dedicated instances: verify tenant isolation, region, subprocessors and administrator access.
- Self-hosted deployments: verify model and dependency provenance, updates, network boundaries and operational responsibility.
- IDE plugins or agents: verify file reads, command execution, network access and writes; use workspace allowlists, approval and isolation.
- CI/CD agents: verify token, branch, artifact and deployment permissions; use short-lived credentials, protected branches and human release gates.
Eight questions that define the data boundary
Use contracts, formal security and privacy documents, administrator configuration and observed network behavior as evidence. Marketing copy or verbal assurances are not enough by themselves.
- Does the tool receive diffs, full files, repository indexes, terminal output or runtime logs?
- Is data processed locally, in an enterprise tenant or by a third-party service?
- How long are inputs, outputs, prompts and telemetry retained, and can they be disabled or deleted?
- Is data used for training, quality improvement, human review or another secondary purpose?
- Are cross-border transfer, overseas storage or subprocessors involved?
- Which policies or contracts cover source code, client material, personal data, secrets and logs?
- How are security incidents, product changes and service termination reported and handled?
- Can the enterprise export evidence of users, time, repository scope and actions?
Apply least privilege
- Repository scope: begin with a pilot repository or named directories and exclude core algorithms, client code, secrets and licensed material where required.
- Action scope: treat read-only understanding, patch generation, test execution, branch creation, pull requests and direct merges as separate permissions.
- Credential scope: use short-lived, revocable, single-purpose identities; never place production secrets or administrator tokens in prompts, configuration, scripts or logs.
- Network scope: limit domains, package sources and internal interfaces; run command-capable agents in isolation with egress and high-risk command controls.
Minimum admission evidence
- Data use: a contract or formal policy states training, retention and deletion rules; otherwise, do not upload internal code.
- Identity and access: enterprise accounts, roles and least-privilege test records; otherwise, use only public code or offline experiments.
- Secret protection: scanning, variable isolation, short-lived credentials and rotation; otherwise, prohibit tasks involving real credentials.
- Audit logs: searchable user, time, repository and action scope; otherwise, do not allow automatic writes or execution.
- Supply chain: traceable plugins, models, images, dependencies and updates, with approved versions pinned.
- Validation and exit: code review, tests, account recovery, token revocation, cache cleanup and data-deletion procedures.
A controlled pilot path
- Stage one uses public code, template projects or de-identified data without production accounts.
- Stage two limits named users, directories and read-only access to a low-risk internal repository; outputs arrive as patches or isolated branches.
- Stage three considers branch creation, test execution or pull requests only after earlier evidence passes; main-branch and deployment approval remain separate.
- Stage four periodically reviews tool versions, models, terms, subprocessors, accounts, tokens, logs and exclusion rules.
Be able to stop and reconstruct an incident
The enterprise should be able to disable accounts or plugins, revoke tokens, freeze automated execution, identify affected repositories, preserve audit records, assess exposure and complete notification, credential rotation or code repair. Automation without exit and traceability controls is unsuitable for critical development paths.
Does a no-training statement make it safe to upload all code?
No. Also verify retention, human review, telemetry, subprocessors, region, account isolation, contractual responsibility and actual settings, while honoring enterprise and client restrictions.
Is self-hosting always safer?
No. It changes the data path but places responsibility for models, images, dependencies, patches, identity, network and operations on the enterprise. Suitability depends on the threat model and operational capability.
Should an AI agent modify the main branch directly?
Not by default. Generate changes in an isolated branch, run deterministic checks and human review, then merge through protected controls. High-risk systems also need specialist approval and target-environment validation.
How should secrets and production logs be handled?
Establish secret scanning, log redaction and data classification first. If a real credential reaches code or a prompt, revoke and rotate it under the incident process; deleting chat or commit history alone is insufficient.
Sources and scope
- NIST Secure Software Development Framework: https://csrc.nist.gov/pubs/sp/800/218/final
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- NIST Generative AI Profile: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- This engineering admission framework is not a security certification for any product and does not replace legal, security, privacy or procurement review.