Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show Notes: Building AI Agents Securely
Quick Take
AI agents are driving efficiency, but also introducing serious, often unseen security risks. As adoption accelerates, unvetted access, prompt injection, and poorly controlled environments can expose sensitive data and disrupt operations.
This episode of Compliance Unfiltered breaks down the key threats and shows how to mitigate them using proven principles like least privilege, input validation, and isolated execution.
Learn how to secure AI deployments and turn a growing risk into a resilient advantage.
Read The Transcript
So let’s face it, managing compliance sucks. It’s complicated, it’s hard to keep organized, and it requires a ton of expertise in order to survive the entire process.
Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less. Now, here’s your host, Todd Coshow, with Adam Goslin.
Todd Coshow:
Welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow, alongside the air conditioning to your compliance heat wave, Mr. Adam Goslin. How the heck are you, sir?
Adam Goslin:
Very apropos. I’m doing good, but hot.
Todd Coshow:
I can appreciate that. I’m sure that you are not the only person listening to this that appreciates that sentiment.
Today, as always, we want to take the opportunity to thank the folks that listen to this fine podcast.
If you’re listening to us on Spotify, please give us a five-star rating and review. It really helps out the podcast. We also want to know what you think, the topics of choice that you’d like us to cover, and we’d love to know your favorite summertime recipes. Give us a shout at [email protected].
Today, Adam, we’re going to talk about something that’s out there in the news, and that is building AI agents. But we’re going to talk about building AI agents securely.
You’ve been talking about the AI zombie walk for some period of time now. What perils are folks walking into with AI agents?
Adam Goslin:
We’ve got the democratization of agentic AI on the march. Anybody can get the latest tools and create these incredible AI agents that can do almost anything you can imagine. It’s part of the main reason why the agentic AI move can be a substantive risk for the organization as well.
One of the big problems they’re having right now is that, while security and compliance folks understand the risks of AI, there are a ton of frontline users that are just clicking buttons and building tools and making things automated and better. There isn’t, in a lot of cases, any thought to the security implications of what they’re in the process of doing.
Thinking about security isn’t an element of day-by-day workflow, and that’s where this notion of agentic AI comes in riskiest, if you will.
Leveraging platforms for building these AI agents without a security background, I’d liken it to giving a three-year-old an arc welder. It might be able to figure out how to turn it on, but can you imagine the untold damage that they could do with it?
You put a powerful AI tool in the hands of people that don’t know about protecting data, layers of security, and how to appropriately restrict access. They’re not going to know how to use it safely.
There are a lot of considerations when it comes down to building AI agents in a secure fashion. But most of it honestly comes down to security principles.
It’s possible for employees to build those safely, but there needs to be that marrying of the security and compliance-style mindset in conjunction with what’s going on.
Todd Coshow:
What type of efficiency risks are folks running into?
Adam Goslin:
AI agents are often used for personal efficiency and internal workplace functions. To give some examples: consolidating, summarizing, and filtering across multiple email accounts; automated execution of auto-replies; analyzing workflows and calendars for identifying efficiencies; gathering up data; and preparing written summaries of client projects.
These things may seem harmless, but just consider the risk of letting the AI agent loose on your calendar. How much data did you just expose as a result of clicking, “Sure, you’re going to have full access to my calendar”?
The agent has access to your client lists, client contacts, emails, signatures, phone numbers, and cell phone numbers. All of that starts to come into play as you’re granting blind access to Office 365, as an example.
Maybe that extends to OneDrive and SharePoint. Maybe, depending on the user and their access levels, they could be granting a ton of access.
Even things that seem innocent, such as tracking birthdays or anniversaries, could similarly produce greater levels of exposure than you were even considering.
The company needs to consider what is the data and information that’s exposed to the AI engine, how do we want to use it, and whether or not that data is secluded from other things.
If you’re moving from a free version to a paid version of AI, your users may still be jammed into some gigantic public pool of data storage.
Even when the AI vendors are claiming, “We don’t hand your data over to public AI models,” you need to look closely at what they are doing, such as utilizing the information that’s gleaned from the individual users when it comes to training their engines.
It’s a different way of looking at it. You really need to peek below the curtains, if you will.
Todd Coshow:
What types of permission considerations need to be made when it comes to AI agents?
Adam Goslin:
This is a general security premise. The general security premise is to mitigate risk by applying the notion of least-privilege access to information. Least-privilege access is about granting only the necessary level of access based on what’s needed, and no more.
A system administrator may need full access to all of the infrastructure assets, but the CEO doesn’t need the same technical access, despite them being higher on the organizational chart.
When it comes down to deploying AI agents, it’s important to understand what permissions it needs to be able to perform the tasks that you’re facing it with.
You need to think through how can I limit the capability of its access, restricting it only to titles of certain calendar entries, going back to the calendar example, instead of just giving it blind O365 access.
You need to take that into account. Restricting that agent’s access to only the information it needs also helps to protect your company, your customers, and sensitive information from being leveraged in a broader sense.
Todd Coshow:
What considerations do organizations need to take into account when it comes to agentic AI use in a business setting?
Adam Goslin:
It’s one thing to use agentic AI for personal workplace efficiency and be cognizant of sensitive data exposure, but it’s an entirely different thing when you’re talking about supporting broader workplace functions.
It means that you have to raise the scrutiny level several notches on the matter, if you will.
Allowing permissions to be granted only when necessary or on a temporary basis until the task is complete, rather than just being wide open all the time, would be an example.
You also need to drive the agents toward more specific, narrow tasks.
A common problem that organizations have is making the target of the purpose of the agent too broad. When an agent’s designed to handle these wide-sweeping tasks, like managing calendars, writing papers, and performing investigations all at the same time, it becomes astronomically difficult to dial down those permissions and button up to that least-privilege notion.
When you’re generating agents with specific purposes, now I’ve got the capability to dial in those permissions and access controls. I’m only truly granting exactly what’s needed if I’m doing it on a smaller scale.
In addition to defining those specific purposes, develop agents that have strict rules regarding what data they can process, what they can share, and where the hard boundary is for the AI engine.
For high-risk activities, things like sending outgoing emails, modifying a database, deleting data and files, or information, you always want to implement some form of human oversight and human approval.
This ensures that you aren’t just granting the automated system autonomous access to potentially do catastrophic actions within the environment.
For agents that are in a business setting, you want to avoid running them locally on primary machines or allowing them direct access to critical internal infrastructure.
Instead, take a notion of isolating that agent’s execution environment to a segregated, controlled location within the organization.
You can do that through separate devices, separate servers, or a virtual environment where you’re spinning up and down agents as you need them, shutting them off when you no longer do.
All of those things will, in a business setting, be really good ideas for the organization to consider.
Todd Coshow:
What about input sanitation and the implications for identity, auditing capability, and logging when it comes to AI agents?
Adam Goslin:
For the sanitization of inputs for prompt injection, it’s been a longstanding security premise that user inputs, anything coming in from the outside, could be malicious.
We need to sanitize those inputs coming in to increase resilience against any form of prompt injection.
Basically, it’s using input-validation components bolted onto input fields so that once an input’s submitted, it goes through a verification routine before it reaches the backend system, and you’re checking for malicious content such as SQL injection.
In a SQL-injection scenario, the attacker’s using unsanitized input fields to embed SQL statements, such as some form of command that will retrieve data and information that was not intended to be returned through that field, such as backend users, passwords, and things along those lines.
If the system’s vulnerable and that input’s left unsanitized, then it’s going to run off, execute, and bring back all the sensitive data straight to the bad actor. That’s that piece of it.
When it comes to identity, auditing, and logging, it’s been a fundamental tenet of security and compliance to be able to identify every person and every system that’s taking action within the boundaries of the organization.
People need to make sure that, as they’re going through and doing the testing of their AI agents, they can identify which specific AI agent it was that performed this function, validate its identity, and make sure that identity is associated with every single action that’s taken.
This will ensure that you maintain the capabilities for tracing, auditing, and attributing activity down to the specific agent.
To carry on from that, it also makes sure that the agent is pushing all of their appropriate logs to central logging so that we have the capability to really have full visibility in terms of monitoring what the heck is going on here.
Todd Coshow:
What are the implications when it comes to the software development lifecycle and security testing?
Adam Goslin:
The AI agent isn’t different from any other piece of code that’s being generated for a web or mobile app. It needs to be subject to the exact same principles of development change control.
Todd Coshow:
How easy is it to do that?
Adam Goslin:
What do you mean? It is no different. These are things that will be done with every piece of code. An agent would be no different.
Going through and doing the reviews, especially, it depends on the nature of the agentic AI that’s being leveraged.
Certainly, there’s a functional-testing aspect of it, where you can put it through its paces and see what’s spitting out in terms of logging on the backend.
Maybe the inside of it is more of a black box. For a lot of people, they are literally building the agents themselves and are able to get down to code level.
That would really enable a far more detailed peer-to-peer code review and security reviews, in conjunction with the end-to-end functional testing and making sure that the system is generating the outputs that you expect.
Specific to the AI arena, you need to establish a simulated sandbox environment where you can just set the agent loose to observe it, test it, and stretch the consequences of the planned activity.
It’s also really important to do security testing, specifically third-party penetration testing, on these chunks of code that you’ve developed.
A dedicated testing team is going to stretch the agent in various directions to validate that its input sanitation is holding up, that its boundaries can’t be thwarted, and things along those lines.
One of the mistakes that folks will make is that they’ll say, “We’ll just run vulnerability scanning.”
Scanning’s far different from a penetration-test-style scenario.
The third-party penetration testing team is essential because the internal developers, in many cases, are far too close to their own work.
They’re not going to test for unexpected things, think outside the box, or look at potential ripple impacts and implications that, as an example, an outside attacker would be targeting to exploit.
The depth and duration of that security testing really depends on the nature of the agent.
If we’re scraping news articles off Google, then it’s going to take a lot less scrutiny than if we had an autonomous agent that was authorized to delete system data or take action on inbound user tickets.
It depends on the nature of what that agent is supposed to be tasked with.
Todd Coshow:
Fair enough. What should organizations take into account when contemplating centralized IT governance?
Adam Goslin:
The organization needs to define how it’s protecting data.
The frontline users developing these AI agents for any use case need to validate and vet those tools through the IT department.
Centralized IT control is critical because it’s the IT crew that’s ultimately governing what can and can’t be done while establishing and validating boundaries that need to be in place, while still supporting business needs.
There’s not an expectation walking in that the person on your marketing team or one of the administrative assistants is somehow going to become an expert in security and compliance. Nor would we expect that the IT team is running the marketing plan.
Everybody’s got their place here.
The accessibility of these modern AI tools does mean that users can readily build things on their own without enforced interaction with IT. That’s where the danger comes into play.
When some administrative assistant unknowingly pours a massive amount of highly sensitive corporate data into an unvetted system to achieve the objective that they’re seeking, just imagine that this is the administrative assistant to the CEO as an example.
If they gave unfettered access to their mailbox and any connected mailboxes, holy moly, there could be an astronomical level of exposure there.
That’s really what we’re focusing in on and concerned about.
Todd Coshow:
Speaking of concerns, what concerns should organizations have surrounding prompt libraries and repositories?
Adam Goslin:
You want to make sure that the employees are thoughtful when it comes to using prompt-engineering libraries or cutting and pasting prompts from online sources.
The risk varies on a case-by-case basis, but depending on who’s provisioning them and their intended use, it needs to be handled no differently than pulling code samples from a public repository.
Most of the folks listening to the pod are familiar with that. It’s the same premise.
Grabbing prompts or code samples from some unknown, unvetted repository could be an unbelievably risky security decision.
Make sure you’re using reputable, secure, reliable sources.
Even if the original creator’s intent wasn’t malicious, the underlying actions and execution of unvetted prompts absolutely could be.
Regardless of the origination source of any code being leveraged for the organization, it still needs to go through standard code reviews, vetting, testing, various validation procedures, and be included in your annual penetration-testing scope.
Todd Coshow:
Finally, what about implications for self-hosting and network segmentation?
Adam Goslin:
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 the self-hosted implementation, just make sure to segregate those AI assets from both the core internal infrastructure and any of the day-to-day production machines.
Better yet, maintain absolute control over what access the self-hosted AI system has to the other environment.
Lock that arena down. Use strict firewall rules to govern the box that’s running the AI engine, defining exactly which internal systems it can interact with, strictly controlling outbound communication flow, locking down allowed communication ports, and limiting access to only the specific data and locations that are required for its function.
Those are all going to be good guidance for the self-hosting and segmentation arena.
Todd Coshow:
Parting shots and thoughts for the folks this week.
Adam Goslin:
To be honest with you, this whole AI arena reminds me a lot of the waves of a cowboy arena.
In the early days of the internet, we were having dot-com bubbles, and everything was cool because you had a website. People were more concerned with just flinging websites, data, information, and systems up than they were about anything surrounding security.
That died off. Then all of a sudden, we had APIs and automated mechanisms for the movement of information through automated systems.
Everybody had to have a web service or an API. If you didn’t have one, you weren’t cool. We weren’t really worried about the security of those either. That got a lot of people in trouble too.
Then we had mobile applications.
In every single case, as we’ve been seeing these elements of technology rolling out, you can see the burning desire in the early days was just to do it because it was cool. But it was done at the absolute peril of security and compliance every single time.
Honestly, AI isn’t any different.
We’ve got the quarterly security one coming up here, and one thing that I’m seeing a lot more of is AI-related data breaches, AI-company data breaches, etc., starting to really hit regularly and often.
It’s going to get exciting out there.
But back to the topic at hand. If your employees are building these AI agents themselves, then you need to make sure you understand what guardrails you need to put in place and what approval process you need to go through as an organization to protect the company.
I would issue clear communication about what’s permitted, what isn’t, etc., because right now, in this market, everything is moving astronomically quickly.
In order to protect the organization, you’ve got to give some directional guidance to the frontliners.
Todd Coshow:
And that right there, that’s the good stuff.
That’s all the time we have for this episode of Compliance Unfiltered. I’m Todd Coshow.
Adam Goslin:
And I’m Adam Goslin.
Todd Coshow:
Hope we helped to get you fired up to make your compliance suck less.
