James Whitfield, a permit reviewer at a county planning department, had a deadline and a clever idea. He pasted three pages of a resident's permit application, including the applicant's home address, phone number, and a scanned ID, into a free public chatbot and asked it to summarize the zoning history. The summary was great. It saved him twenty minutes. It also sent a citizen's personal information to a company's servers outside the county's control, where it could be stored, reviewed by staff, and used to train future models. James had not broken a rule he knew about. He had never been shown which tools were approved, what they were approved for, or where the lines were. Nobody had walked him through it. This lesson is that walkthrough.

The goal is simple and practical: by the end you will know how to find your agency's approved tool list, set up your account correctly, understand what you may and may not put into these tools, and configure the safety settings that protect you and the public. Your agency probably has approved AI tools available already. They may be an enterprise deployment of a commercial chatbot, a model reached through a government contract vehicle, or a specialized tool built for your agency's own needs. Having access to one is not the same as knowing how to use it responsibly. We will follow James as he does it the right way.

Why an approved list exists at all

It is not bureaucracy for its own sake. Authorized tools exist for a reason: they have been vetted, they have been checked against your agency's security requirements, they have been configured to protect government data, and their terms of service have been reviewed against the regulations your agency operates under. Unapproved tools, meanwhile, are everywhere, and it takes almost no effort to find one and start using it. The consequences of doing that are serious and concrete: data exposure, security vulnerabilities, and loss of compliance.

A public chatbot and an agency-approved one can look identical and behave identically, while being completely different underneath in the one way that matters: what happens to the data you type in. When your agency approves a tool, it has usually signed a contract that changes three things. First, an enterprise agreement under which the vendor states it will not use your inputs to train its models. Second, a security review, often through the federal FedRAMP program, the government's standardized cloud-security authorization, or a state equivalent, confirming the tool meets data-protection standards. Third, a data-handling boundary that keeps government information inside an approved environment.

Be precise about what the first of those actually buys you. A contractual commitment is something you can hold a vendor to; it is not a technical mechanism that makes training impossible, and it does not transfer from one product tier to another because the names sound similar. Read the terms attached to the specific tool and tier your agency licensed rather than assuming a label implies them. The free public version James used had none of these protections. Same chat box, entirely different legal and security reality, and nothing on the screen tells you which one you are in.

Step 1: Find your agency's approved tool list

Every agency publishes this somewhere, though "somewhere" varies. Check these in order, and stop when you find it. What you are looking for is not just a list of names, but a list annotated with what each tool does, who has access, the licensing terms, the security certifications behind it, and the policies governing what data may be used with it. A bare list of product names is not an authorization, and if that is all you can find, you have not finished this step.

1. Your IT or CIO intranet page. Your IT department should maintain the list of approved software and services, with AI tools on it. Look for "approved software," "AI tools," or "acceptable use policy." This is the authoritative source, and many agencies post AI tool guidance on internal SharePoint or intranet sites as well.
2. The acceptable use or AI policy document. Federal agencies maintain these under the Office of Management and Budget's 2024 AI guidance, memo M-24-10, which required agencies to inventory and govern their AI use. Also look for your agency's AI governance policies, Chief Information Officer directives, Chief Data Officer guidance, and any recent memos about AI. Your version names the tools and the rules.
3. Your supervisor or designated AI point of contact. Your supervisor should know what tools your team is authorized to use and may have specific guidance about what each one can be used for. Many agencies now have a Chief AI Officer or a responsible-use lead. Ask directly.
4. The IT help desk. If you cannot find a written list, file a ticket asking "What AI tools am I approved to use, and for what?" Keep the written answer.

If you still cannot find the information after working through all of those, you have learned something important rather than nothing: your agency may not have clear AI governance. That is a problem, and it is worth raising. But at least you now know not to proceed until you have clear authorization in writing. Silence is not permission, and an absent policy is not a permissive one.

James found his county's list on the IT intranet. It named two approved tools: an enterprise chatbot for general drafting, and a specialized records-search tool. The free public chatbot he had used was explicitly on the "do not use for government data" list. He had simply never looked, which is the ordinary way this goes wrong. Nobody in his office had looked either.

Step 2: Set up your account the right way

An approved tool only protects you if you access it through the approved door. Using the right product under a personal login can drop you right back into the unprotected public version. Expect to authenticate through your government email and password, through a government-wide single sign-on service, or through a dedicated account issued for that tool. Use your official government identity in all cases. Do not create personal accounts for work purposes and do not use a personal email to reach approved tools, because that creates liability and breaks the chain of custody for the data.

• Sign in with your government credentials only. Use your work email and single sign-on, never a personal account. The enterprise protections are tied to the government login.
• Confirm you are in the enterprise workspace. Look for your agency's name, logo, or a business or enterprise label. If you see consumer upsell ads or an invitation to upgrade to a personal paid plan, you are probably in the wrong version.
• Do not install browser extensions or plugins unless they are on the approved list. Many AI extensions quietly send page contents to third parties.
• Use only on a government-managed device if your policy requires it. Some tools are approved for work laptops but not personal phones.

Two features of enterprise access surprise people, and both are working as intended. The first is role-based access control. Some approved tools limit who can use them: a version cleared for classified work may only be available to people holding clearances, and a benefits determination tool may only be available to caseworkers. When you see "you don't have access to this tool," that is correct. You are not supposed to have access. Do not try to work around it, and do not ask a colleague with access to run the query on your behalf, which defeats the control entirely and puts them at risk rather than you.

The second is audit logging, which approved tools should have enabled. It records when you logged in, what data you accessed, what you asked the tool to do, and what the tool returned. This is a feature, not a bug: it is what makes accountability possible and misuse detectable, and it is also what protects you when you have followed policy and someone later asks what happened. While you are setting up, confirm data residency as well. Ask whether data sits on government servers in your country, on contractor-managed servers within your country, or on cloud servers in other countries, because agencies differ in what they permit and you need to know your own agency's requirement before you proceed.

Step 3: Know the data rules, the green and red list

This is the part that would have saved James. Even an approved tool has limits on what you may put into it, and the dividing line is data sensitivity. Approval is always scoped to particular uses and particular data types, never granted in general, which is why the specific policy attached to your specific tool is the thing that governs and not the fact of approval itself. Print this and tape it to your monitor.

Generally safe to input, in an approved tool

• Public information already published on your agency's website.
• Draft text with no personal or sensitive details, such as a generic memo outline or a policy summary you wrote.
• General questions, for instance "explain this zoning term in plain English."
• De-identified content with all names and identifiers removed.

Never input, even in an approved tool, unless your policy explicitly permits

• Personal information about citizens: names tied to cases, addresses, phone numbers, Social Security numbers, dates of birth, ID scans. This is what James pasted. Most approved tools carry policies restricting the use of personally identifiable information, so check whether yours is approved for PII, and if it is not, you cannot use it with PII.
• Protected categories: health records under HIPAA, tax data, criminal-justice records, anything covered by the Privacy Act.
• Law-enforcement-sensitive, procurement-sensitive, or classified material. Do not upload classified information to unclassified systems even when those systems are approved. Classified data never goes in any commercial tool, approved or not.
• Anything you would not email to someone outside your agency. That is a quick gut check that works surprisingly well.

Beyond data type, approved tools carry restrictions on purpose and on what you do with the output. Use is for work-related purposes only, so the answer to "can I use this to help with my side business?" is no. There is no commercial use, meaning you cannot use the tool to develop products or services you intend to sell. There is no sharing of outputs with parties outside your agency without explicit authorization. And output attribution may apply: if you use the tool to draft something, you may be required to disclose that AI was involved, particularly for public-facing documents.

The reliable instinct: an approved tool changes where your data goes, not whether it is sensitive. Approval protects the channel. It does not give you permission to share data that should never leave your agency in the first place. Before each use, run four questions. What is the policy on what data I can input? Should I include context, or anonymize my examples? Can I use the output in a public document, or only internally? Do I need to disclose that I used AI? And keep a fifth in reserve: what do I do if the tool returns something that looks like confidential information?

Step 4: Configure the safety settings

Most enterprise AI tools have settings that reduce risk. Spend five minutes turning them on, once, on the day you get the account, because nobody does this later.

• Turn off chat history or training contributions if the option exists. Even in enterprise tools, look for "improve the model for everyone" toggles and switch them off.
• Enable data-retention limits if your tool allows you to set how long conversations are stored. Shorter is safer.
• Check whether outputs are logged and assume they are. Treat every AI conversation as a potential public record subject to open-records requests.
• Do not share a login. When several people work through one account, audit logging cannot attribute anything to anyone, and if something goes wrong nobody can determine who caused it.
• Verify the output before you use it. The setting that matters most is your own judgment. Approved tools still hallucinate; never paste an AI answer into an official document without checking it.

A worked example: fifty complaint letters

Your agency approves an enterprise chatbot for government work and you get an account. You read the policies: no PII, no classified information, work-related purposes only, output disclosure required for public documents. Then you get a task. Review 50 citizen complaint letters and identify the common themes for a briefing. The letters contain names, addresses and case details. There is a compliant way to do this and a non-compliant one, and they take about the same amount of time.

The wrong option is to copy and paste the letters into the tool and ask it to summarize the themes. That violates the no-PII policy, and the fact that the tool is approved does not change the analysis, because the tool is approved for general use and not for PII processing. The right option inverts the order of the work. Read the letters yourself and write the summary that contains no personal data: slow processing, 15 complaints; staff rudeness, 8; unclear eligibility rules, 12; other, 15. Then ask the tool to suggest ways to address each category.

Look at what changed. You provided summary information without PII and used the tool for analysis rather than for processing sensitive data. The AI still did the part it is good at, which was generating options for each category, and the part that required handling citizens' personal information stayed with the person legally responsible for it. That is the difference between compliant and non-compliant use, and it usually looks like this: not a prohibition on using AI, but a decision about which half of the task the AI gets.

When in doubt, and how to report

You will hit gray areas. The professional move is to pause and ask, not to guess. If you are unsure whether something is allowed, treat it as not allowed until you confirm with your supervisor or AI point of contact. If you realize you have already made a mistake, like James did, report it promptly to your supervisor or security office. Early disclosure of an accidental data exposure is treated very differently from an exposure discovered later in an audit, and agencies can often contact the vendor to request that data be purged if they act fast.

Be clear-eyed about what reporting accomplishes. It makes remediation possible and it puts the agency in a position to respond; it does not undo the exposure, and it is not a guarantee that there will be no consequence. That is still overwhelmingly the better position to be in, and the alternative, hoping nobody notices, converts a mistake into a concealment. James reported his slip the same afternoon he learned about it. His IT team contacted the vendor, confirmed the free tool's retention window, and documented the incident.

Because he came forward quickly, it was handled as a teachable moment rather than as a violation. He now uses the approved enterprise tool, signed in with his county credentials, for exactly the tasks it is approved for, and the resident's ID scan never goes near a chat box again. The county also did something more useful than disciplining him: it added the walkthrough you have just read to onboarding, on the reasoning that a rule nobody has been shown is not really a rule.

Anti-Patterns to Avoid

• Assuming all AI tools are approved. An employee finds an exciting new AI service online and starts using it for work. It turns out not to be approved and not to meet security requirements, and the result is data exposure, a security vulnerability, and a policy violation.
• Using approved tools outside policy bounds. An employee with access to a tool that has clear policies against PII uploads a spreadsheet full of it anyway, reasoning that it is an approved tool so it must be safe. The tool is approved for general use, not for PII processing, and the exposure is real.
• Not reading the policies. Access arrives, work begins, and nobody opens the usage policy or learns the restrictions. The result is an accidental policy violation, and the fact that it was accidental is not much of a defense once data has moved.
• Sharing tool access. Several people use one login. That breaks audit logging and makes it impossible to track who did what, so when something goes wrong accountability collapses and nobody can establish who caused it.
• Treating the enterprise agreement as a technical guarantee. "Our contract says they will not train on our data" is a commitment you can enforce, not a mechanism that makes the outcome impossible, and it applies to the specific product and tier your agency licensed. Assuming a tier name carries the same terms as a differently named one is how a consumer account ends up holding government data.
• Reading approval as blanket permission. Vetting establishes that a tool met a standard for particular uses and particular data types. It does not certify the tool for whatever you happen to need next week, and it never converts sensitive data into shareable data.
• Assuming prompt reporting erases the exposure. Reporting fast is the right move and it materially improves the outcome. It is not an undo button, and treating it as one encourages exactly the casual pasting that caused the problem.

Practice Prompts

Do these against your actual account rather than hypothetically. Most people discover at least one surprise.

• List every AI tool you can currently use at your agency, and note where you found the list.
• For each tool on that list, write down the restrictions on the data types you may use with it.
• Pick one tool you are authorized to use and read its usage policy end to end. What are the restrictions? What can you not use it for?
• Open the tool's settings and check the training-contribution toggle, the retention setting, and whether you are signed in with your government identity in an enterprise workspace.
• Identify work you want to do with AI that you cannot do with the approved tools. What would need to change for it to become possible, and who decides that?

Reflection

• If you wanted to use an approved AI tool for a project you are working on right now, what data limitations would apply? Is there data you hold that you could not use?
• If an approved tool returned output that appeared to contain confidential information, what exactly would you do, and who would you tell first?
• Which of your routine tasks involve pasting text you did not write into a tool? How many of those texts contain something about an identifiable person?
• If your agency has no findable AI tool list, who is the right person to ask for one, and what would you say?

Glossary

• Approved tool. Software or a service that has been vetted by your agency and authorized for use with government data.
• Authentication. The process of verifying that you are who you claim to be, usually via a password or multi-factor authentication.
• Data residency. The location where data is physically stored.
• Audit logging. The recording of who accesses what data, when, and what they do with it.
• Policy compliance. Adherence to the rules and restrictions governing tool use.
• FedRAMP. The federal government's standardized cloud-security authorization program, one of the routes by which a tool reaches an approved list.

Related Lessons

• PII and AI: The Bright Red Lines goes deeper on the personal-data category that decides most of the red list above.
• Data Sensitivity and Classification explains the ladder from unclassified through CUI to classified material that the input rules depend on.
• Prompt Engineering Basics is the next step once you are inside the right tool with the right data.
• Evaluating AI Outputs develops the verification habit that the final safety setting depends on.
• AI Confidence and Hallucination explains why an approved, secure tool can still hand you a confidently wrong answer.
• Reporting AI Concerns in Your Agency covers the disclosure path James used and what happens after you file.

Closing

Your agency's approved tools are there for you to use. They have been vetted, secured and configured to protect government data, and using them is not a concession to bureaucracy but the thing that lets you use AI at work at all. Use them, use them responsibly within the scope they were approved for, and do not be tempted by unapproved alternatives that look identical in the browser and are nothing like it underneath. The gap between James before and James after was not intelligence or diligence. It was one visit to the intranet page and one pass through a settings screen.

Key Takeaways

• The chat box can look identical, the data reality is not. Approved tools carry a vetted security posture, reviewed terms of service, and a data boundary that free public versions lack.
• Find the authoritative list first. Check your IT or CIO intranet, your acceptable-use or AI policy, your AI point of contact, then the help desk, and keep the written answer. If nothing exists, do not proceed until you have written authorization.
• Access through the approved door. Sign in with government credentials, confirm you are in the enterprise workspace, never share a login, and avoid unapproved extensions and personal devices.
• Approval protects the channel, not the data. A tool approved for general use is not thereby approved for PII, and no approval makes sensitive data shareable.
• Restrictions cover purpose and output, not just input. Work purposes only, no commercial use, no external sharing without authorization, and AI disclosure may be required on public-facing documents.
• Access controls and audit logs are features. A denied tool is a correct denial, not an obstacle to route around, and logging is what makes accountability and your own protection possible.
• Use the email gut check. If you would not email it outside your agency, do not paste it into an AI tool.
• When unsure, ask; if you slip, report fast. Early disclosure makes remediation possible and is handled far better than something found later in an audit, though it is not an undo button.

Frequently Asked Questions

The tool is approved, so can I paste anything into it? No. Approval is scoped to particular uses and particular data types. A tool approved for general drafting is not thereby approved for personally identifiable information, and the reasoning "it is an approved tool so it must be safe" is one of the most common ways government data gets exposed. Check the specific policy attached to the specific tool.

What if I cannot find any approved tool list at all? Work through the IT or CIO intranet, the acceptable-use or AI policy, your supervisor or AI point of contact, and the help desk. If none of them produces an answer, you have confirmation that your agency may lack clear AI governance. Raise it, and do not proceed until you get clear authorization in writing. An absent policy is not a permissive one.

Can I use my personal account for the same product if it is faster? No. The enterprise protections are tied to the government login, so reaching the same product through a personal email or personal plan drops you back into the unprotected version, creates liability, and breaks the chain of custody for the data.

Are my AI conversations discoverable? Assume so. Approved tools log activity, and you should treat every AI conversation as a potential public record subject to open-records requests. That is a reason to be deliberate about what you type, not a reason to avoid the tool.

I was denied access to a tool a colleague can use. Should I ask them to run it for me? No. Role-based access exists because some tools are restricted to people with clearances or to specific job functions such as caseworkers. Asking someone else to run the query defeats the control, breaks the audit trail, and puts them at risk. Request access through the proper channel instead.

I already pasted something I should not have. What now? Report it promptly to your supervisor or security office. Early disclosure of an accidental exposure is treated very differently from one discovered later in an audit, and if the agency acts quickly it can often ask the vendor to purge the data. Reporting makes remediation possible; it does not undo the exposure, which is why it should happen the same day rather than after you have thought about it for a week.