How to stop unauthorised AI usage at work

The first sign of shadow AI can be an expense claim.

A customer-support lead has been paying for an AI subscription to help with the weekly report. Every Friday, they export the week’s tickets, upload the file and ask for the main complaints, recurring faults and customers who need a follow-up.

The report is useful. Their manager wants the rest of the team to use the same process. Someone asks whether the company can cover the subscription.

That is how the request reaches IT.

You ask what goes into the upload. The export includes customer names, contact details and the full conversation history. Some tickets contain attachments. The account belongs to the employee. Its settings and terms have never been through the company’s review process.

Now you have two jobs: deal with the data already sent, and give the team a workable way to produce next Friday’s report.

To stop unauthorised AI usage at work, find the tools and accounts your team uses, give people an approved alternative, set clear rules for data and actions, and test that your controls enforce those rules on the relevant routes. Assign an owner to exceptions and give each exception an expiry. Repeat verification when tools, accounts or controls change.

Here is how to work through those decisions, with a checklist you can use at the end.

Define what is unauthorised

The expense claim tells you someone bought access. It says nothing about whether the account was approved to receive customer records.

Moving the subscription to a company card would settle the payment question. You still need to review the tool and its data use. Even if your organisation already approves that AI product for drafting public copy, uploading a customer-support export is a separate decision.

Define approval across five things: tool, account, purpose, data and action.

• Unapproved tool: an employee uses a public chatbot that has no business owner or supplier review. This is a shadow AI discovery and approval problem.
• Prohibited use of an approved tool: an employee uploads restricted customer material to an approved work account whose permitted use covers public information. The tool is approved; that disclosure is outside policy.
• Unapproved account or feature: an employee switches to a personal account, connects an unreviewed plugin or enables an AI feature inside existing software. Review that specific route.

Managing unauthorised AI usage means deciding which tools people can use and what they can do with them. Use Promptective’s shadow AI management overview to evaluate discovery, policy enforcement and decision evidence, or the Australian workplace AI policy guide to write the governance document.

1. Discover use and assign owners

Start with the support lead’s process. Which account receives the files? How long has this been happening? Have other people started doing it? Does the upload contain ticket text, attachments or both?

Pause further uploads while Security and the data owner assess the previous disclosures through the incident process. Establish the account, dates and data classes without copying customer records into another ticket. Check provider access, retention and deletion options, and involve Privacy or Legal in any notification decision. Deleting a chat alone does not establish that every copy has been removed.

The support lead owns the reporting task; IT owns the account and control review. That gives both the incident and the unfinished weekly report somewhere to go.

For your own inventory, combine staff reports with procurement and single sign-on (SSO) records, approved browser and endpoint signals, network metadata and expense records. Include embedded AI, coding assistants, direct APIs, agents and local models.

Explain to employees what you collect, why you collect it and how long you keep it. Involve Privacy and People teams before workforce monitoring.

For each workflow, record the application and feature, account or workspace, business purpose, users, data classes, connected actions, owner, approval state and review date. Keep the discovery source and confidence separate from enforcement status. A domain visit gives you something to investigate. You still need to verify whether a control checked or stopped the interaction.

Prioritise unknown tools handling restricted information or actions with external effects. Restrict a confirmed high-risk route through a tested control while its owner reviews a safe alternative. Keep an incident route available for accidental disclosures, with no sensitive content copied into tickets.

Done when: each priority workflow has a named owner and an explicit approved, prohibited or pending decision.

2. Make the approved path usable

Friday’s report still needs to happen. Ask the support lead which part takes the time: counting issue categories, reading long conversations or writing the summary. Those are different tasks, and they may need different access to customer information.

The helpdesk’s own reporting may supply the counts. A person can handle named customer follow-ups inside the helpdesk. For the written summary, assess whether an approved AI workspace can work from a reviewed, minimised set of themes. Keep raw ticket exports out until that exact use has been assessed and approved.

Try the replacement process with the support lead. If it misses what made the report useful, fix that gap before asking the whole team to adopt it.

Put the agreed process on a short tool card: exact product, workspace, allowed purpose, permitted data, enabled features and support contact. The next person preparing the report should be able to follow it.

Provide organisation-managed accounts for common tasks. Review supplier access, retention, model-training terms, deletion and connected services for each approved combination.

Use examples from employees’ work when you train them. Show the expected account badge, an allowed task, a blocked task and where to request a missing capability. Ask Procurement and IT to set a review turnaround, so employees know what to do while they wait.

Done when: an employee can complete the common approved task and identify where to request an alternative.

3. Write data and action rules

Removing the name column from an export is a tempting shortcut. Read a few ticket bodies and the problem becomes clearer: names and contact details can appear in replies, signatures and attachments too. A complaint can identify a customer through its context.

Have Security and the data owner define what the summary genuinely needs, how that input is prepared and who checks it. Record the permitted data classes and the required controls. Keep customer-level follow-up inside the reviewed customer system unless a separate AI workflow is approved for it.

Map your own information classifications to specific uses. Your rules need to reflect your data, obligations and risk. Removing obvious identifiers alone does not establish that an export is safe to share.

Ask what the AI can do as well as what someone can type into it. Reading a repository, connecting an inbox, uploading a file or allowing an agent to change a system can each need a separate decision. Minimise permissions and input data before selecting a detector or enforcement product.

The sensitive-data leakage guide covers ChatGPT and Copilot account differences, data classes and delivery tests in detail. This guide provides operational guidance. Privacy or Legal should validate applicable duties.

Done when: each priority use has a rule, an accountable approver and an expected control outcome.

4. Match technical controls to the route

The team has an approved reporting process. Next Friday, someone may still reach for the familiar export-and-upload shortcut. What would stop that file leaving?

If the unapproved service uses a separate destination, domain blocking can close it on an enforced route. If personal and work accounts share a domain, you need controls that can distinguish those accounts. The approved workspace’s uploads also need their own policy check. Any AI summarisation built into the helpdesk needs a separate coverage decision.

Follow each route from the device to the AI service. Where can you check content or stop an action? Use the comparison below to choose controls for those points. It describes control categories; availability and coverage depend on the actual deployment.

Begin with controlled tests, then pilot with representative teams. Audit-only mode lets you review findings and see where approved work runs into problems. It still allows delivery. Introduce enforcement where you have verified the rule, coverage and business alternative. Keep urgent, confirmed high-risk cases under tested restrictions.

Done when: every claimed protected route has a tested decision point, and each remaining gap has an owner and treatment.

5. Make exceptions narrow and temporary

Once the weekly summary is working, the support lead asks about analysing a longer run of tickets to investigate a recurring fault. That could need more context than the approved summary input contains.

Review that request against a defined purpose, date range, data set and account. If the relevant owners approve it after assessing the data handling and controls, give the permission a defined scope and an expiry. Until then, the team follows its existing approved process. A request alone grants no permission.

Record the requester, business reason, exact tool and account, purpose, data class, permitted action, compensating controls, approver and expiry. Use an approval channel with access controls and avoid including the source material in the request.

Before approving, check whether an existing sanctioned tool can complete the task. After approval, test both the permitted case and a case outside its scope. Check what happens when the exception expires: the permission should end. Document how the employee returns to the normal approved route.

Done when: an expired exception cannot silently remain an approved route, and an owner can revoke an active exception.

6. Verify decisions and delivery

Before you describe the reporting workflow as protected, recreate the choices in an authorised test environment. Prepare a safe summary input and a synthetic ticket export representing the prohibited data class, including identifiers inside free text. Keep real customer tickets out of the exercise.

Write the expected results first: the approved summary task should succeed, and the prohibited upload should be stopped on the route you claim to protect. Then test the relevant exception and failure cases. A working account and an installed control are only the starting conditions.

Use deliberately authored synthetic content and fictional identities, with no real secrets or customer material. Exercise each supported route in a controlled environment authorised for the test.

These illustrative test cases describe expected outcomes for your test plan. Run them against the specific controls you intend to rely on:

• Allow: a public-information task in an approved workspace succeeds. Check the decision and intended delivery, including duplicate-send behaviour.
• Block: synthetic content representing a prohibited class is stopped on a supported route. Confirm no prohibited payload reaches the controlled destination.
• Sanitise: where supported and chosen by policy, only the safe transformed content arrives. Check that the prohibited value is absent and the remaining task is usable.
• Exception: an in-scope request succeeds during its approved period; an out-of-scope or expired request follows the normal restriction.
• Failure or uncovered route: disable the test control, simulate stale policy or select unsupported content. Compare the outcome with the documented failure policy and mark any gap for treatment.

Keep a bounded evidence record so a reviewer can check the result: application and route, policy version, expected and actual decision, reason category, delivery outcome, test time and reviewer.

Verify delivery with a controlled receiver or network check. A screenshot shows the visible response. The delivery check tells you whether the payload crossed the boundary. Keep routine evidence free of prompt and response text.

Done when: approved work succeeds, prohibited cases meet the stated restriction, failure behaviour is understood and unresolved routes are reported honestly. Retest after material changes to applications, provider features, account settings or policy.

Implementation checklist for IT providers and security consultants

Copy this checklist into your client’s change record so each task has an owner and a clear handover. Agree scope and testing authority before collecting signals or changing controls. Record an owner, due date and evidence reference against each item.

1. Confirm the sponsor, business workflow, managed devices and accounts in scope.
2. Document authorised discovery sources, employee notice, access and retention.
3. Complete the priority AI register and obtain owner approval decisions.
4. Publish the approved-tool card, data rules and employee support route.
5. Map each browser, desktop, API and agent route to its control and known gaps.
6. Write expected allow, block, sanitisation, exception and failure cases where applicable.
7. Run the authorised synthetic tests and record decisions plus delivery results.
8. Rehearse exception expiry, revocation and a safe rollback with the client owner.
9. Hand over the coverage record, unresolved risks and incident contacts without prompt plaintext.
10. Assign ongoing review ownership and change-triggered retesting.

Suggested handover fields: workflow; owner; account; data class; control; coverage boundary; policy version; expected decision; actual decision; delivery result; evidence reference; unresolved risk; next review.

Where Promptective fits

Go back to the expense claim. Before approving the subscription, you need an answer to what the team will send next Friday, which account will receive it and how the controls will be checked. The response to earlier disclosures also needs an owner and follow-through.

The support lead needs to finish the report. Your job is to make the permitted way of doing that clear, usable and verifiable, then review it when the account, data or task changes.

Promptective helps Security, IT and Compliance discover recognised and suspected AI activity and apply organisation policy on supported interactions. Its decisions can audit, block, redact or require approval, with content-minimised evidence. Match coverage to the application, provider, connection, device and integration used by your team.

Explore Shadow AI monitoring and management to evaluate the workflow. Start with one approved task and one prohibited use from your team’s work, described without sensitive content. Bring those examples to a demo to discuss the decision you need, the route it covers and the evidence you should expect.

See Promptective in action.