Artificial intelligence is now part of daily work in many enterprises. Copilots draft emails, agents trigger workflows, and systems answer questions using internal documents. Each of these applications brings value. But each also opens a new path that an attacker can exploit.
Artificial intelligence security is the discipline that protects AI systems and the data behind them. It is part of the broader field of cyber risk management, and it matters for a simple reason: when AI fails or is abused, the result can be data theft, a system compromise, or a decision that harms people Meanwhile, the controls most companies already run were not designed for these new risks.
This guide explains how AI changes the risks enterprises face and what to do about it. You will find a short history of how AI attacks, 10 AI security best practices, an overview of the NIST AI Risk Management Framework, and a look at how NordLayer supports secure AI adoption.
How AI attacks have changed
Early concerns about AI centered on models that provided incorrect answers or produced biased text. The picture in 2026 is broader. Now, when a model can call tools, pass parameters into code, and read external content, a manipulated prompt can become a system compromise.
Recent disclosures tell us that:
- Prompt injection can reach the host. Microsoft research published in May 2026 documented how prompt injection in AI agent frameworks could escalate to host-level remote code execution. In a framework where the agent can run code or call tools, a hostile prompt can hand an attacker control of the machine.
- A webpage can compromise the agent’s host. A separate Microsoft exploit chain called AutoJack published in June 2026, showed how a single malicious webpage, once read by an AI browsing agent, could reach local services on the host and run code on it. Therefore, the local machine is not a safe zone, and content that an agent reads from the open web can become a direct route in.
- One click can leak company data. In June 2026, Varonis disclosed SearchLeak a patched, one-click data-theft attack against Microsoft 365 Copilot Enterprise Search (CVE-2026-42824, rated critical). It chained a prompt injection through a URL parameter with an HTML rendering flaw and a server-side request that pulled data out through an allowed domain. Because the link pointed to a trusted Microsoft address, standard anti-phishing tools did not block it. The lesson learned is that a model with access to a user’s mailbox, calendar, and files can be turned into an exfiltration tool with a single click, and output safeguards that run too late do not help.
- AI gateways are now targeted directly. CISA added a LiteLLM proxy vulnerability to its Known Exploited Vulnerabilities catalog after evidence of active exploitation. This was one of the clearest signals that AI gateways and proxy layers—the infrastructure that routes calls to models—are now part of the enterprise attack surface in their own right. It matters because attackers do not need a flawed model to succeed; they can target the infrastructure around it. AI gateways are part of the attack surface even when the model itself is sound.
Attackers also use AI as a tool. Reports from Microsoft, OpenAI, and Google Threat Intelligence found that observed threat actors mostly used AI as a productivity aid for research, coding help, and reconnaissance, without highly novel attack techniques. Mandiant meanwhile, reported that generative AI is already raising attacker output across phishing, coding, and other stages of an attack. NordStellar research adds an example: in the first 5 months of 2026, dark web discussions of deepfake-as-a-service already exceeded the full 2025 total by 39% The firm links this increase to a new wave of business email compromise attacks that use AI-generated voice and video to impersonate executives.
So, cybersecurity trends point to 2 main problems:
- AI raises attacker speed, scale, and personalization.
- Enterprise AI adoption creates new attack surfaces.
10 AI security best practices for businesses
The practices are drawn from guidance by NIST, CISA, the NSA, the NCSC, OWASP, Microsoft, and Google. They apply whether you are building models, fine-tuning them, or simply buying AI features from a vendor. No single control stops every attack, so it is better to treat these practices as a layered set.
1. Build and maintain an AI inventory
This always comes first because every other control depends on knowing which AI systems exist and who is responsible for them. A risk classification, an access policy, or a monitoring rule cannot be applied to a system that no one has recorded.
Record every approved and unapproved AI use across the company: internal copilots (e.g., a support assistant built on your help-desk data), SaaS AI tools, model endpoints (e.g., hosted OpenAI or Azure OpenAI API), retrieval systems (e.g., systems that answer questions from internal wikis), agents, plugins, datasets, vector databases (e.g., stores that hold embeddings for retrieval), and fine-tuned models.
Microsoft recommends getting visibility into both AI workloads being built in the organization and SaaS generative AI apps being used by employees. No AI system, including AI features inside tools you already pay for, should run in production without an inventory entry, an owner, a data classification, a model source, an access model, a logging plan, and a risk tier.
2. Decide the rules before you scale AI use
Set clear rules early so that AI use stays within limits as it grows across the company. Decide which AI uses are allowed, which data types may be used, who approves high-risk cases, and who accepts the residual risk (the risk that remains after controls are applied and signed off on by a named senior owner).
The NIST AI RMF Govern function is a strong reference point, and ISO/IEC 42001 offers a management system standard for organizations that provide or use AI. Google’s Secure AI Framework also suggests forming a cross-functional team and aligning stakeholders before the technology spreads across the business.
3. Classify AI systems by risk
Though not without risk, a summarization tool that reads public text carries far less risk than an agent that can reach production systems or process regulated records.
Assign a risk tier to each system and match controls to that tier. Teams selling or operating in the EU should note that the EU AI Act will be fully enforced starting August 2, 2026, though some prohibited practices will be enforced earlier. The Act defines high-risk systems as AI used in areas such as hiring, credit, education, healthcare, and access to essential services. These systems must meet requirements such as risk mitigation, high-quality datasets, clear user information, and human oversight.
4. Secure the AI data lifecycle
Enterprise AI, whether a copilot, a retrieval system, or a fine-tuned model, depends on data at every stage. The CISA, NSA, and FBI AI Data Security guidance recommends controls across development, testing, and operation. These controls include encryption, digital signatures, data provenance, and secure storage.
In practice, data and security teams can classify data before it reaches an AI tool, block restricted data from unapproved tools, apply data loss prevention to prompts and outputs, and verify the sources fed into models. Together, these steps lower 2 risks at once: malicious data entering your pipeline and sensitive data leaving it.
5. Secure model development and machine learning operations (MLOps)
If your teams build or fine-tune machine learning models, the pipeline itself needs protection.
NIST SP 800-218A a 2024 companion to the Secure Software Development Framework, gives direction for generative AI In short, it tells the teams that build models to treat training data, model weights, and incoming queries as potential sources of compromise, because an attacker can poison a dataset, tamper with weights, or smuggle instructions through a query.
To act on that, development teams can use approved model registries, sign their artifacts, restrict access to model weights, separate development from production, and add evaluation gates and rollback plans before a model ships.
The joint AI and machine learning supply-chain guidance supports checksums, digital signatures, and provenance tracking throughout. In reality, this means a team can verify that a model or dataset has not been altered before they use it, and trace where it came from, so a tampered component is caught before it reaches production.
6. Apply least privilege to AI systems and agents
Each AI app and agent should have only the access the task requires. Microsoft recommends managed identities over static API keys, private endpoints, role-based access control, and secure compute without public IP addresses.
For example, a finance copilot that only needs to read invoices should not hold write access to the payment system, and a connection to a model endpoint should run over a private network rather than the open internet.
For tools that simply add AI features to software you already use, the same logic applies: grant the feature the minimum permissions, and turn off the parts you do not need.
Agents need tighter limits still. The team that deploys an agent should allowlist the tools it may call, grant short-lived permissions, sandbox its actions, and require human review for high-impact steps. The NSA agentic AI guidance recommends incremental deployment, strong governance, explicit accountability, and human oversight. This means, for example:
- Rolling an agent out to a small scope first.
- Naming a person who is accountable for its actions.
- Keeping a human in the approval path for anything sensitive before you widen its reach.
This is also where zero-trust architecture proves its worth: verify every request, grant minimal access, and assume no component is inherently trusted, not even prompts and outputs.
7. Treat prompts and outputs as untrusted
A system prompt can guide how a model behaves, but it is only an instruction that the model may or may not follow. It is not a barrier tjat an attacker has to break, so it cannot replace authentication, authorization, isolation, validation, or human approval of any action the model triggers.
The reason is prompt injection Prompt injection happens when a user or an external source pushes the model to follow hostile instructions, and the indirect form hides those instructions in a webpage, email, document, or tool output that the model reads. The AutoJack and SearchLeak cases above are real examples of this.
Microsoft recommends defense in depth, with several controls layered together:
- Prompt shields (filters that detect and block known injection patterns)
- Data marking (tags that help the model tell trusted instructions from untrusted content)
- Plan-drift detection (alerts when an agent’s actions stray from its intended plan)
- Tool-chain analysis (review of which tools an agent calls and why)
- Human-in-the-loop controls
On the output side, treat every model response as untrusted. Validate it before it reaches a database, a shell, an email tool, a ticketing system, or a customer. It means checking the output against expected formats and rules and stripping anything that could execute or trigger an action rather than passing it straight through.
8. Add AI-specific monitoring and detection
Standard logging can miss AI behavior. The security and platform teams should monitor prompts, outputs, tool calls, API calls, retrieval activity, file access, sensitive-data exposure, policy violations, cost spikes, and agent actions.
Useful log fields include the user, the app, the model, the data source, the documents retrieved, the tools called, the actions taken, the output destination, the safety filter result, token usage, and the human approval status.
9. Red team and test AI systems before and after every major change
Test your AI the way an attacker would. Red teaming should probe prompt injection, data exfiltration jailbreaks, unsafe tool use, retrieval manipulation, and abuse of agent workflows. Microsoft reports that it has red-teamed more than 100 generative AI products and recommends incorporating red teaming into your CI/CD pipeline early on.
For threat modeling, MITRE ATLAS is a strong reference, since it documents real adversary tactics and techniques against AI-enabled systems. Run these tests before launch and again after any major model, data, or tool change.
10. Manage third-party AI and supply-chain risk
Apply real due diligence to third-party AI tools, especially those that handle confidential data or connect to your systems. When evaluating a vendor, your procurement, security, and legal teams should ask the supplier direct questions:
- Does the vendor train on customer data?
- Where is the data stored, and for how long?
- Are prompts and outputs logged?
- Are model artifacts signed?
- Can you use single sign-on, customer-managed keys, private networking, and data loss prevention?
NIST AI Risk Management Framework
The NIST AI RMF deserves its own section because it gives the practices above a common structure, so they form one program rather than a list of disconnected controls.
The NIST AI RMF is voluntary and built to work in any industry, and it applies to any organization that designs, develops, deploys, or uses AI. Its Core has 4 functions: Govern Map Measure and Manage Govern sets policy and accountability, Map identifies context and risk, Measure assesses and tracks risk, and Manage acts on it.
NIST also defines characteristics of trustworthy AI, which matter because they give teams a shared, testable definition of “good enough” to aim for: validity, reliability, safety, security, resilience, accountability, transparency, privacy, and bias management.
Its generative AI profile lists risk categories such as data privacy, information integrity, information security, confabulation, and supply-chain risk. The list is helpful because it names the specific failures a generative AI review should look for.
For a security program, the security team can pair the AI RMF with the NIST Cybersecurity Framework 2.0 whose Govern Identify Protect Detect Respond and Recover functions connect AI security back to your existing cyber risk management.
NIST SP 800-218A, the secure AI software development guidance first published in 2024, then extends secure development practices to generative AI. Used together, these frameworks let a company handle AI security inside the security program it already runs rather than creating a separate one from scratch.
How NordLayer helps businesses adopt AI securely
Several of the practices above map directly to NordLayer controls. In short, NordLayer helps with securing the AI data lifecycle, least privilege and zero trust, and parts of practices 1 and 7 (visibility and untrusted external content).
- NordLayer Browser supports the data lifecycle practice by controlling what users can paste or upload into external AI tools, which reduces the chance that sensitive data leaks into public large language models.
- Zero-trust network access solutions support least privilege by making sure only authorized staff reach internal AI development environments, applying zero-trust architecture to your model pipelines and agent infrastructure.
- DNS filtering supports both visibility and the rule that external content is untrusted by blocking access to malicious AI domains and known bad endpoints before a user or an agent ever connects.
Putting AI security into practice
AI security is cyber risk management applied to a new class of systems. The companies that handle it well do a few consistent things: they inventory their AI systems, set the rules before it scales, classify each system by risk, and treat prompts and outputs as untrusted.
Pair AI security best practices with the NIST framework and zero-trust controls and your organization can adopt AI on a sound footing. The same discipline also helps when you start using AI in cybersecurity yourself, since the tools you defend with deserve the same level of scrutiny as the ones you defend against