AI security: use AI you can trust
From language models to autonomous agents and AI perception: we secure the AI in your products and operations, so you can use it where it creates value without losing control.
AI changes what you have to protect
Products and operations now contain models that read documents, see the road, write code and act on their own through tools. An AI component does not only process data; it takes decisions and, in agentic systems, triggers actions. That turns its inputs, its training data, its model files and its permissions into attack surface.
Classic security controls do not see these attacks. A prompt hidden in a PDF, a poisoned training set or a manipulated model file looks like normal content until the system misbehaves. AI security closes that gap: it applies threat analysis, secure architecture, testing and monitoring to the AI itself, so you can use AI where it creates value without losing control.
Who it is for
- Manufacturers adding AI to products, from perception to voice and diagnostics
- Teams deploying AI agents and copilots in engineering, service or operations
- Providers and users of high-risk AI systems under the EU AI Act
- Security and compliance leads who must sign off AI before go-live
The new attack surface
Eight risk areas we assess in every AI-enabled product or workflow. They follow the threat catalogues of MITRE ATLAS, the OWASP Top 10 for LLM Applications and the NIST taxonomy of adversarial machine learning.
Inputs
Prompt injection
Instructions hidden in user input, e-mails, web pages or documents take over the model. Indirect injection needs no access to the system at all, only to the content it reads.
Agents
Excessive agency
Agents with broad tool access can be steered into deleting data, sending messages or changing configurations. The risk grows with every tool and connector they get.
Data
Data and model poisoning
Manipulated training or fine-tuning data plants hidden behaviour, such as backdoors that trigger on a specific input.
Supply chain
Untrusted models and components
Pre-trained models, datasets, plugins and tool servers come from third parties. Model files can carry executable code; provenance is often unknown.
Confidentiality
Data leakage and model theft
Models can reveal training data, system prompts or connected documents, and repeated queries can copy a model's behaviour.
Perception
Adversarial inputs
Small, targeted changes to images, signals or sensor data make vision and detection models see something that is not there, or miss what is.
Outputs
Insecure output handling
Model output passed unchecked into code, commands, queries or user interfaces becomes an injection path into the rest of the system.
Operation
Drift and abuse at runtime
Behaviour changes with new data, new model versions and misuse. Without monitoring, nobody notices until an incident happens.
Six principles for enabling AI securely
Security should make AI usable, not block it. These principles let your teams move fast while risk stays under control.
1
Secure by design
AI components are part of the threat analysis from the first architecture sketch, with clear trust boundaries around every model.
2
Least privilege for agents
Agents get only the tools and data they need, with human approval for actions that cannot be undone.
3
Trusted supply chain
Every model, dataset and connector has a known origin, a version and a place in the AI bill of materials.
4
Test like an attacker
Red teaming with injection, jailbreak, extraction and adversarial techniques before release and after every model change.
5
Monitor at runtime
Inputs, outputs and agent actions are logged and checked, so misuse and drift are detected and can be reported.
6
Govern and prove
Roles, rules and documentation that satisfy the EU AI Act, the CRA and ISO/IEC 42001 with one set of evidence.
How we help
From the first design decision to operation. Each service has a clear scope and a defined result.
AI threat modelling
Know how your AI could be attacked before it ships.
What we do
- Map models, data flows, tools and trust boundaries
- Analyse threats with MITRE ATLAS and OWASP, rated for impact and feasibility
- Link AI risks into your product TARA or IEC 62443 risk assessment
You receive
AI threat model, risk ratings, security requirements
Secure architecture for agents and LLM applications
Guardrails that hold under pressure.
What we do
- Permission design, tool allowlists and sandboxing for agents
- Input and output filtering, isolation of untrusted content
- Human approval steps for critical actions, secrets handling
You receive
Reference architecture, design review, requirement set
AI supply chain security
Know what is inside your AI.
What we do
- Assess pre-trained models, datasets, plugins and tool servers
- Check model file formats, provenance and signing
- Build and maintain an AI bill of materials alongside your SBOM
You receive
Supplier and component assessment, AI-BOM, acceptance criteria
AI red teaming and adversarial testing
Attacks we run so others cannot.
What we do
- Direct and indirect prompt injection, jailbreaks, data exfiltration through agents
- Model extraction and training data leakage tests
- Adversarial inputs against vision and sensor models
You receive
Test report with findings, severity and fixes; retest after changes
Runtime monitoring and AI incident response
Stay in control after go-live.
What we do
- Define logging for prompts, outputs and agent actions
- Detection rules for misuse, drift and anomalies
- Incident playbooks that connect to CRA reporting where products are affected
You receive
Monitoring concept, detection rules, response playbook
AI governance and compliance
One framework for regulation and audits.
What we do
- Classify your AI systems under the EU AI Act
- Map obligations to the CRA and to ISO/IEC 42001
- Policies for safe use of AI tools with code and confidential data
You receive
Classification, obligation map, AI policy set
How we work
Step 1
Discover
Where AI is used, what it can read and what it can do.
Step 2
Analyse
Threat model across models, data, tools and people.
Step 3
Harden and test
Architecture measures, then red teaming against them.
Step 4
Operate
Monitoring, response and evidence for audits.
Standards and frameworks
ISO/IEC 27090
The new international standard for AI security: guidance on understanding, detecting and mitigating security threats to AI systems across their life cycle, from training data to models. It complements ISO/IEC 27001 and 27002 and is in its final publication stage in October 2026. We already align our AI threat modelling and testing with it.
EU AI Act
Article 15 requires accuracy, robustness and cybersecurity for high-risk AI systems, including resilience against data poisoning, adversarial examples and model flaws.
Cyber Resilience Act, Article 12
High-risk AI systems that are also products with digital elements can show AI Act cybersecurity compliance by meeting the CRA essential requirements.
ISO/IEC 42001
Management system for artificial intelligence: roles, risk assessment and controls across the AI lifecycle.
ISO/PAS 8800
Safety and artificial intelligence in road vehicles, relevant where AI perception supports driving functions.
ETSI TS 104 223
Baseline cybersecurity requirements for AI models and systems.
MITRE ATLAS and NIST AI 100-2
Catalogue of real attack techniques against AI, and the reference taxonomy of adversarial machine learning.
OWASP Top 10 for LLM Applications
The most common risks of language model and agent applications, used as a test baseline.
Industries
AI perception in vehicles and machines, AI diagnostics in medical devices, AI agents in plants and grids: the risks differ, the method stays the same.
We secure AI because we build with it
AITIGRITY uses AI to generate threat analyses, requirements and tests. It runs on your own servers, keeps your data inside your trust zone and lets you swap the language model. We apply the same principles to your AI that we apply to our own.
See the platformQuestions we often hear
Does the EU AI Act apply to us?
It depends on what your AI does and where it is used. We classify each system, then map the obligations, including where the CRA already covers the cybersecurity part.
Is AI security different from normal product security?
The method is the same: analyse, design, test, monitor. The attacks are new, and so are the components, such as models, datasets and agents. We add these to your existing process instead of building a parallel one.
Can you test AI systems we bought, not built?
Yes. Most AI risk sits in how a model is integrated: what it can read, what it can do and how its output is used. We test the integration, with or without access to the model itself.
How do agents change the risk?
An agent can act, not only answer. A successful prompt injection then becomes an action in your systems. That is why permissions, approval steps and monitoring matter more than the model choice.
Where does your product stand?
Tell us about your product and the rule you are facing. You talk to an engineer from the first call.
Cybersecurity consulting and the AITIGRITY platform for connected products and industrial systems.