Enterprise AI Security Practices

Enterprise AI security means protecting the models, data, prompts and infrastructure behind your AI features, not just the application code around them. Most of the controls you already run for ordinary software still apply. What changes is that the model itself becomes an attack surface: it can be fed poisoned data, tricked by crafted inputs, or coaxed into leaking what it was trained on.

This post covers the risks that are specific to AI systems, the controls we put in place when we build AI features for clients, and where AI security sits next to the security programme you already have. If you need a governance framework rather than engineering controls, our AI governance and security work starts there.

What does enterprise AI security cover?

It covers six areas: the data used to train and query models, the models themselves, the infrastructure they run on, who can access and change them, the regulations they fall under, and the monitoring that tells you when something is wrong. A gap in any one of them can undo the work done on the others.

• Data: training data, inference inputs and model outputs.
• Models: protection against theft, tampering and adversarial inputs.
• Infrastructure: the compute, storage and network used for training and serving.
• Access control: who can read, modify and deploy a model or its prompts.
• Compliance: obligations under the EU AI Act, the NIST AI RMF and sector rules.
• Monitoring and audit: logs of model behaviour and a trail of who changed what.

How is AI security different from ordinary application security?

Application security looks for flaws in code, configuration and authentication. AI security adds threats that live in data and model behaviour: inputs designed to cause wrong answers, training sets that have been tampered with, and models that reveal sensitive training data when queried the right way. A clean code review won’t catch any of these.

AI security should plug into your existing programme. Route AI events into the same SIEM, use the same incident process, and extend the same access policies to model registries and prompt stores.

What are the main AI security risks?

The risks that come up most in real projects are prompt injection in LLM features, sensitive data leaking through model outputs, and compromised third-party models or libraries. Data poisoning, model extraction and adversarial inputs matter more for teams that train their own models. Insider misuse applies to everyone.

• Prompt injection: text in a user message, a retrieved document or a web page that overrides the instructions you gave an LLM. This is the first thing we test on any agent or RAG feature.
• Data leakage: a model or retrieval layer returning information the user shouldn’t see, often because access rules weren’t applied at retrieval time.
• Supply chain compromise: pre-trained models, datasets or packages with hidden flaws or backdoors.
• Data poisoning: malicious records added to training data to change model behaviour.
• Model extraction: repeated queries used to rebuild a copy of a model.
• Adversarial inputs: crafted inputs that push a model into a wrong prediction.
• Insider misuse: staff or contractors abusing access to models, data or prompts.

Which controls should you put in place first?

Start with governance and an inventory: know which AI systems you run, who owns each one and what data it touches. Then lock down the data pipeline and access to models, add rate limits and logging on model APIs, and test LLM features against prompt injection before launch. Advanced techniques can wait until the basics are done.

1. Set up governance

• Name an owner for every AI system and for AI security overall.
• Write a short policy covering acceptable use, risk assessment and incident response.
• Map your controls to a framework such as the NIST AI RMF or ISO/IEC 42001.

2. Secure the data pipeline

• Restrict access to training and inference data, and apply user permissions at retrieval time in RAG systems.
• Validate incoming data before it reaches a training set.
• Encrypt data at rest and in transit, and record where each dataset came from.

3. Protect the models

• Version and sign model artefacts so you know what is running in production.
• Rate-limit model APIs and alert on unusual query patterns that suggest extraction.
• Test models against adversarial inputs as part of your evaluation suite, not once before launch.
• Consider differential privacy where models are trained on personal data.

4. Harden the infrastructure

• Apply your normal controls: network segmentation, least-privilege IAM, intrusion detection.
• Train sensitive models in isolated environments.
• Watch for unexpected GPU or storage use, which can signal a compromise.

5. Control access

• Use role-based access for AI platforms, model registries and prompt repositories.
• Require multi-factor authentication for anything that can deploy or change a model.
• Log every access and use just-in-time permissions for sensitive operations.

6. Monitor and respond

• Baseline normal model behaviour so drift and anomalies stand out.
• Send AI security events to your SIEM.
• Write playbooks for AI incidents, for example a prompt injection that exposed data.

What gets in the way, and how do teams deal with it?

The usual blockers are a lack of people who understand both AI and security, worry that controls will hurt model quality, and dependence on third-party models nobody has assessed. Each has a practical fix, and none of them needs a large budget to start.

• Skills gap: train your security team on AI-specific threats, or bring in engineers who have built and tested AI features before.
• Security versus model quality: measure the effect of each control in your evaluation suite during development rather than guessing.
• Third-party models: set vendor requirements, assess components before adoption and keep an AI bill of materials.
• New attack techniques: refresh your threat model on a schedule, for example each quarter.
• Older AI systems: rank them by risk, fix the high-risk ones first and plan to retire what can’t be secured.

How do we handle AI security at Dignep?

We’re a software and AI engineering company in Lalitpur, Nepal, certified to ISO/IEC 20000-1:2018 for IT service management. We build security into AI work from the proof of concept onward, because retrofitting it later costs more. Our governance practice works with ISO 27001, SOC 2, the EU AI Act and the NIST AI RMF.

In practice that means access rules applied at retrieval time, prompt injection tests in the evaluation suite, and audit logs from day one, whether the work is an AI agent, a GenAI feature or a security platform. We designed and built Certifyi, an AI SaaS GRC platform, and we built the SayCure SOC platform for CryptoGen Nepal.

A governance or GRC engagement starts with a 2–6 week scoping phase. If you only need a penetration test of a single app, a specialist security firm is a better fit than us.

Frequently asked questions

Related reading: GRC software in practice and lessons from building the SayCure SOC platform. For the full service, see cybersecurity and GRC services.