What Can You Share with AI? Approval Criteria for Enterprise Code and Customer Logs

1. The answer: define the conditions that authorize work

“Are you sure this is safe?” should not be the end of the meeting. The useful answer is a set of approval conditions and an owner who verifies them. A traffic light has more than one job: it must also let people move when the light turns green.

This article proposes an adoption policy for ordinary enterprise development and SaaS operations. Based on public primary sources checked on September 19, 2026, it separates public information, ordinary internal code and real customer data. Adopt the following decisions as company policy after checking applicable law, customer agreements and existing internal rules.

“Allowed” means an authorized business activity, not a prediction that no incident will ever occur. Having an appropriate processor handle confidential source code is different from publishing it to the world. Where current policy bans the activity, use this article as a proposal to revise that policy.

This is consistent with official guidance. Japan's Ministry of Economy, Trade and Industry (METI) discusses contractual restrictions and internal rules for secure use of generative AI and translation tools, rather than relying solely on prohibition. ^[1] NIST recommends minimum thresholds for deployment decisions and reassessment of risk tolerance. ^[2]

For a practical starting point, read Section 3 on repositories, Section 4 on incident investigation and Section 8's approval template. The six criteria and 30-day pilot below are this article's operational proposals. They are not a common standard certified by a regulator or vendor.

2. Establish one environment approved for business information

Instead of making every employee interpret every policy, have an administrator approve a specific combination of product, plan, organization, model and integrations. A company-paid ChatGPT Pro subscription remains an individual plan. Claude Code's terms also depend on how the user authenticates and accesses it.

Approve an environment for ordinary internal information when these four requirements are met:

• Purpose: limit processing to the business purpose and stop provider model-training use. Disable feedback sharing where available, or prohibit sharing confidential conversations through feedback controls.
• Retention and deletion: document the periods and exceptions for conversations, attachments, indexes and monitoring logs, human access conditions and account-closure handling. They must fit your classification and customer obligations. A company that accepts 30-day monitoring retention for ordinary code can approve that use on those terms.
• Administration and routing: use company-managed accounts, MFA, offboarding and appropriate access. Identify the application, model providers and search or MCP destinations; disable unapproved integrations.
• Contracts and response: verify confidentiality, purpose restrictions, subprocessors, international processing, deletion and incident notification. Obtain the data owner's approval and any required DPA or customer authorization.

Training updates model weights; inference and conversation storage are separate activities. Answering a question does not automatically write its contents into a model shared with the world. Give training use and retention separate fields in the approval record.

For example, OpenAI API abuse-monitoring logs are generally retained for up to 30 days; approved Zero Data Retention has endpoint limitations and exceptions. ^[13] Anthropic's policy effective June 9, 2026 describes generally 30-day safety retention for covered models, with model scope and eligible-organization exceptions to check. Cursor's September 3 update also describes retention exceptions. If a contract prohibits retention, exclude incompatible models. If it permits retention, document the accepted period and proceed. ^[14][7]

Reputation helps build a shortlist. This precise service configuration is the unit of approval. Check the terms for OpenAI and Anthropic, and apply the same criteria to a startup. When using audit reports as evidence, verify which service and controls the audit actually covers.

3. Authorize repository access when these six conditions are met

This baseline applies to ordinary company-owned application code, tests and technical documentation. Route customer-owned code, sensitive unpublished technology and regulated data to Section 5. Ordinary source code does not require every word to be anonymized. Company names, class names and business logic can remain when the approved environment is authorized to process them.

Ordinary code that satisfies these six conditions and Section 2 becomes permitted under the adopted policy. Do not extend review indefinitely with “there might be something else.” Identify a specific unresolved item. Have the repository owner classify commercial secrets that credential scanners cannot recognize.

GitHub secret scanning examines the Git history across all branches and other supported surfaces. ^[15] If the agent can read history, scanning only current files does not cover its access. For a faster start, provide a history-free copy of only the current code needed for the task, with access to the original repository and neighboring directories blocked.

Revoke and replace exposed credentials before treating deletion as remediation. A revoked value need not be counted forever as a live secret, although accompanying customer identifiers still require their own handling. Explain what happened to each finding instead of pursuing a cosmetically empty scan report.

Test exclusions in the feature you will actually use. GitHub announced general availability of content exclusions in Copilot app and CLI on September 2, 2026, while its documentation describes limitations for IDE Edit and Agent modes. ^[16][17] Use harmless test markers to verify that reads of excluded locations are blocked. A .gitignore file controls Git tracking; it is not a read-access boundary.

Separate the ordinary baseline from additional safeguards

The ordinary route uses the six criteria above. Do not universally require complete anonymization of every historical commit, two-person review of every file, a private circuit or a local LLM. Information kept outside the submission and access scope need not be part of a company-wide cleanup project before AI use begins. Remediation of existing credential exposure should continue in parallel.

For highly sensitive algorithms or customer-specific environments, add repository separation, negotiated terms, stricter retention, dedicated processing or two-person approval. The additional controls follow the sensitivity and potential damage. A scan is evidence about tested conditions, not proof that unknown defects have disappeared.

4. Troubleshoot with the smallest set that preserves the cause

SaaS incident investigation usually needs errors, timing, versions, relevant code and reproduction steps, rather than a customer directory. Standardize the following transformations so that every engineer does not have to invent a policy during an outage.

An invented example changes “customer=real name, email=real address, token=secret, HTTP 401” into “tenant=TENANT_01, user=USER_01, HTTP 401, token_expired=true, SDK 2.4, happens only after refresh.” Refresh logic and clock skew can be investigated without disclosing the token.

The acceptance test is: no authentication secrets or unnecessary identifiers, enough context to reproduce the issue, and a destination approved for the remaining information category. Read the transformed log once, including free text and images that pattern matching handles poorly. If reproduction fails, add only the next necessary detail.

Some bugs depend on an actual customer's name. First reproduce the same character type, length or Unicode normalization with a synthetic name. If real data remains necessary, authorize a scoped processing engagement under Section 5, specifying the customer, fields and period. Japan's Personal Information Protection Commission (PPC) explicitly discusses maintenance that handles real personal data through consent or entrusted processing. Privacy rules do not require all work involving personal data to stop. ^[18]

Do not automatically label replaced records as legally “anonymously processed information.” Where a mapping or combination can still identify someone, manage the remaining information accordingly. A record of what was removed and retained is more useful than an unsupported “anonymized” label.

5. Company-specific decisions: customer contracts and real data

“Summarize Toyota's published financial results” uses public information. “Summarize our unpublished proposal to Toyota” discloses a potential business relationship. These are hypothetical examples, but they show that the attached context matters more than the corporate-name string.

Distinguish a corporate name from a contact's name, sole-proprietor information or an employee number readily linked to a person. Email addresses likewise require an identifiability assessment. ^[19][20] The mere presence of a public corporate name need not make its removal a condition of approval.

Give the contract owner a specific question, rather than “Is AI safe?” METI's contract checklist is a useful primary reference for examining the permitted scope of input-data use. ^[21]

For personal data, check the necessary business purpose and whether the provider uses it for its own training or other purposes. ^[22] Under Japan's rules, overseas entrusted processing generally raises consent requirements, subject to exceptions including qualifying countries or equivalent protective arrangements. Record the legal route selected by counsel or the privacy owner, rather than using the existence of a DPA as the answer. ^[23]

An SLA is an agreement about service levels; an SLO is a target level of service. ^[24] A 99.9% availability figure does not authorize a data transfer or establish an acceptable disclosure rate. Check data handling in NDAs, DPAs and security schedules; check continuity in SLAs, SLOs and fallback procedures. Both may appear in the same contract, but answer different questions.

Turn unresolved issues into an owner, a question and a deadline: counsel determines whether a subcontracting clause applies; the account owner obtains customer approval. While a novel legal issue is being resolved, work with public information, company-owned code or synthetic examples can continue. There is no need to test unclear rights by submitting the disputed data.

6. Choose network and credential controls that meet the requirement

Review AI using the same purpose, contract, identity, retention and audit criteria used for Gmail or AWS. Add instructions embedded in external content and the agent's ability to act as specific AI considerations.

Choose the processing route as follows:

• Ordinary internal code: when policy permits public-network transport, use an approved business service protected by TLS. AI use alone need not trigger a private-circuit requirement.
• A contract or policy requires private connectivity: choose a supported option such as PrivateLink and verify DNS, routing and endpoints.
• External processing itself is prohibited: use an internally hosted LLM with controlled egress or a customer-authorized environment. Include search and telemetry in the outbound-path review.

HTTPS uses TLS to protect communication to the service endpoint. Traffic does not become plaintext merely because it leaves a VPN. Include any corporate TLS inspection proxy in the managed trust boundary. ^[25] Bedrock PrivateLink is a connectivity option; select model retention separately. Bedrock also provides controls that reject calls to retention-requiring models when incompatible with a ZDR requirement. ^[26][27]

Name the exact service. Google Cloud Translation API explicitly describes non-use for training or improvement. ^[28] Do not extend that approval to a consumer translation page. Cursor requests pass through its backend even with a customer's own API key, and Copilot search or additional agents can introduce other processing destinations. Record the entire route. ^[7][12]

Keep authentication in AWS Secrets Manager, Infisical, OS Keychain or an equivalent facility. Prefer short-lived credentials, IAM roles and OIDC. Tell the model which authentication route to use, with the execution tool authenticating when needed instead of exposing the secret value. A login ID is not necessarily a credential on its own; classify it as identifying information. ^[29]

Choose an appropriate Devin Secrets scope: Global, Personal, repository or session. Global Secrets can be used by sessions across organization members, so credentials for Customer A's investigation belong in a suitably limited scope. ^[30] Start with read-only, scoped access, without granting unnecessary ability to retrieve and print Keychain secrets.

Google SAIF describes least-privilege agent permissions and user control over actions. ^[31] Use facilities such as Claude Code or Codex sandboxing to control reading, outbound transfer and modification separately. Verify actual filesystem and network boundaries rather than inferring them from a preset's name. ^[32][33] An ordinary initial deployment can permit code investigation and proposed changes, with human approval for production deployment, external disclosure and deletion.

7. Translate past incidents into approval requirements

An incident list is useful when it changes a control, not merely when it makes the reader anxious. Map each failure mechanism to something that can be checked before approval.

The March 2023 event preceded ChatGPT Enterprise's August launch and was not reported as training-data contamination. Do not recast it as an Enterprise training-policy breach. ^[37] This research did not establish a primary-source incident matching that description.

Instead of trying to prove the absence of future defects, limit scope, examine the provider's remediation and notification capabilities, and authorize use with a workable stop mechanism. The same approach applies to email and cloud services. Without comparable incident-rate evidence, assigning a percentage to how much more dangerous AI is than email adds less value than reducing actual data and permissions at risk.

Borrow enterprise operating practices, not just company names

Morgan Stanley announced its OpenAI-powered customer-meeting assistant, Debrief, in June 2024. It records with client consent, and advisers edit and send the resulting emails. The announcement's 98% adoption figure concerned adviser teams using a separate internal-search Assistant. Consent, bounded purpose and human review can create a viable route even for customer-facing work. ^[38]

Japan's SMBC Group also announced that its internal SMBC-GAI assistant began using OpenAI's API in September 2024. ^[39] This demonstrates that a financial institution can adopt external AI organizationally. The permitted treatment of a particular dataset still follows your own classification and contracts.

Translate those practices into boundaries within a task: “meeting-note drafts are allowed; a person sends the message,” or “investigation of this code is allowed; merge follows review.” Place controls between stages of work rather than trying to approve or prohibit the entire company in one decision.

8. An approval template and a 30-day rollout

The following example authorizes ordinary source-code work. Fill in the product, scope and owners, attach evidence, and turn a yes-or-no debate into a review of concrete conditions.

We authorize code investigation, test creation and proposed fixes using [organization, product, plan and model] for [repository and readable scope]. [Owner and date] verified the environment requirements in Section 2 and six criteria in Section 3. Repeated use within this scope does not require individual approval. Real customer data, authentication secrets and designated highly sensitive information are excluded. Production changes require human approval; adding an external destination requires separate review. Reassess on changes to contracts, models, integrations or information classification, and on [review date].

Attach five items: purpose and scope; contractual provisions and settings evidence; scan results and dispositions; verification of read, network and action restrictions; and owners plus a stop procedure. Avoid copying payloads or secret values into the audit record itself.

One workable proposal is one ordinary repository, one team, 30 days. The period organizes evaluation; it does not prove safety.

1. Before starting: the data owner and administrator verify the baseline. Send only unresolved contractual questions to counsel. Start with ordinary code and sanitized logs.
2. During the pilot: record investigation time, acceptance of suggested fixes, defects found in review, prohibited-data detections and false positives. Evaluate productivity and whether controls actually operate.
3. Immediate stop triggers: a live secret is sent, unexpected customer data becomes accessible, information reaches an unapproved destination or the agent exceeds its permissions. Disable the relevant integration or credentials, preserve evidence and follow contractual notification procedures.
4. At review: expand to similar repositories when benefits and control evidence support it. Document false-positive exceptions; tighten conditions when sensitivity or processing destinations change. Set the next review date.

Route legal interpretation to counsel, contractual consent to the account owner, and inadequate isolation to the administrator. For example, set an internal target of five business days to return approval, additional requirements or an alternative. The deadline means a reasoned decision and a next option, not automatic permission when the clock runs out.

NIST's deployment thresholds and reassessment approach support this style of operation. ^[2] Expand based on evidence that the same data classification and controls apply, rather than simply counting incident-free days.

Companies need repeatable work with clear permission, not a daily test of individual courage. Identify what must be protected, meet the conditions and allow the work to proceed. Reviewers should explain both what is missing and what would make approval possible. That is a useful standard for enterprise AI adoption.

The acceptance criteria and approval text are templates for an adoption policy. Adapt them to applicable law, customer agreements and your information classification. Distinguish official guidance from this article's proposals and recheck terms at adoption and material change. Existing illustrations are AI-generated.

References

1. [1]METI: Technology Leakage Prevention Guidance 2.0, measures, p.89. ↩
2. [2]NIST AI 600-1: Generative AI Profile, GV-1.3-002, 006 and 007. ↩
3. [3]OpenAI: How your data is used to improve model performance. ↩
4. [4]OpenAI: Business data privacy, security, and compliance. ↩
5. [5]Anthropic: Consumer model-training policy, March 16, 2026. ↩
6. [6]Anthropic: Commercial model-training policy, August 18, 2026. ↩
7. [7]Cursor: Data Use & Privacy Overview, updated September 3, 2026. ↩
8. [8]Cursor: Privacy and data. ↩
9. [9]Cognition: Security at Cognition; training, Data Controls and Enterprise terms. ↩
10. [10]GitHub: Managing GitHub Copilot policies as an individual subscriber. ↩
11. [11]Google: Generative AI in Google Workspace Privacy Hub. ↩
12. [12]Microsoft: Data, Privacy, and Security for Microsoft Copilot. ↩
13. [13]OpenAI: API data controls, retention and ZDR exceptions. ↩
14. [14]Anthropic: Data retention practices for Covered Models; effective June 9, 2026. ↩
15. [15]GitHub: Secret scanning scope. ↩
16. [16]GitHub: Content exclusion and feature limitations. ↩
17. [17]GitHub: Content exclusions generally available in Copilot app and CLI, September 2, 2026. ↩
18. [18]PPC: Maintenance providers handling personal data, Q7-55. ↩
19. [19]PPC: General Guidelines under the APPI. ↩
20. [20]PPC: Email addresses as personal information (Q1-4). ↩
21. [21]METI: Checklist for AI use and development contracts, February 2025. ↩
22. [22]PPC: Notice on generative AI use, June 2, 2023. ↩
23. [23]PPC: Overseas outsourcing and consent (Q12-1). ↩
24. [24]Google SRE: Service Level Objectives; SLI, SLO and SLA definitions. ↩
25. [25]IETF: RFC 8446, TLS 1.3; confidentiality and integrity in transit. ↩
26. [26]AWS: Protect your data using Amazon VPC and AWS PrivateLink. ↩
27. [27]AWS: Amazon Bedrock data retention. ↩
28. [28]Google Cloud: Cloud Translation data usage FAQ. ↩
29. [29]OWASP: Secrets Management Cheat Sheet. ↩
30. [30]Cognition: Devin Secrets & Site Cookies; scopes and usage access. ↩
31. [31]Google SAIF: Controls; Agent Permissions and Agent User Control. ↩
32. [32]Anthropic: Claude Code sandboxing. ↩
33. [33]OpenAI: Agent approvals and security. ↩
34. [34]OpenAI: March 20 ChatGPT outage, reported March 24, 2023. ↩
35. [35]Microsoft: AI Application Security Series 1, December 17, 2025; EchoLeak remediation. ↩
36. [36]OpenAI: The Hugging Face incident and the road ahead, August 26, 2026. ↩
37. [37]OpenAI: Introducing ChatGPT Enterprise, August 28, 2023. ↩
38. [38]Morgan Stanley: AI @ Morgan Stanley Debrief launch, June 26, 2024. ↩
39. [39]SMBC: Agreement with OpenAI, October 15, 2024. ↩