How to Build AI Agents Securely

One of the marvels of today’s technology is the democratization of agentic AI. Anyone can access the latest tools to create incredible AI agents that do almost anything you can imagine. That’s also why agentic AI can be such a risk for your organization.

One of the biggest problems right now is that while security and compliance experts understand the risks of AI, many frontline users are simply clicking buttons and building functional tools without considering the security implications. Thinking about security simply isn’t an element of their day-to-day workflow, and that’s where agentic AI is riskiest.

Your Company’s AI Adoption Is a Security Nightmare 

Leveraging platforms to build an AI agent without a security background is like giving a three-year-old an arc welder. They might figure out how to turn it on, but just imagine the untold damage they could do with it. Likewise, when you drop a powerful AI tool into the hands of someone who doesn’t know about protecting data and layers of security, they won’t know how to use it safely.

Many of the considerations around building AI agents securely essentially come down to general security principles. It’s certainly possible for your employees to build agents safely, but only if they know those basic security principles.

Let’s take a look at the AI security considerations your company must keep in mind when employees are permitted to build AI agents for greater productivity.

The Risks of Efficiency with AI

AI agents are frequently used for personal efficiency and internal workplace functions — for example: 

• Consolidating, summarizing, and filtering across multiple email accounts
• Executing auto-replies
• Analyzing workflows and calendars to find efficiencies
• Gathering data
• Preparing written summaries for client projects

These may seem like harmless activities, but consider the risk of setting an AI agent loose on a calendar. Think about how much data is exposed as a result. The agent has access to your client list and client contacts — and, by extension, emails, signatures, phone numbers, and cell phone numbers are all exposed. If you grant AI blind access to a platform like Office 365, that access can extend to OneDrive, SharePoint, and every piece of documentation stored there. 

Even an innocent use case like tracking birthdays or anniversaries on a calendar could produce a massive amount of exposure.

Your company must consider what data and information is exposed to the AI engine, the nature of its use, and whether that data is secluded from others. If you move from a free version to a paid version of AI, your users may still be jammed into a gigantic public pool of data storage. 

Even when AI vendors claim they don’t hand data over to public AI models, you must look closely at what they’re doing, such as utilizing information gleaned from individual users to train their internal engines.

Applying Least Privilege Principles to AI Agents

You can mitigate your security risks by applying the notion of least privilege access to information. Least privilege is about granting only the necessary level of access based on what is needed, and nothing more. For example, while a system administrator needs full access to infrastructure assets, the CEO doesn’t require that same technical access despite being higher in the organizational chart. 

When deploying an AI agent, you must understand what permissions it requires to perform its task. You need to evaluate the capability to limit its access — such as restricting it to only the titles of calendar entries — instead of it pulling your full contact lists, emails, and drive files.

Restricting an agent’s access to only the information it needs helps your company protect your (and your customers’) sensitive information from the risk of accidental exposure.

Scrutinize Agentic AI for Broader Business Functions

It’s one thing to use agentic AI for personal workplace efficiency, while being cognizant of any sensitive data exposure. It’s quite another thing to use it for supporting broader workplace functions, and that requires a much greater level of scrutiny. Permissions must be granted only when necessary and/or on a temporary basis until the task is complete, rather than ad infinitum.

You must also drive agents toward specific, narrow tasks. A common problem is making the target or purpose of an agent overly broad. When an agent is designed to handle wide, sweeping tasks — like managing a calendar, writing papers, and performing investigation all at once — it becomes monumentally more difficult to secure and dial down permissions. When you generate agents with specific purposes, you can precisely dial in permissions and access controls in accordance with need.

In addition to defining specific purposes, develop agents with strict rules regarding what data they can process and share, establishing a hard boundary for the AI engine. For high-risk actions — such as sending outgoing emails, modifying a database, or deleting data, files, and information — always implement human oversight and approval. This ensures you aren’t granting an automated system autonomous access to perform potentially catastrophic actions.

For agents in a business setting, avoid running them locally on primary machines or allowing them direct access to critical internal infrastructure. Instead, isolate the agent’s execution environment in a segregated and controlled location within the organization. 

You can achieve this by using separate devices or servers, virtual private servers, or a containerized environment to spin the agents up as needed and shut them down when completed.

Sanitize Inputs for Prompt Injection

A long-standing security guardrail for systems and applications is to operate under the assumption that user inputs and anything coming from the outside could be malicious. You must sanitize the inputs coming into the system to increase resilience against prompt injection.

Sanitization means using input validation components that are bolted onto input fields so that once an input is submitted, it goes through a verification routine before reaching the backend system. This process checks for malicious intent, such as SQL injection. 

In a SQL injection scenario, an attacker uses an unsanitized input field to embed a SQL statement — such as a command to retrieve all backend users and passwords. If the system is vulnerable and the input is left unsanitized, it will execute and return that sensitive data to the bad actor. 

AI-powered Cyberattacks Are Coming for Your Data. How Prepared Are You?

Identity, Auditing, and Logging

A fundamental tenet of security and compliance is the ability to identify every person or system taking action within your organizational boundaries. That same tenet must apply to AI. You must be able to clearly identify which specific AI agent performed a function, validate its identity, and associate that identity with every action taken. 

This ensures that you maintain the capability to trace, audit, and attribute activity to a specific agent. Furthermore, ensure the agent pushes all appropriate logs to central logging so you have full visibility to monitor its operations.

The Development Lifecycle and Security Testing

An AI agent is no different from any other piece of code generated for a website or a mobile application. It must be subject to the exact same principles of development change control, peer-to-peer code reviews, security reviews, and end-to-end testing.

Specific to the AI arena, you need to establish a simulated sandbox environment where you can set the agent loose to observe, test, and stretch the consequences of its intended activity. It is also essential to perform security testing, specifically third-party penetration testing. 

A dedicated testing team will stretch the agent in various directions to validate that its input sanitation holds up and that its boundaries cannot be thwarted. 

Don’t rely solely on vulnerability scanning. Scanning is markedly different from penetration testing. A third-party team is essential because internal developers are often too close to their own work and won’t test for the unexpected variables an outside attacker would exploit.

The depth and duration of this testing depend entirely on the nature of the agent. An agent that simply scrapes public news articles off Google would require less testing compared to an autonomous agent authorized to delete system data based on inbound user ticket submissions.

Centralized IT Governance

Your organization must define how it protects your data. Frontline users developing AI agents for any use case must validate and vet those tools through the IT department. Centralized IT control is critical because the IT crew ultimately governs what can and cannot be done while establishing and validating the appropriate boundaries to support business needs.

We don’t expect a marketing professional or an administrative assistant to become an expert in security and compliance, just as we wouldn’t expect the IT team to run a marketing plan. However, the accessibility of modern AI tools means users can easily build things on their own without any enforced interaction with IT. This is dangerous for an organization. 

When an administrative assistant unknowingly pours a massive amount of highly sensitive corporate data into an unvetted system to achieve an objective, it puts the organization in a position of increased risk. 

All AI agent development should be brought back to IT for central oversight.

Use Prompt Libraries and Repositories with Caution

Make sure your employees are thoughtful when using prompt engineering libraries or cutting and pasting prompts from online sources. The risk varies, depending on who is provisioning them and their intended use. 

This needs to be handled no differently than pulling code samples from public repositories. Grabbing prompts or code samples from an unknown or unvetted repository is an extremely risky security decision. You must use reputable, secure, and reliable sources. Even if the original creator’s intent wasn’t malicious, the underlying actions and execution of unvetted prompts absolutely can be. Regardless of the origination source of any code being leveraged for the organization, it must still go through standard code review, vetting, testing and validation procedures.

Self-Hosting and Network Segmentation

Self-hosting an AI orchestration platform is an appealing option for organizations looking to avoid high-volume cloud token fees and monthly subscription costs. If you choose a self-hosted implementation, segregate your AI assets from both your core internal infrastructure and your day-to-day production machines.

Furthermore, maintain absolute control over what access the self-hosted AI system has to other environments. Establish strict firewall rules to govern the box running the AI engine. This includes defining exactly which internal systems can interact with it, controlling outbound communication flows, locking down allowed communication ports, and limiting its access to only the specific data and locations required for its function.

Keep Your Data Safe with AI 

If your employees are going to build AI agents themselves, make sure they understand how to do it securely. Communicate very clearly what’s permitted and what isn’t permitted. 

The market is moving incredibly fast, and new platforms are popping up constantly. Focus on applying these foundational security guardrails across whatever tools you utilize.