How do you use AI coding assistants safely in an enterprise?

Use AI coding assistants safely by deciding what data may reach them, approving specific tools, requiring human review and normal security scans on all generated code, and checking every dependency they suggest. Treat the assistant as a fast junior contributor whose output is untrusted until a person and your pipeline have verified it.

What are the main risks?

The OWASP Top 10 for LLM applications (2025 edition) lists the categories that matter here. Four stand out for coding use:

• Prompt injection (LLM01). Text the model reads can steer it. In a coding tool, that text may come from a README, an issue, a web page or a file in the repository.
• Sensitive information disclosure (LLM02). Whatever you paste or let the tool read may leave your boundary: source, keys, customer data.
• Supply chain (LLM03). Models, plugins and extensions are third-party components with their own risks.
• Misinformation (LLM09). OWASP describes hallucination and overreliance, and its example of unsafe code generation covers a model suggesting insecure or non-existent code libraries that cause vulnerabilities when trusted without verification.

NIST has also published SP 800-218A, a community profile that adds AI model development practices to the Secure Software Development Framework. It is aimed at those building models, but its theme applies to users too: the usual secure development practices still apply when AI is involved.

What data should never go in a prompt?

Write the rule in plain terms. A constructed example policy:

• Never: credentials, private keys, tokens, customer personal data, unreleased security fixes, regulated data.
• With approval only: proprietary source for products under contract restrictions.
• Fine: public code, open source questions, generic design discussions.

Then enforce it in places where people actually work. Secret scanning in the editor and in pre-commit hooks catches the common mistake of a key sitting in an open file that the assistant reads.

Also ask each provider: is prompt data retained, is it used for training, where is it processed, who can access it, and can you switch retention off by contract or configuration? Get the answers in writing and keep them with your vendor review.

How do you handle the code it writes?

Generated code needs the same gates as human code, and sometimes more attention, because it can look polished while being wrong.

• Require pull requests and human review. The reviewer owns the merge, not the tool.
• Run static analysis and dependency scanning on every change.
• Verify any new package: does it exist, who maintains it, is the name exactly right, is it the one you intended? Package names that do not exist are an invitation for someone to register them.
• Test generated code, especially input handling, authentication and anything cryptographic.
• Do not let agent modes run shell commands or install packages without confirmation, and give them least privilege credentials.

How do agents and tool servers change this?

When an assistant can call tools, such as a file system, a ticket tracker or a database, the risk shifts from bad suggestions to bad actions. A poisoned issue comment could ask the agent to read a file and send it somewhere. Limit what each tool can reach, log tool calls, and require approval for anything that writes or sends data.

Where does Safeguard fit?

Safeguard offers IDE extensions for VS Code, Cursor (via Open VSX) and JetBrains, an MCP server, and MCP Guardrail, which applies guardrails to what agents can do through tools. These help apply the dependency and policy checks above at the point where code is written. They supplement a written policy and review practice, they do not replace them.

How to check or apply this

1. Publish a one page policy with three data classes: never, approval needed, fine.
2. Approve specific tools and block unapproved ones on company devices.
3. Collect each provider's data retention and training terms.
4. Add secret scanning in the editor and in pre-commit.
5. Require review, tests and dependency verification on all generated code.
6. Limit agent permissions, log tool calls and review the logs.

Quick check

Sources

• OWASP Top 10 for LLM Applications
• OWASP LLM09:2025 Misinformation
• NIST SP 800-218A, SSDF Community Profile for Generative AI
• NIST SP 800-218, Secure Software Development Framework

Last reviewed: 18 October 2026.