AI Guardrails: What Leaves the Building and What Never Should

Friday, 11:50, at Tollgate Foods. Sam has a twenty-eight-reply ticket from the HR team about a payroll export that produces wrong figures for a handful of staff. He wants a summary before he hands it to the payroll vendor. He selects the whole thread and opens the general-purpose assistant he uses at home in a browser tab. He has the text on the clipboard when he glances at what he is about to paste. Reply four names the three employees whose pay was wrong and gives their employee numbers. Reply nine is from Beth, the payroll administrator: "I'll just put my login here so you can test it: beth.admin / Harvest!2go". Reply seventeen is an internal note from the security lead saying the export server is two patches behind and should not be exposed until it is fixed. Sam puts the clipboard down. None of that is the problem he wants summarized. All of it would have gone.

A guardrail, in this series, is a rule about what text may be given to an assistant, where that assistant runs, and who can see what was given. The reason the rules exist is simple and easy to forget at ten to twelve on a Friday. A ticket is data about a person, and a prompt is a copy of that data that has left your control. This article is part of our AI Assistants in Support series. It is about the line that text crosses when it goes to an assistant and what is allowed across it. It also covers the one-page policy that tells a tired technician the answer before they have to work it out.

It covers why a ticket is data about a person, then where an assistant runs and who sees the text. What never goes into a prompt and stripping a ticket before it crosses follow, with a worked example. Next is the difference between an assistant working inside your tool and a technician pasting into one outside it. Who decides and who is accountable come next, followed by what to do when something crosses that should not have. Keeping the policy current, a short war story, and the AI use policy to copy come last, in that order.

A Ticket Is Data About a Person

Tickets look like technical records and are mostly records about people. A request for a laptop names who is joining and when. A ticket about a sick-leave form says who is ill. A payroll ticket says who was paid wrongly and by how much. A ticket from a home worker contains their home address, in the shipping note. A ticket about a shared mailbox says who has fallen out with whom. A ticket about a disciplinary file's permissions says that a disciplinary file exists. The desk handles this all day and stops noticing it. That is exactly the frame of mind in which a thread gets pasted somewhere it should not go.

Tickets also contain things nobody should have typed into them. These include passwords, like the one Beth typed, because "I'll just put it here" is the fastest way to get a technician to test something. Tickets also contain licence keys, door codes, and the one-time codes a sign-in process sent to the requester while the technician was on the phone. And internal notes contain the desk's own secrets: which server is unpatched, which account has more rights than it should, what the security lead found last Tuesday and has not fixed yet. What should never have been written into a ticket in the first place is the subject of What Not to Write in a Ticket. That article is the first guardrail: text that was never recorded cannot be pasted. This article is the second: the text that is recorded anyway, and what happens to it.

The desk is a custodian of this data, not its owner. The requester told the desk about their pay, their illness or their password because they needed help, and on the understanding that the desk would use it for that. A copy sent to an assistant is a use they did not agree to and usually do not know about. Depending on where you are and what the data is, it may be a use the law has views on. That is the principle, and the rest of this article is its mechanics. A password typed into a ticket is a password that wants to travel. The guardrails are the things that stop it.

Where the Assistant Runs, and Who Sees the Text

Every assistant runs somewhere, and where it runs decides who can see the prompt. There are three cases. The assistant runs on servers your organisation controls, in the building or in a space you rent and administer. In that case, the text stays under your control, and the questions are about which of your own people can see it. The assistant runs as a service your organisation has a contract with, chosen by someone with the authority to sign it. In that case, the text goes to a third party. The contract says what they may do with it, how long they keep it, and whether they use it to improve their service. Or the assistant runs in an account a technician signed up to themselves, free or personal, with terms nobody at the organisation has read. In that case, the text goes to a third party under conditions nobody chose. The third case is the one that produces incidents, and it is the one Sam was a paste away from.

The questions to ask of any service are the same, and the answers differ by service and change over time. So ask them of yours rather than trusting what this or any other article says about services in general. Who at the provider can read what we send? Is it stored, and for how long? Is it used to improve the service, or shown to anyone else? Where, geographically, is it processed? Can we delete it, and can we prove we did? What does the contract say happens if they are breached? A provider that cannot answer these in writing has answered them. Every provider's privacy page is a reassuring document, and so is every other provider's; the contract is the one that counts.

Treat the line as real even when the assistant runs inside. The ticket text in a self-hosted help desk, QuerySolv's or any other, lives on a server you control, with the access rules you set. The moment a copy of it goes into a prompt, it has a second home, with whatever access rules apply there. Those are rarely the same. An assistant on your own server still writes logs. An internal service still has administrators who are not the desk. The guardrails are about the second home, wherever it is. The simplest way to think about them is that the prompt is a new document, and you are deciding who may read it. Where that document goes when the assistant is a chatbot answering requesters, and the four places it can live, is worked through in A Knowledge Base Chatbot Without a Vendor Cloud.

What Never Goes Into a Prompt

Some categories of text do not cross the line under any circumstances, for any task, in any assistant. The policy lists them so that nobody has to decide at 11:50. Credentials: passwords, passphrases, keys, tokens, one-time codes, door codes, recovery phrases, whether current or expired. (An expired password is still a pattern, and people reuse patterns.) Personal data beyond the problem: names, employee or customer numbers, addresses, dates of birth, contact details, and anything about a person's health, pay, performance, immigration status, religion, union membership, family or disputes. Security findings: unpatched systems, open vulnerabilities, incident details, network diagrams, internal hostnames and addresses, firewall rules, who has elevated rights. Confidential business data: customer records, contracts, prices, anything a non-disclosure agreement covers, anything marked confidential by its owner.

The test for anything not on the list is to ask what the assistant needs to do its job. The answer is almost always the symptom and the sequence, never the person or the building. To summarize Sam's payroll thread, the assistant needs to know that an export produces wrong figures for some staff. It needs to know which fields are wrong, what has been tried, and what the vendor has said. It does not need the three names, the employee numbers, Beth's password or the patch state of the server. None of those change the summary. All of them change who now holds a copy. The prompt should contain the symptom, the sequence, and nothing with a surname.

Do not paste the thread. Not "just the relevant part", because the relevant part of a long thread is never cleanly separable from the rest. Not "it is only internal hostnames", because internal hostnames are a map. Not "the password has been changed since", because you do not know that, and if you do, the pattern has not. Copy the problem out, in your own words or by careful selection, and paste that. It is slower by two minutes. The two minutes are the guardrail.

Stripping a Ticket Before It Crosses

Stripping is the two-minute job of turning a ticket into a prompt that contains the problem and nothing else. It has four moves. Replace people with roles: "Beth, payroll administrator" becomes "the payroll administrator". The three named employees become "three employees, all part-time, all paid monthly". Remove identifiers: employee numbers, ticket numbers from other systems, account names, serial numbers, unless the number itself is the problem. Remove the building: server names and addresses become "the export server". The patch note goes entirely. Remove credentials and, separately, deal with them, because a password in a ticket is a problem even if it never crosses. Tell the person to change it, and note on the ticket that you did.

Keep the symptom and the sequence intact, because that is what the assistant works on. "Export produces wrong gross pay for some part-time monthly staff since the pay-rate table was updated; totals correct for full-time staff; vendor asked on day six for a sample file; sample sent day seven; no reply by day twelve" is a complete prompt for a summary or a chase, and it names nobody. The table below is Sam's thread, element by element, with what crossed instead.

The stripped prompt was eleven lines. It produced a summary Sam could check against the ticket and send to the vendor. The prompt contained nothing the vendor, the assistant's provider or anyone reading a log would learn from. The ticket itself, with the names, the figures and Beth's note, stayed where it was, with its access controlled by the desk. That is the whole move: the problem travels, the people and the building do not.

Built In Versus Pasted In

There is a difference between an assistant that is part of your help desk tool and reads the ticket where it sits, and a technician copying a thread into an unrelated tool. The difference is who made the decision and when. An assistant built into the tool was switched on once, by someone with authority, under a contract someone read, with the questions above answered. What it can see is a configuration the organisation chose. A paste is a decision each technician makes alone, on each ticket, with no contract and no record. The policy below is mostly about the second, because the first is a procurement decision and the second is a Friday.

Switching on a built-in assistant is a change to how the organisation handles personal data. It belongs in whatever review your desk gives to changes that matter. The test for which changes deserve a look before they are made is in What Needs Review and What Does Not. And "a third party can now read every ticket" passes it comfortably. Ask the six questions, and get the answers in writing. Decide which departments' tickets it may see (HR and payroll are the usual exclusions), and record the decision with a name on it. Then it is a chosen risk, which is the only kind a desk should be carrying.

The output needs a guardrail too, in the other direction. A draft or summary that comes back may contain things that must not go on to the requester. Examples are an internal hostname the assistant was given, a colleague's name from the notes, and the fact that the server is unpatched. The reviewer's reading, in Drafting Replies With a Human Reviewer, catches these as part of checking names and facts. The public-versus-internal split in the knowledge base, in What Must Never Be in the User Doc, is the same rule applied to articles. Text that came in through the back of the desk does not leave through the front.

Who Decides, and Who Is Accountable

Three roles hold the guardrails, and the policy names them. The desk lead owns the policy, keeps it to one page, and answers the question "may I paste this?" when the page does not. The security lead or data owner, whoever your organisation has that is responsible for personal data and systems security, approves which services may be used at all. They also answer the six questions for each. And each technician is accountable for each prompt they send. In the plain sense, if it contained something from the never list, it was their paste. That last one is uncomfortable and it is the only arrangement that works, because the paste happens at a keyboard with one person at it.

Make the use visible on the ticket. When an assistant produced a draft or a summary, an internal note says so, with the technician's name. For example, it says: "summary drafted with the assistant from a stripped prompt; checked against the history by Sam." It costs a line and it means that six months later, when someone asks what was sent where, the history can answer. A desk whose tickets carry a complete event history has that answer in one place. A desk relying on memory has a conversation. Honesty about the tool's involvement also keeps the review honest, because a technician who writes "checked by" has, in my experience, usually checked.

Give technicians an exception route, so that the answer to "the policy says no but I think this case is fine" is a message to the desk lead rather than a quiet paste. Most exceptions, asked, turn out to be unnecessary once the problem is stripped. The few that are genuine get a decision from someone entitled to make it, recorded on the ticket. A policy with no exception route is a policy with a secret exception route, and the secret one has no record.

When Something Crosses That Should Not Have

It will happen, and the response is the same as for any other data incident, which is to say prompt and unglamorous. The technician tells the desk lead and the security lead the same day, in writing, with what was sent, where, and when. Any credential that crossed is changed immediately, whether or not it was still valid. The provider is asked, in writing, to delete the content, and the request and reply are kept. Whoever owns the personal data involved is told, and decides, with whatever regulatory advice your organisation has, whether the people concerned must be informed. The ticket records all of it in an internal note.

The thing not to do is nothing. A paste that is reported the same day is a mistake with a known shape and a known fix. A paste that is discovered three months later, from a log or a complaint, is an incident with an unknown shape and a cover-up attached. It comes with a technician who will not be believed about what else they did not mention. Make reporting easy and consequence-free for the first offence. That is because the organisation's interest is in knowing, and a technician who fears the report will not make it. The guardrail against the unreported paste is a desk lead who has said, out loud, that they would rather hear about it.

Keeping the Policy Current Without Rewriting It Yearly

The policy stays current if it is written about categories of text rather than about tools. "No credentials, no personal data beyond the problem, no security findings, no confidential business data" is as true of the next service as of this one, and of a service that does not exist yet. Name the approved services in an appendix that the security lead maintains, not in the policy body, so that adding or removing one is a line change. Review the page whenever a new service is approved, whenever an incident happens, and once a year regardless. On most desks, that means it is read twice a year. That is twice more than most policies.

Keep it to one page, because the technician reading it is the one with the clipboard full and the tab open. Eleven pages is a document that explains everything to someone with an afternoon. One page is a document that answers "may I paste this?" in the time it takes to glance at it. The glance is the only moment the policy will ever be consulted.

A Short War Story: The Pasted Thread at Thornbury Accountants

At Thornbury Accountants, a junior technician called Ravi wanted a quick summary of a thirty-reply ticket about a client's tax return software. He pasted the entire thread into a free assistant in his own browser account. He had used it at college and trusted it. The thread contained the client's name and tax reference, and two partners' discussion of the client's late payment. It also contained the address and name of the firm's remote-access server, and a temporary password a partner had typed into the ticket a fortnight earlier for the technician to test the client's access. The password had never been changed. The summary was excellent and took four seconds. The firm's data protection review, which took a partner most of the following week, described the paste as "an outbound transfer of client data and access credentials to an unapproved third party". The firm changed the remote-access credentials that afternoon, wrote to the client, and spent two days establishing from the provider's terms whether the content had been retained. The terms did not make that clear. Nothing was hacked and no one outside the firm did anything wrong. The desk had mailed its own keys out of the building to save a quarter of an hour. Thornbury wrote the one-page policy the following Monday. Its first line was the one Ravi said he wished he had read: the prompt is a copy of the ticket that has left your control.

The AI Use Policy

The policy is one page, written for the technician with a thread on the clipboard. It is read at the moment of pasting, not in an induction. The first block is the never list, which is deliberately short and absolute. The second is the stripping rule. The third names who decides and what to do when something goes wrong. The approved services live in the appendix line at the bottom, maintained by the security lead, so that the page itself does not change when a service does. Fill in the names, print it, and put it where the clipboard is.

AI USE POLICY — THE HELP DESK — ONE PAGE
Owner: ______________ (desk lead)   Approver: ______________ (security / data owner)
Last reviewed: ________   Next review: ________

1. THE RULE
   A prompt is a copy of the ticket that has left our control.
   Only the problem crosses. The person and the building do not.

2. NEVER GOES INTO A PROMPT, FOR ANY TASK, IN ANY SERVICE
   [ ] Credentials: passwords, keys, tokens, one-time codes, door codes, current or expired
   [ ] Personal data beyond the problem: names, employee or customer numbers, addresses,
       contact details, dates of birth, health, pay, performance, HR or legal matters
   [ ] Security findings: unpatched systems, vulnerabilities, incidents, network diagrams,
       internal hostnames and addresses, firewall rules, who holds elevated rights
   [ ] Confidential business data: customer records, contracts, prices, anything marked
       confidential or covered by an agreement
   [ ] Anything from the departments listed as excluded: ______________________________

3. BEFORE ANYTHING CROSSES
   [ ] People replaced with roles        [ ] Identifiers and numbers removed
   [ ] Servers and addresses generalised [ ] Credentials removed AND the owner told to change them
   [ ] Symptom and sequence kept, with dates
   [ ] Only an approved service used (see appendix)
   [ ] Internal note on the ticket: what was drafted with the assistant, and who checked it

4. THE OUTPUT
   [ ] Reviewed by the sender before it reaches a requester
   [ ] Contains no internal name, hostname, colleague's name or security detail

5. WHO DECIDES
   Unsure whether something may cross:   ask ______________ before pasting, not after
   New service wanted:                   ______________ approves, with the six questions answered in writing
   Exceptions:                           ______________ decides; recorded on the ticket

6. IF SOMETHING CROSSED THAT SHOULD NOT HAVE
   Same day, in writing, to ______________ and ______________: what, where, when
   [ ] Credentials changed   [ ] Deletion requested from the provider, in writing
   [ ] Data owner informed   [ ] Internal note on the ticket
   First report of an honest mistake carries no penalty. An unreported one does.

APPENDIX (maintained by the approver): approved services and what each may see
   ______________________   may see: ______________________   approved: ________
   ______________________   may see: ______________________   approved: ________

Sam wrote the eleven-line prompt, got his summary, checked it against the ticket, and sent the vendor a chase that named no one and gave away nothing. Then he replied to Beth's reply nine, on the ticket, asking her to change the password she had typed and noting that he had asked. He added an internal note saying what he had used the assistant for. It took eight minutes more than the paste would have. At Thornbury, the paste took four seconds and the week that followed took a week. The guardrails are not there to slow the desk down. They are there so that the only thing that leaves the building is the problem.

Frequently Asked Questions