Record the data path alongside the tool
At a fictional company, marketing edits published announcements, support wants to classify customer inquiries, and developers use an editor assistant to work on private code. All three use AI, but each sends different data and leaves different permissions for the company to revoke.
Shadow AI commonly means work use of tools, accounts, or integrations that the company has neither approved nor brought under management. Inventory chat, browser extensions, editor plug-ins, meeting bots, document connectors, API accounts, and AI features added to existing SaaS. A meeting bot can collect speech without someone pasting it. An editor plug-in may request access beyond the lines at the cursor. An installation list can miss a newly enabled feature in a tool IT already manages.
Ask teams about recent tasks and types of data. Avoid asking for original text in the inventory form, which creates another copy. Review permission grants and installation records for company accounts. Before removing a tool, identify who will keep its work going. If a former employee owns a project or workflow, transfer its records and approvals to a current owner. NIST’s Generative Artificial Intelligence Profile[1]
Which combinations take priority?
Start with broad data exposure or access that is hard to revoke. A connection from a personal account to an entire support folder comes ahead of an occasional edit to a public announcement. Restrict new use of an organization-wide extension if its effective scope remains unknown.
A personal API key that runs a production batch may present a continuity risk even at low volume. Frequent use of published data in an approved workspace may instead call for a check of input and output review. Consider data category, volume, ongoing access, reversibility, and when the work ends.
Define permitted use from the data and purpose
This illustrative matrix connects data classes to jobs. Verify the applicable provider terms, customer contracts, and internal policies. Even for a public webpage, confirm that the responsible owner published the exact version. Exporting the whole working folder might include internal notes or identifying data.
| Data | Example task | Permission condition | Owner’s check and evidence |
|---|---|---|---|
| Published product copy and announcements | Draft translation or editing | Use registered tools and accounts with published material only | Link to the published original and review the edited output |
| Internal announcements and unpublished schedules | Organize or reformat text | Revocable organization workspace with verified retention | Confirm classification and default sharing |
| Support records and attachments | Classify inquiries or draft replies | Minimize identifiers and order information, and approve the data path | Check approved fields, input samples, and retention and deletion ownership |
| Private code and technical designs | Explain code or propose changes | Approved repositories and paths only, with secrets excluded | Confirm the repository allowlist, extension scopes, and revocation |
| Passwords, API keys, signing keys, and high-risk originals | Exceptional security diagnosis | Restrict raw input and review any isolated exception | Have the security and key owners name the environment and test data |
The fictional support team removed customer names but left order numbers and order links. Access to the internal order system could still reconnect these records to people. Inspect masked fields and prefer substituted test values where possible. If a reply really needs order status, authorize that path separately and restrict which orders and attributes can be queried.
Marketing can paste published text only. Developers can use approved internal search or code review pending a decision. Recheck meeting-assistant approval when participants, attachments, or recording retention change. Tell staff which alternatives are available and when to expect an answer to an approval request.
Connect the data each campaign needs — Define events and attributes from campaign needs, then align identifiers, transmission timing and measurement tools.
Five things to verify with the provider
Check processing purpose and retention separately
Ask about the use of prompts, responses, files, and logs for improvement or training. Separately check where and why each is stored and for how long. For example, the OpenAI API documentation distinguishes default training use from abuse-monitoring logs and application state. Check the actual plan, feature, contract, and organization settings. A rule for the API cannot establish conditions for other providers or consumer services. OpenAI API data controls[2]
Map locations and subprocessors
Check where data is stored, where it is processed, and where support can access it. A connector may create its own index or summary, and an external tool can receive results. Review those pathways and subprocessors as well as the original chat provider. Confirm which features and data flows a region setting covers. Hold unresolved paths out of scope while reviewing permitted operations.
Use accounts administrators can revoke
A company email address can still belong to a personal workspace. Verify seat removal and ownership transfer. In a test account, check administrator access, company authentication, deactivation, audit events, and shared-link expiry. Deactivation, connector-grant removal, and API credential revocation may require different actions. Migrate production jobs and verify their operation when replacing personal credentials.
Inspect read and write scopes independently
Permission to upload a kind of document does not authorize a connector that can read an entire folder. Check allowed folders, search audiences, downloads, and resharing. If a tool can send messages or write to another system, test enforcement of approval and scope. Check documentation and test what happens to existing indexes and conversations after disconnecting. OWASP’s agentic application security guide[3]
Record remaining copies and responsibilities when use ends
Check export, deletion requests, completion evidence, backup and log exceptions, and retained corporate records. An account removal can leave links, browser extensions, email, and attachments. Record who verifies each location after termination. Have the responsible company teams assess applicable terms and legal obligations for the actual use.
AI tool registration card
Have the requesting team start with purpose and data. Use internal classification labels and documentation links in place of credentials or support transcripts. Data, security, and IT owners can record what is needed for rollout, transfer, and termination.
| Field | Example entry | When to review again |
|---|---|---|
| Tool, feature, and owner | Support inquiry classification, support operations lead | Workspace owner, plan, or feature changes |
| Purpose and eligible input | Review sanitized inquiries against the supplied taxonomy | Original transcripts, new databases, or attachments |
| Account and permissions | Company workspace, assigned group, controlled editing and export | Personal account, external seats, or administrator departure |
| Connections and handling | Evidence links, confirmation date, and subprocessors for each location | Provider policy, region, retention, or integration changes |
| Testing and operations | Sample submission, post-disconnect access test, and review date | Missing reproducible evidence or failed restriction |
| Approval and retirement | Business and data approvers and owners for seat, link, and token revocation | Expiry, cancellation, or staff departure |
With the card, a team lead can approve editing without implicitly approving outbound delivery or organization-wide search. Use approved sample data and test accounts. Decide on live customer data only once the conditions are verified. Give employees an owner and response timeline for approvals so they have a practical alternative to a workaround.
When unapproved use is discovered
Establish the data, connected systems, sharing scope, and whether access remains active. If a credential was supplied, have the issuer revoke or rotate it and request removal through the provider. If internal material was disclosed, preserve evidence needed by responders and connect the data owner to the provider’s support. See NIST incident response recommendations[4] and IXC’s response guide for exposed credentials.
Check whether an offboarded user can authenticate, use an existing session or token, and whether their replacement can access company-owned records. For session and audit design see IXC’s comparison of administrator access methods. In follow-up, review requests that bypassed a slow approval, connections that persisted, and changes to approved conditions.
