Securing AI and GenAI Use at Work

AI security starts with knowing what people are actually using

Most companies do not have an AI problem because employees are using ChatGPT, Microsoft Copilot or another GenAI tool. They have an AI problem because the organisation often does not know which tools are being used, what information is being entered, which accounts are connected, or what permissions those tools have.

That distinction matters. Banning AI completely is usually unrealistic, while allowing unrestricted use creates risks around confidential information, credentials, intellectual property, regulated data and access to business systems.

Start with an inventory.

Ask which AI services employees use for writing, coding, research, transcription, customer support, document analysis and automation. Include browser extensions, AI features embedded inside existing SaaS applications and developer tools. Do not limit the exercise to products that the IT department purchased.

This is the "shadow AI" problem. A finance employee may use an online document summariser without involving IT. A developer may connect an AI coding assistant to a private repository. A salesperson may paste customer information into a public chatbot to draft an email.

The technology may be useful. The problem is that the organisation has lost visibility over where information is going.

The first control is therefore not a sophisticated AI security platform. It is an accurate list of tools, users, data types and business purposes.

Separate public AI from business-controlled AI

Not every AI service presents the same risk.

There is a major difference between asking a public chatbot to rewrite a generic paragraph and connecting an AI system to SharePoint, Git repositories, customer records or internal databases.

The more data and authority an AI system receives, the more carefully it should be controlled.

For a business using Microsoft 365, for example, the relevant question is not simply whether Copilot is enabled. You need to understand what the user's existing permissions allow the AI system to retrieve. If a user already has access to sensitive documents through SharePoint, adding an AI interface can make that information easier to discover.

That means ordinary identity and access controls still matter.

Use separate administrative accounts. Require MFA. Review privileged access. Remove stale accounts. Apply least privilege to applications and service principals. Where the platform supports it, use conditional access policies to control access based on user, device, location and risk.

AI does not replace these controls. It makes poor access control easier to expose.

The same principle applies to AI coding tools. An assistant that can read a repository and suggest code is useful. An agent that can modify files, run commands, access credentials or deploy changes is a different security proposition.

Treat AI agents according to the permissions they have, not the friendly interface they present.

Protect the data before trying to police every prompt

A common mistake is attempting to create a giant list of prohibited prompts.

That is difficult to enforce and quickly becomes obsolete. A better approach is to classify information and decide what each class can be used with.

For example, a company might define four practical categories:

• Public:

  information already intended for public release.

• Internal:

  ordinary business information that is not public.

• Confidential:

  commercial, employee, customer or operational information requiring controlled access.

• Restricted:

  information subject to legal, regulatory, contractual or security restrictions.

The policy can then define which AI services may process each category.

Public information might be acceptable in a public AI service. Restricted information may require an approved enterprise service with appropriate contractual, identity and data-handling controls. Some information may simply be prohibited from AI processing unless a specific business process has been approved.

This is much easier for employees to understand than a policy saying "do not put sensitive data into AI".

The policy also needs to cover credentials and secrets. API keys, passwords, private certificates, access tokens and connection strings should never be pasted into an AI prompt simply because the model can help diagnose an error.

Source code needs similar treatment. Code can contain secrets, proprietary logic and customer information. A developer using an AI coding tool should understand exactly what the tool can access, where prompts and context are processed, and whether the organisation has approved that configuration.

Techx4u's GenAI protection services are relevant to this layer because the objective is not simply blocking AI. It is controlling how AI is used with business information.

What people get wrong about AI security

The first mistake is believing that an AI policy is enough.

A policy does not stop a user from pasting a spreadsheet into an unapproved service. If the control depends entirely on employees remembering the policy, it is a human-control problem rather than a technical control.

The second mistake is assuming enterprise AI automatically means safe AI.

An enterprise licence may provide stronger administrative controls, but it does not fix excessive SharePoint permissions, overprivileged identities, exposed API keys or badly designed integrations.

The third mistake is treating AI as a completely separate security category.

Much of the required security is familiar. Identity management, endpoint security, network controls, data classification, application permissions, logging, vulnerability management and incident response still matter.

The new part is the way AI can combine these capabilities.

An AI application may have access to documents, email, calendars, source code or internal APIs. An AI agent may also be able to take actions rather than simply return text. That changes the impact of a compromised account or badly designed integration.

The recent Rejetto HFS vulnerability is a useful example of why technical capability matters. Horizon3 reported on 30 September that its research using Anthropic's Mythos identified a chain that could turn a weak session-signing mechanism into administrator access and remote code execution. VulnCheck subsequently reported exploitation attempts beginning on 1 October. The important lesson for businesses is not that AI caused the vulnerability; it is that automation can reduce the time and specialist effort required to discover and operationalise complex weaknesses.

The fourth mistake is blocking everything.

A blanket ban often pushes usage underground. Employees still have deadlines. If the approved route is too restrictive, they may find an unapproved alternative.

A better model is controlled enablement. Provide approved tools, clear data rules and sensible technical controls. Make the secure route usable enough that employees have a reason to follow it.

AI agents need a different level of control

The biggest change is moving from AI that answers questions to AI that performs actions.

A chatbot that drafts a response has limited authority. An agent connected to a CRM, ticketing system, cloud account or source-code repository may have considerably more.

For each AI integration, ask four questions:

What can it read? Identify the data sources, files, mailboxes, repositories and APIs available to it.

What can it write? Reading information is one risk. Creating, modifying or deleting information is another.

What can it execute? An agent that can run commands or trigger workflows needs stronger controls than one that only generates text.

Who controls it? There should be an owner responsible for the integration, permissions, credentials, logging and review.

Use separate service identities where possible. Give them only the permissions required for the workflow. Store secrets in appropriate secret-management systems rather than configuration files or prompts. Log significant actions.

For high-impact workflows, consider approval gates. An AI system may prepare a payment, change a customer record or generate a production configuration, but a human can be required to approve the final action.

That introduces friction. It also prevents an automation error from becoming an unauthorised business action.

This is where AI security and GenAI protection needs to connect with normal IT operations rather than becoming another isolated dashboard.

What to actually do in order

First, inventory AI use. Include sanctioned products, browser tools, developer assistants, SaaS features and AI-powered automation.

Second, classify the information employees work with. Do not attempt to classify every possible prompt. Define practical categories and examples that staff can understand.

Third, approve a small set of business AI tools. For each one, document what data it can process, what administrative controls exist and which users are allowed to use it.

Fourth, fix identity and permissions. MFA, least privilege, privileged-account separation and regular access reviews remain fundamental. AI should not be given more access than the human or workflow actually requires.

Fifth, control integrations. Review API permissions, OAuth grants, service accounts, connectors and application registrations. Remove integrations that nobody owns.

Sixth, introduce logging and review for higher-risk AI activity. You do not necessarily need to record every harmless prompt. Focus on access to sensitive data, administrative actions, external sharing and automated changes.

Seventh, train employees on realistic scenarios. Show them what should happen when they receive confidential customer information, source code or credentials and want AI assistance. The policy becomes useful when people know what to do in the situation they actually face.

Eighth, test the controls. Try the approved workflow with restricted data. Review whether an ordinary user can access information they should not. Check whether an AI integration can perform actions outside its intended scope.

Finally, review the AI environment whenever a new agent, connector or business integration is introduced. AI security is not a one-time configuration exercise. Permissions and capabilities change as quickly as the applications around them.

For a 20 to 500 person company, the sensible objective is not to eliminate AI use. It is to make AI use visible, controlled and proportionate to the information and authority involved.

The companies with the strongest position will not necessarily be those with the most AI security products. They will be the ones that know what their AI systems can access, what they can do, who owns them and what happens when something goes wrong.