Do you hear that? AI is already inside your house, hiding inside almost everything with an internet connection. Waiting to recite a half-correct answer you didn’t ask for. Or worse: ask you what else it can help you with.
Whichever side of the AI debate you find yourself on, you can at least be sure of one thing: your employees are using it whether you like it or not.
AI has been made accessible to everyone with a screen. It's baked into virtually every user interface so seamlessly that it's sometimes difficult to tell you’re using it. The major contemporary AI applications (ChatGPT, Copilot, Claude, etc.) are all trivial to access via desktop apps, mobile apps, or directly in a web browser.
There’s no doubt your employees and teammates are using one of them at this very moment, maybe to help fix their application code. The code a client said should never be exposed outside of your organization.
That may sound like the beginning of a certain movie (or maybe several movies) about intelligent machines taking over humanity. Fortunately, administrators do not need to send anyone back through time to stop them.
Like other, more ordinary applications, AI agents can be made safe to use. With some thoughtful planning and implementation, IT and network administrators can limit what those agents can access and prevent them from acting beyond their intended bounds with the tools and controls they’re already familiar with.
By following Zero Trust principles, organizations can feel secure letting the agents inside, so long as they’re careful to lock every door they don’t need to open.
They can't be bargained with. They can't be reasoned with: Employees are already using AI.
AI agents are a step above your typical AI chatbot. Agents are allocated the permissions and mechanisms to interact with other tools beyond a chatbot’s typical boundaries, which usually end at what it has learned through its large-language model (LLM) and through searching the internet.
For instance, a devops engineer could hypothetically use a chatbot to analyze the output logs of a failed CI/CD job and expect it to, at most, explain the error and recommend the next steps it’d take. It can only do so much, given it only knows what it’s so far learned about software deployment troubleshooting through its model, and even then it still might get the context wrong and suggest you do something at best a waste of time, at worst devastating. It’s all fun and games until ChatGPT asks you to delete your container namespace.
An AI agent, however, is only as limited as the resources it has access to (and the bank account of the engineer). An agent connected to the project’s CI/CD platform, code repository, containers, and development infrastructure could assess what failed, create its own feature branch with its attempted correction, and open a pull request to await approval. The possibilities are nearly limitless.
With little effort or technical know-how, the usual chatbot culprits like Claude and ChatGPT can be enhanced with agent capabilities. Automation platforms, like Zapier or Microsoft’s Power Automate, can be installed as web browser extensions that read a user’s input into their chatbot and extend it to any arbitrary tool or system.
And that’s just for users with access to free, unpaid tools. Paid versions support integration right out of the box. Employees with access to the paid version of Copilot can, for instance, ask it to build and execute a Visual Basic script that transforms financial data in any Excel workbook it has permission to read in your M365 tenant. Claude Pro might be asked to build a working, interactive browser application that displays metrics it derives from arbitrary internal files, source code, or databases.
These are exciting, powerful capabilities that can accelerate a business’s output by orders of magnitude. Or reduce manpower through task automation. Or cost your business because your agent executed the wrong code. Let’s discuss how to avoid the latter by explaining how to mitigate the risks posed by these tempting ideas.
Not a robot, not a cyborg: AI agent security risks
The risks AI agents pose to a business environment are like those IT and security teams are used to dealing with, with only a few new surprises (which do not include becoming self-aware (yet)):
Transitive trust
An employee may hypothetically ask an agent to summarize all the documentation associated with a particular project and prepare a report. Behind its chat interface, its workflow might invoke PowerShell, open Microsoft Office, run a script, and connect to an external service, all in the name of accomplishing what it was asked.
This creates a technical challenge known as transitive trust: Just because an AI agent is allowed to run doesn’t mean it should be able to use every other application or network connection it attempts to access.
Agents can expose sensitive data
An agent cannot distinguish between ordinary and sensitive information unless the application, its prompt or instructions, or a surrounding security control provides that distinction.
For example, an employee could ask an agent to summarize a folder’s contents without realizing that it contains payroll files, customer records, credentials, or confidential agreements. An agent might then transmit content to a connected cloud service, include it in its generated answers, or save it in a location with storage access controls that are weaker than those at its origin.
Further, free-tier AI tools often train their LLMs with chat input from their users. Anything your employees input into these chatbots, including sensitive information or source code, may wind up as a knowledge source for the agent to learn from.
Agents can be wrong
AI output can be inaccurate. At least when AI output is only text, someone has the chance to review and catch any errors or misjudgments before blindly destroying their development environment. But when an agent is allowed to execute commands, edit files, or transform data, an incorrect decision can cause havoc.
The potential impact depends on the agent’s permissions. An agent running with administrator rights could cause the most damage, like modifying a CI/CD pipeline or communicating with unapproved network destinations. The more permissions an AI agent is allocated, the more security and business consequences.
Prompts aren’t deterministic
No matter how specific and comprehensive a user makes an agent prompt or input, there is no guarantee that an AI agent will behave in the intended or expected manner. AI agents can’t yet make decisions that rely on intuitive meaning. Semantics, context, and what the agent ultimately has permissions and access to all matter.
Just because a user might include the text “do not upload any data to this web server” doesn’t take away the agent’s configured permissions to upload that data. Unless a deterministic security control is enabled, like removing the agent’s access to the web server, it might be one misinterpreted chat away from unintentionally disobeying its prompt.
Astronomical expenses
Once a user strays outside of an AI tool’s free-tier, it can become expensive. Fast. Accessing an LLM’s API (i.e., asking it to do things) costs tokens (aka, money). If you ask it to store something in its memory, that costs money, too. If it accesses a third party’s API, that might cost you even more money. Money that you’ll only be notified of when that third party adds a charge to your account.
Unless measures are taken to limit the number of actions an agent can take, you may be one poorly coded for-loop from being charged your yearly salary in tokens.
Come with me if you want to live: Zero Trust tips for AI agent security
Despite the heavy risks involved, AI agents are only as dangerous as you allow them to be, regardless of how audacious your users are. Even John Connor made the T-1000 safe enough for business use.
Businesses don’t seem to have much choice, either way. It’s a matter of getting used to agents now or risk falling behind.
Consider exercising the following Zero Trust security practices to keep your agents from running amok and inciting your company’s own judgment day:
- Identify and take inventory of the AI usage throughout your company.
Use remote management, asset management, and endpoint detection software to discover where AI agents are installed and who is using them.
Examine web and network activity for connections to AI servers. Audit OAuth integrations to identify the services, like M365, Slack, or other third-party business services your company uses, that AI tools are requesting access to.
- Define approved business use cases and codify them in official policy documents.
Start with a trusted authority’s guidance, like NIST’s, and apply their playbook to your organization’s specific circumstances. Try to be as specific as possible about the types and classifications of information users may submit to AI, which AI services they may use, and whether those services may make changes to production environments or data without a human reviewing those changes first.
Above all else, employees’ personal AI service accounts should never be used on company assets or with regulated or sensitive projects.
- Enforce least privilege for both AI users and AI agents.
Disable local administrator access from and remove administrative user and service account credentials from AI agents. When integrating AI services with other tools and systems via OAuth, grant as narrow a scope of permissions as possible to the AI’s account or identity. Use separate accounts or identities for each AI service.
If AI agents can access an API, do not permit access via persistent, unchanging API keys or other secrets. Implement multifactor authentication (MFA) for user accounts created for each AI service, where possible.
- Use application allowlisting to automatically prohibit unapproved AI applications, scripts, processes, or web browser extensions from executing.
For any AI applications that should be permitted, configure their allowlisting policies to restrict the child processes they can launch or the network sockets they can negotiate.
Approved AI tools should not be able to open other applications or processes, such as PowerShell, unless explicitly permitted by policy.
- Segment data and network access.
Limit agents' access only to the folders, applications, services, and network destinations required to perform their specific, approved duties.
- Log local AI activity through a SIEM or other log analyzer, and any AI access made to cloud tenants through those cloud services’ log analytic tools.
Use an advanced data governance tool, like Microsoft Purview or NinjaOne, to understand and secure the data accessed by AI.
You’re terminated, Claude!
AI agents can be extraordinarily useful to any business, and you should start preparing your organization to securely manage them now. They’re coming for you, either way.
ThreatLocker offers Zero Trust controls for AI tools and agents, including Zero Trust AI Control (ZTAIC), Application Allowlisting, Ringfencing™, Zero Trust Network Access (ZTNA), Zero Trust Cloud Access (ZTCA), and configuration management policies.
Give users the AI capabilities they need while blocking everything the agent does not. Book a demo of ThreatLocker Zero Trust AI Control today, before the machines start submitting their own support tickets against you. No time travel required.
