Data privacy and security with AI tools
Whatever you type into an AI tool may leave your control. Mainframe teams handle some of the most sensitive data a company has, so the core rules are simple: approved tools only, no production data, no secrets, and the same access rules as everywhere else.
Why this matters more on the mainframe
Mainframes hold account balances, card data, medical claims and tax records. Much of it is covered by data-protection law, industry standards such as PCI DSS for card data, and contracts with customers. A prompt is just another way data can leave the building. Pasting one production record into the wrong tool can be a reportable data breach.
Where your prompt goes
Depending on the tool and the contract, prompts may be logged, kept for a period, reviewed by the provider, or in some consumer services used to improve future models. Enterprise agreements usually restrict this, which is one reason organisations maintain a list of approved AI tools. You cannot tell from the chat window which terms apply; the approval process exists so you do not have to.
The core rules
| Rule | What it means in practice |
|---|---|
| Approved tools only | Use the assistants your organisation has approved for the data class you are working with, through the approved route (for example the company IDE plugin, not a personal account) |
| No production data | No real customer names, account numbers, balances, card numbers or extracts in prompts, even 'just one record' |
| No secrets | No passwords, password phrases, API keys, certificates, connection strings with credentials or RACF details |
| Minimum necessary | Share only the code needed for the question; strip internal hostnames, IP addresses and comments naming customers |
| Same access rules | If you could not email it to a third party, do not paste it into an unapproved tool |
Hidden data in 'harmless' material
Sensitive data turns up in places people forget to check:
- Job logs and SYSOUT: a SYSOUT dump or DISPLAY output can contain real account data.
- Abend dumps: storage dumps include whatever records were in memory at the time.
- Test libraries: test datasets are sometimes copies of production that were never masked.
- Comments and literals: hard-coded customer IDs, internal URLs and userids in source.
- Screenshots: a 3270 screen capture may show live customer details.
Before: DISPLAY output: ACCOUNT 4929123456781234 BAL 00012734.55 After: ACCOUNT [REDACTED-16] BAL [AMOUNT] Before: USERID PRDBAT1 PASSWORD XXXXXXXX in SYSIN After: USERID [ID] -- remove credential lines entirely
Even sanitised, ask whether the question needs the data at all. Often the message ID, return code and a description of the record layout are enough.
Security risks from the tools themselves
- Suggested code may be insecure: hard-coded credentials, missing input validation, or overly broad access in generated JCL or scripts.
- Prompt injection: text inside a document or code comment can try to steer an assistant that reads it, especially one that can take actions. Treat assistant output that came from untrusted material with extra care.
- Over-privileged integrations: an assistant connected to systems should use a functional userid with least privilege, never a person's high-authority ID.
Is it acceptable to paste one masked-looking production record into an unapproved chatbot if you remove the name? Answer yes or no.
Show a hint
Think about the tool, not just the data.
Show the solution
No. The tool is not approved, and partial removal often leaves identifying data such as account numbers.
Common mistakes
Personal accounts are not covered by company agreements on retention and use. Use the approved route even if it is less convenient.
Logs and dumps can contain real customer data and credentials. Extract only the messages you need and sanitise them.
Test libraries are sometimes unmasked copies of production. Check how the data was created before sharing it anywhere.
What you will see at work
- Most organisations publish an approved-tools list with the data classes each tool may be used for.
- Security teams may monitor or block unapproved AI services on company networks.
- Incident reports increasingly ask whether any data was shared with an AI tool.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.