> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/4.-data-protection-and-residency/4.2-data-classification-for-ai-prompts-and-outputs.md). # 4.2 Data classification for AI prompts and outputs Which data classes may touch which AI tools and how to enforce the matrix technically across browsers, endpoints, APIs, and agents. *Last reviewed: August 18, 2026* {% hint style="info" %} AI policy needs a data-class matrix. Users should know which data classes can enter which tools before a prompt is written. {% endhint %} ## Data classification for AI prompts and outputs: what security teams need to know Data classification turns AI policy from a slogan into a decision table. The table should say which data classes are allowed in each tool, account type, connector, model endpoint, and deployment mode. Classification should cover outputs too. An AI-generated answer can contain secrets, customer data, source code, or regulated information copied from context. ## Common data classification for AI prompts and outputs security failures * The policy says confidential data is restricted, but tools are not mapped to data classes. * Outputs are shared externally without reclassification. * Users cannot tell whether source code, logs, or tickets count as sensitive. * Artifacts and connector writes inherit the source data class but are never relabeled. * Regulated data is allowed in chat but not in API workflows, or the reverse. ## Data classification for AI prompts and outputs security controls checklist * Define data classes that users understand. * Create a class-to-tool and class-to-action matrix. * Include prompts, uploads, retrieved context, tool parameters, outputs, and artifacts. * Require stronger controls for regulated data, customer data, source code, and secrets. * Review output-sharing paths such as links, exports, artifacts, and connector writes. ## Anthropic ### Overview A class-to-tool matrix maps onto three Anthropic levers. Enterprise custom roles decide which groups get which capabilities — chat, code execution and file creation, skills, Claude Code, Cowork — so a role can embody "this team may use this surface with this data class." Connector permissions add the class-to-action dimension: each connector can require approval, be blocked, or be always allowed, and connectors act according to the person's source-system permissions, so the source ACL remains part of the effective classification. Outputs need their own row in the matrix. Artifacts require the code execution and file creation capability and inherit whatever data class entered the conversation. The Claude Office add-ins can pass context between open Excel, PowerPoint, Word, and Outlook files, so classify the cross-app session at the highest input class and review the target file before writing into it. For Claude Tag, classify the Slack channel, its inherited workspace memory, and every attached Access bundle together. Organization-wide and workspace-level credentials or repositories flow into narrower scopes, while a private channel can add more access. Do not attach a high-classification data source to a broad channel simply because the Slack channel itself began as low sensitivity. ### Anthropic documentation * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [What are artifacts and how do I use them?](https://support.claude.com/en/articles/9487310-what-are-artifacts-and-how-do-i-use-them) * [Work across Microsoft 365 apps](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview On the OpenAI side the matrix maps to RBAC and app controls. RBAC custom roles assign apps, GPTs, projects, canvas networking, and skills to groups, with effective permissions taking the maximum across a user's roles — worth remembering when one broad role quietly widens a narrow one. Enterprise and Edu workspaces can assign specific apps to custom roles, so app access itself can follow data-class boundaries. Action control is the class-to-action lever: it determines whether a connected app can read only, take actions, or use a custom set of actions. Work can create documents, spreadsheets, presentations, reports, and Sites from files and connected sources. Classify every deliverable like its most sensitive input, and treat a published Site as an application release rather than an ordinary chat output. ### OpenAI documentation * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [Admin Controls, Security, and Compliance in apps](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-in-apps-enterprise-edu-and-business) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Creating and managing ChatGPT Sites](https://help.openai.com/en/articles/20001339) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about data classification for AI prompts and outputs ### What data classes matter for AI security? Most programs reuse their existing scheme — public, internal, confidential, regulated — and add AI-specific classes: secrets and credentials, source code, customer content, and privileged operational data such as incident tickets. The AI-specific classes matter because they move through prompts and tool calls in ways stored-data controls never see. Keep the list short enough that users can apply it while writing a prompt. ### What is a class-to-tool matrix? It is a decision table that maps each data class to the AI tools, account types, connectors, and actions allowed to receive it, plus the required controls. For example: source code may enter Claude Code or Codex under an enterprise account with secret files denied, but never a personal chatbot account. It turns "be careful with confidential data" into a rule someone can check. ### Should AI outputs be classified? Yes. Outputs inherit the classification of what went in: an answer summarizing a confidential document is confidential, and an artifact built from customer data carries customer data. Reclassify before outputs are shared, exported, or written into another system through a connector. ### How should users know what is allowed? Publish the matrix as short, tool-specific rules with examples — "customer records: allowed in the enterprise ChatGPT workspace, never in personal accounts" — rather than a long policy memo. Put the rule where the decision happens: onboarding, tool launch pages, and DLP warning messages. One good example per class beats a page of definitions. ### What is the biggest classification gap? Most teams classify stored data but not data in motion through AI: prompt inputs, retrieved context, tool parameters, and generated outputs. Output reclassification is the most common miss — artifacts and connector writes inherit the source data class, but nothing enforces the label downstream. Close the gap by giving outputs and artifacts their own rows in the matrix. ## Applicable regulations and frameworks | Governance page | Relationship to this article | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes. | | G.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports input-data relevance and governance. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports data protection, integrity, and third-party service review. | | G.4 Colorado AI Act and the US state patchwork | Conditional: for covered Colorado ADMT, this supports the personal-data inputs and outputs used in a consequential decision. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Data Protection guidance. | | G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy. | | G.7 Ownership and RACI for AI security | This control depends on the ownership and evidence responsibilities defined in the RACI. | | G.8 ISO/IEC 42001 AI management system | This article supports ISO/IEC 42001 AIMS preparation through data-governance and classification records. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA PHI identification, minimum-necessary handling, retention, and disclosure controls. | *G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.* ## Related handbook guidance * [4. Data Protection & Residency](/handbook/4.-data-protection-and-residency.md) * [4.1 DLP for GenAI](/handbook/4.-data-protection-and-residency/4.1-dlp-for-genai.md) * [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention.md) * [4.6 Cross-app data flow and live artifacts](/handbook/4.-data-protection-and-residency/4.6-cross-app-data-flow-and-live-artifacts.md) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/4.-data-protection-and-residency/4.2-data-classification-for-ai-prompts-and-outputs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.