8 secure AI practices your engineering teams should be following

I’m not Lewis Hamilton, but I’m fairly certain I could drive a F1 racecar at 200 MPH. Turning a corner safely, though, or getting safely to the finish line? Absolutely not. If I tried, there’d be nothing but a cartoon-shaped imprint on the very first corner of the Circuit de Monaco.

There’s a big difference between velocity and safety. Achieving one or the other isn’t so hard — I could finish the Monaco Grand Prix in one piece if I was allowed to chug along at 20 MPH, but I certainly wouldn’t win any prizes. It’s achieving velocity and safety at the same time that’s the real trick.

AI is exactly the same. It’s easy enough to achieve AI safety without speed (overgovernance) or speed without safety (undergovernance). Obviously, neither result in positive business outcomes, and knowing how to strike this balance can be paralyzing — during question time at tech industry events, one of the most frequently asked questions is:

“How can we use AI at scale in our engineering teams while managing the risks?”

This question is salient not just for cybersecurity and engineering leaders, but also for L&D teams. Why? Because if your teams aren’t trained in AI best practice, they can’t apply it. In this article, I’ll cover the most popular best practices engineering teams are using in 2026, so you can compare it to your current approach and identify potential gaps.

1. Secure prompt hygiene

Sensitive information should never go into AI prompts. Yes, this sounds obvious, but there’s a reason cybersecurity educators wind up repeating this so much: it’s because even smart engineers keep doing it. This includes things like, but is not limited to:

• Not sharing API keys and secrets

• Not entering personally identifiable information (PII) into prompts, including customer data

• Not entering proprietary algorithms

2. Scoping agent permissions and tool access

Would you give an intern the keys to the CEO’s car and an unrestricted business expense card? No, that would be a terrible idea. But that’s close to what engineers do when they give AI overly broad permissions, not out of carelessness, but because tightly scoped agents can fail halfway through a task, and widening access is the fastest way to unblock the work.

Engineers working with agents constantly need to make these judgement calls on how much permission to give it in order to do its job: what tools it can use, what data it can read, what actions it can perform and where, and for how long. However, the consequences of getting this wrong can cause serious problems. Think of an AI agent introducing breaking errors into your products and services, deleting everything, or being hijacked by bad actors to do real business damage.

To counter this, your engineers should not only know how to properly scope permissions and tool access, but be practicing a zero trust approach with AI, especially the Principle of Least Privilege (PoLP).

3. Incorporating agentic guardrails into tools

AI guardrails are safeguards that stop AI tools from acting in ways you don’t want them to. For example, if a bad actor tries to tell your publicly-facing AI tool to help them build a bomb (prompt injection), there’s guardrails that can stop that from being executed. Obviously, these are really good to have for any AI agents you’re using, whether they’re internally or externally facing.

While it might sound like these are something the AI vendor has exclusive control over, your engineers can actually build these directly into your agents. These include:

• Relevance classifiers, which ensure the agent stays within intended scope

• Safety classifiers, which detect unsafe inputs, such as prompt injections or malicious instructions

• PII filters, which detect and filter out personally identifiable information (PII)

• Moderation, to flag things that are toxic or inappropriate

• Tool safeguards, which assess the risk of each tool available to the agent and can restrict or approve actions dynamically

4. Setting up LLM and MCP gateways for uniform governance

If your organization uses or delivers more than one AI solution, how do you make sure that they all have the same safeguards in place, and those are kept up to date? It’s a pain if you have to task your engineers with hunting down and updating each one individually — that’s a lot of wasted time, and you’re sure to miss something.

LLM and MCP gateways help solve this issue, acting as the middleware between AI agents (like Claude) and MCP servers. This allows for the guardrails (e.g. PII filtering, prompt guardrails, safety classifiers) to be centrally applied and managed. It can even help reduce token use by cutting down on context bloat.

The decision to implement these is a specific build choice by leaders, one that requires engineers with sufficient skills to build, deploy, and manage. And once it’s in place, every AI-assisted action an engineer performs is routed through this process.

5. Building auditable, traceable agentic workflows

Audits. Everyone loves them, right? In sectors like healthcare, finance, or government, the software you produce can be put under the microscope to make sure you’re industry compliant. 

This already uncomfortable process can become even more so when a regular or auditor asks your engineers why they made a decision, and there’s no record, because the only evidence was in a chat window that deleted itself months ago. To avoid this from happening, your software engineering teams should adopt practices like  Spec-Driven Development so there is auditability and accountability.

6. Evaluating plugins, extensions, and MCP servers before adoption

When you set up a work computer, you don’t just install Windows and call it a day. You try to make your computer more useful by installing things like the Chrome Browser, Microsoft Office, Slack, Zoom, and so on. Each of these is a third-party tool made by someone else that could be used to hack into your computer, but you trust them because they’ve been vetted and approved by the IT team. 

AI tools for engineers are exactly the same. Out of the box, they’re rather limited, but you can make them more useful with plugins and extensions. Since these introduce third-party security vulnerabilities, you shouldn’t just install them for a whole team and call it a day. Instead, your teams need to evaluate these for security and capability first (and know how to do this.)

7. Reviewing AI-generated output at volume

Knowing how and when to review agentic output is a skill in itself. Unsupervised, AI tools can run wild, creating security and business risks in the process. To counter this:

• Safety, governance, and the need for AI oversight must be stressed at the individual level

• Engineers should understand the different agentic evaluation techniques (E.g. HITL, LLM-as-a-Judge.)

• Engineers should know the right and wrong use cases, as well as the limitations of AI tools

• Emphasize that AI responsibility and explainability still lies with engineers

8. Experimenting safely in sandboxed environments

Sandboxes are secure virtual spaces (such as terminals, code editors, or cloud consoles) where you can experiment, practice, and learn in a controlled environment. This gives your engineers somewhere to:

• Practice a new skill in a low-pressure setting

• Focus on the task at hand without installing anything

• Try out a new tool without cluttering their local environment

Because these sandboxes are often offered by a third party as part of a subscription, this mitigates the risk of an engineer accidentally creating a large business expense (for example, experimenting with an AI model in AWS and generating a large computational bill).

More on AI adoption in engineering

Want to know where your engineering teams sit in terms of AI readiness compared to others? Take Pluralsight's 6-minute AI Readiness assessment to measure your engineering team's current AI proficiency, identify capability gaps, and get improvement recommendations. 

If you found this article helpful, you may also enjoy these other entries on the Pluralsight blog:

• 8 AI skills engineering teams need in 2026
• The 5 AI tools modern software engineers are using in 2026
• Why your organization's cloud maturity is tied to your AI maturity