AI Guardrails for Analysts: What Never Goes Into a Prompt

Five data classes never enter a general assistant: identified customer data, credentials, unreleased commercial terms, personal data about colleagues, and production extracts. Govern tools by blast radius in four tiers, from read-nothing to write-to-production. Mask by preserving shape, not by blanking values. And keep the prompt, the source, and your verification note for anything that becomes a delivery artifact.

This is the part of The AI Analyst that is not fun, and it is the part that decides whether the rest of the series is a career accelerant or an incident report with your name on it. Parts one and two were about getting useful output. Part three is about the four ways analysts get this wrong, all of which I have watched happen: pasting a production extract into a consumer chat window, accepting a fabricated control requirement into a specification, giving an assistant credentials that could write to a live system, and being unable to answer “where did this requirement come from” six months later.

None of those are exotic. All of them are preventable with rules you can write down in an afternoon.

What are the four tiers of AI tool access?

Stop classifying tools by vendor. Classify them by what they can reach, because that is what determines the damage when something goes wrong. Four tiers:

Tier	What it can reach	Example	Controls you need
0	Nothing of yours	Asking a public assistant how ISO 20022 mandatory fields work	None beyond not pasting anything
1	Documents you give it	A context pack in project knowledge	Data classification, masking, approved tenant
2	Live systems, read only	An MCP connection to Jira, a query tool over a test database	Least privilege scoping, non-production first, tool-call logging
3	Live systems, write	An agent that creates Jira tickets or updates Confluence	Per-action human approval, dedicated service account, rollback path

The jump that matters is 1 to 2. At tier 1 the worst case is a wrong document, which your review catches. At tier 2 the model is reading real system state, so the worst case becomes a wrong statement about production that someone acts on. At tier 3 the worst case is an action in a system of record that nobody intended.

Most analyst teams should live at tier 1 for a quarter, tier 2 for the next, and approach tier 3 deliberately with the guardrails in part six rather than because a plugin made it easy. The decision rule for when a tool-using agent is even the right shape is in AI agents for analysts.

What data never goes into a prompt?

Five classes. Learn them as a list, because in the moment you will not reason it out.

1. Identified customer data. Names, account numbers, IBANs, card numbers, email addresses, phone numbers, and any transaction reference that can be resolved back to a person through a system you have access to. That last clause catches people: a payment reference looks anonymous and is a direct key into a customer record.

2. Credentials. API keys, personal access tokens, passwords, connection strings, certificates, session cookies, anything from a .env file. This includes pasting a curl command you copied from a browser, which carries an authorization header you forgot about. It also includes screenshots, which carry whatever was on screen. API keys and tokens for analysts covers what each credential type actually grants, which is the knowledge that makes you careful about the right ones.

3. Unreleased commercial material. Pricing not yet public, contract drafts, supplier terms, anything under a non-disclosure agreement, anything related to a transaction the market does not know about. The compliance consequences here are not about data protection law, they are about market abuse rules, and they are severe.

4. Personal data about colleagues. Performance notes, disciplinary matters, salary information, health information, the reason someone is off. Analysts touch this more than they expect, usually while trying to be helpful about resourcing.

5. Production extracts. Any of them, including ones you believe are anonymous. Re-identification from a handful of quasi-identifiers (postcode, date of birth, transaction amount and date) is routine, not theoretical. If it came out of production, it is production data until somebody with the authority to say otherwise has masked it.

Two habits carry most of the weight. First, before you paste, read the first and last five lines of what is on your clipboard. Second, never paste a screenshot you have not looked at properly, because the notification that popped up in the corner is now in the prompt.

How do you mask data so it stays useful?

Blanking a value destroys the thing that makes the exercise worth doing. If you replace an IBAN with XXXXXXXX, the model no longer recognises the field as an IBAN, cannot reason about the country code or the check digits, and will happily tell you your validation rule is fine when it is not.

Mask by preserving shape and destroying linkage:

Field type	Bad masking	Good masking
IBAN	XXXX	A structurally valid fake IBAN with correct country and check digits
Customer name	[REDACTED]	A consistent pseudonym, the same fake name every time that customer appears
Account number	123456	A synthetic number of the same length and format
Date of birth	Removed	Shifted by a constant offset, so age bands and ordering survive
Transaction reference	REF1	A synthetic reference matching your real format rules
Amount	Rounded to nothing	Kept, or jittered by a small percentage if the amount is identifying

Consistency is the subtle requirement. If the same customer appears as Alice Fake in every record, the relationships in the data survive and the model can still reason about “the same debtor sent three payments.” If you randomise per row, you have destroyed the thing you were investigating.

Script it. A twenty-line Python script that applies the same mapping every time is repeatable, reviewable, and faster than doing it by hand on the fourth extract. Scripting checks in Python has the shape of it, and the same script becomes your test data generator, which is a second payoff for the same work.

Better still, avoid the problem: generate synthetic data from the schema rather than masking production. A model given your data dictionary and your business rules will produce perfectly good test payloads that were never anyone’s real payment. That is the approach part nine uses for the whole test data set.

How do you stop fabricated facts reaching a real document?

Masking protects the input. This protects the output, and it is where more analysts actually get hurt, because the failure is quiet.

The rule: anything you cannot trace to a source is unverified, and unverified statements do not enter a specification, a ticket, a defect, or an incident channel.

Three mechanics make that enforceable rather than aspirational:

Force a provenance column. When you ask for a structured artifact, require a source for every row. A test case table gets a column citing the business rule number or the contract clause. A requirements draft cites the transcript line. Rows with no source go in a separate UNGROUNDED list. You are not asking the model to be honest; you are making dishonesty structurally visible.

Ask for the contradiction, not the summary. “Does this specification conflict with the attached contract, and where” produces checkable output. “Summarise this specification” produces something you have to read entirely to trust, which is the time you were trying to save.

Spot-check at a fixed rate. Pick three claims per artifact at random and verify them against the system. If all three hold across several artifacts, your flow is sound. If one fails, the whole artifact goes back. This is sampling, it is what auditors do, and it costs about five minutes.

The reason this matters more in analyst work than in most jobs is that our output is instructions to other people. A fabricated status code in a chat window is a curiosity. The same string in a functional specification becomes a build, a test case, and eventually a production defect, and by then four people have implemented it faithfully. Why acceptance criteria failed on an AI project is the longer version of that lesson from the other side.

What does least privilege look like at tier 2?

When you connect a model to a real system, scope it like you would scope a service account for an intern who is very fast and occasionally confused.

• Read only, always, first. There is no analyst task at tier 2 that needs write access. Investigation is reading.
• Non-production if the answer exists there. A schema question, a contract question, and most flow questions can be answered in a test environment. Reserve production access for questions only production can answer.
• Scope to the project, not the instance. A Jira connection scoped to one project key. A database user granted SELECT on eight named tables, not on the schema. A file connection pointed at one folder.
• A dedicated account. Not your personal credentials. When something appears in an audit log you want it attributable to svc-ai-analyst, not to you personally, and you want to be able to revoke it without changing your own password.
• Log every tool call. Most clients can show you the calls. Keep them for anything that informed a delivery decision.
• A kill switch you have tested. Know how to revoke the token in under a minute, and have done it once so you know the procedure works.

The concrete version of this, with the Atlassian connection, the scoping, and what to check in the audit log, is part five.

What do you keep for the audit?

Not everything. For anything that becomes a delivery artifact, keep three items:

1. The source material you grounded on, or a reference to it if it lives in the repository.
2. The prompt, including the constraints, because that is the evidence of the method.
3. A one-line verification note: what you checked, against what, and when.

Store it next to the artifact. A Confluence page with a collapsed “how this was produced” section, or a file in the repository beside the specification. It takes thirty seconds.

When an auditor asks how a control requirement was derived, “the AI wrote it” is a finding. “Here is the source contract clause, the prompt, and my note confirming I checked the field against the schema on 14 September” ends the conversation. I have been on both sides of that exchange and the difference is entirely in whether the three items exist.

Nothing here is specific to AI, incidentally. It is the same provenance discipline that makes a requirements traceability matrix useful. AI just increases the volume of artifacts, which increases the cost of not having it.

A one-page rules of engagement you can adopt

Write this into your team’s working agreement. Adapt the tool names, keep the structure.

1. Only tools on the approved list. If it is not on the list, it is tier 0 and gets nothing.
2. The five never-paste classes apply everywhere, including the approved tenant.
3. Mask by shape, using the shared script. Prefer synthetic data generated from the schema.
4. Tier 2 connections are read-only, scoped to named projects or tables, on a dedicated service account, with logging on.
5. Tier 3 write actions require a human approving each action, and the action must be reversible.
6. Every generated artifact carries a provenance column or an UNGROUNDED section.
7. A named human reviews and owns every artifact that leaves the team. The tool is never the author.
8. Keep source, prompt, and verification note for anything auditable.
9. Spot-check three claims per artifact.
10. Refresh the context pack every release, or the guardrails protect a stale picture.

Ten lines. It has never taken me more than an hour to get a delivery lead to agree to a version of this, because none of it is an AI policy, it is the data handling and provenance policy they already have, applied to a new channel.

The takeaway

AI guardrails for analysts come down to four moves. Classify tools by blast radius and stay at read-only for longer than feels necessary. Keep the five data classes out of every prompt and mask by preserving shape. Make ungrounded claims structurally visible so they cannot slide into a document. Keep the source, the prompt, and the verification note for anything auditable.

Do that and you can connect a model to your codebase, your ticket system, your wiki, and your test estate without ever having the conversation that starts “so how did this get into production.”

Next: part four, where the model starts reading the repository, which is the first place these rules get tested. The full path is on The AI Analyst.

If you are specifying or testing AI features rather than just using them, the delivery-side reference is AI at Work: MCP, RAG, and AI Agents, and the acceptance criteria problem is covered at Acceptance Criteria for AI Systems.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Artificial Intelligence, Governance, Data Protection, Banking