What are five security practices for AI code assistants like Copilot?

Five practices make AI code assistants safer: review generated code like a stranger's pull request, run the same security scans on it, verify every package it suggests, control what data and context the assistant can see, and limit what agent tools may do. The assistant speeds typing. It does not take over responsibility.

1. Review AI output as untrusted input

An assistant predicts plausible code. Plausible is not the same as secure. Common failures are string-built SQL queries, missing authorisation checks, weak randomness and permissive configuration. OWASP's Top 10 for LLM Applications includes improper output handling for a reason.

Set a rule that no generated change merges without a human who understands it. Smaller changes make that rule realistic.

2. Run the same gates

Generated code should pass the same static analysis, dependency scan, secret scan and tests as any other code. Do not create an easier path for it. If anything, scan more carefully, since the author cannot explain its choices.

A constructed example. An assistant writes a file upload handler that saves files using the client-supplied name. A static analysis gate flags path traversal. The developer fixes it with a generated name and a type check. Without the gate, the review might have focused on whether the feature worked.

3. Verify suggested packages

Assistants sometimes suggest packages that do not exist or that sit close to a popular name. An attacker can register such a name and wait. OWASP lists supply chain weaknesses among the LLM risks.

Before installing, check that the package exists, who maintains it, how old it is and what advisories apply. A policy gate in CI that rejects unknown or very new packages catches mistakes made at speed. Safeguard's free in-browser scan at gold.safeguard.sh/scan checks up to 100 dependencies if you want a quick look.

4. Control what the assistant sees

Everything in the assistant's context can leave your machine, depending on the product's data handling. Decide what may be shared.

• Keep secrets out of repositories and out of open editor tabs.
• Exclude sensitive files with the exclusion settings your tool provides, where available.
• Read the vendor's terms on retention and training, and choose a plan or a self-hosted or bring-your-own model option that fits your data class.
• Be careful with proprietary or regulated code in tools you have not approved.

Prompt injection matters here too. An assistant that reads a README, an issue or a web page can follow instructions hidden in it. Treat external text as hostile.

5. Limit agent permissions

Modern assistants can run commands, edit many files and call tools through protocols such as MCP. Each tool is authority. Give agents the narrowest scope: a branch, not the main branch; read access to one repository, not the organisation; no production credentials.

Require approval for commands that change state outside the workspace. Log agent actions so you can investigate. Safeguard's MCP server and MCP Guardrail are built for this kind of control over what connected agents do.

What is the common thread?

Each practice puts a check between the assistant and the outcome: a reviewer, a scanner, a registry check, a data boundary, a permission limit. None of them requires the assistant to be right.

How to check or apply this

1. Write a one-page AI coding policy covering review, scanning and data.
2. Confirm the same CI gates run on all changes.
3. Add a package existence and age check before install.
4. Inventory which assistants and models are approved, and for which repositories.
5. Give agents least privilege tokens and require approval for risky actions.
6. Sample generated changes monthly and look for recurring weakness patterns.

Quick check

Sources

• OWASP Top 10 for LLM Applications, OWASP GenAI Security Project
• SP 800-218A, SSDF Community Profile for Generative AI, NIST
• AI Risk Management Framework, NIST

Last reviewed: 18 October 2026.