As AI systems rapidly integrate into critical infrastructure and enterprise workflows, their attack surfaces are expanding just as quickly. Consequently, traditional cybersecurity controls are no longer sufficient.
To address this growing risk, the new ETSI TS 104 223 V1.1.1 (2025-04) — Securing Artificial Intelligence (SAI); Baseline Cyber Security Requirements for AI Models and Systems — establishes a comprehensive baseline for securing AI systems across their entire lifecycle, from initial design to end-of-life. In this article, we highlight 10 of its most strategic insights, translating them into actionable lessons that every CISO, technical leader, and engineering team should adopt to stay ahead of emerging AI threats.
1. Build AI Security Awareness into Engineering and Operations
“If your engineers don’t know what data-poisoning looks like, you already have an incident brewing.” #CISO #ETSI104223
To start, the spec introduces Principle 1: build formal AI-security training and regular threat-intel updates into your team’s routine. AI attacks evolve quickly. Therefore, annual or even monthly refreshers are often not enough.
How to apply
- For example, create a monthly lunch-and-learn on topics like prompt injection or model inversion. Rotate presenters to keep interest high.
- In addition, subscribe your Slack #sec-ai channel to ENISA RSS feeds. This will help auto-post CVEs tagged with “AI”. You can also search for news on AI security regularly.
- To further embed awareness, add a sprint-exit checklist item: “demo one new AI threat or mitigation.”
- As an illustration, you could run a red-team exercise focused on a specific attack type. Then, publish the lessons learned in a wiki-style format.
2. Implement Secure-by-Default Design in AI Systems
“An AI system that passes pen-testing but fails threat-modeling is a zero-day waiting to happen.”
Next, Principle 2 urges you to prioritize security from the start. Don’t wait until deployment. Instead, consider security alongside accuracy or latency at the blueprint phase. This includes adversarial-robust architectures, minimal permissions, and auditable data flows.
How to apply
- To begin, kick off every new model with a STRIDE session tailored for AI. Record all mitigations as GitHub issues.
- Also, treat vector DB access keys just like production DB secrets. Store them in Vault and rotate quarterly.
3. Continuously Threat-Model AI Systems Across the Lifecycle
“Your model’s threat landscape refreshes every time its weights do.”
In addition, Principle 3 highlights the need for ongoing threat modeling. You must review threats continuously across the AI lifecycle. This includes data poisoning during training, model extraction at inference, and prompt injection in production.
How to apply
- To automate this, run a “risk diff” check each time you change a hyperparameter or data source.
- Moreover, version and archive all threat models in the same repository. This allows auditors to track changes easily.
- As a best practice, integrate the MITRE ATLAS matrix into your security-as-code pipeline. Then, block merges if any new tactic lacks a control.
4. Ensure Human Oversight and Explainability in AI Decisions
“Explainability isn’t a luxury; it’s your last line of legal defense.”
Similarly, Principle 4 requires you to build in human oversight and explainability. This helps operators review or veto AI outputs when needed.
How to apply
- For example, surface SHAP values or attention heat maps in internal dashboards. Focus on high-impact predictions.
- Require dual control for critical actions. For instance, a model should not commit code or wire money without human sign-off.
- Another useful tactic is to add a Guardrails policy. It could block any response containing “DELETE *” until reviewed by an analyst.
5. Track All AI Assets: Models, Prompts, and Dependencies
“If it’s not in your asset inventory, it’s in somebody else’s shopping cart.”
Additionally, Principle 5 stresses the importance of a real-time inventory. Track all models, datasets, prompts, and dependencies. Use version control and plan for disaster recovery.
How to apply
- To start, maintain an SBOM (software bill of materials) for AI. Hash all model binaries, training snapshots, and prompt templates.
- Store lineage metadata in a graph database. This way, you can query questions like “Which fine-tuned models used dataset X?” in seconds.
- As an example, set up a GitHub Action. On every push, it updates
/assets.yml
and bumps a version tag when system_prompt.txt
changes.
6. Harden and Segment AI Infrastructure to Limit Exposure
“Your LLM sandbox should never see prod secrets—treat it like a hostile DMZ.”
Furthermore, Principle 6 urges you to apply least-privilege access and segment your environments. Separate dev, fine-tune, and production systems. Use tight API rate limits. Publish a clear vulnerability disclosure policy.
How to apply
- For instance, use different AWS accounts (or GCP projects) for training and inference.
- Enforce mTLS (mutual TLS) between all microservices.
- Also, expose your model API through a WAF like Cloudflare. Block any IP that sends more than 50 requests per minute to slow down extraction attempts.
7. Validate the AI Supply Chain, Including Pre-Trained Models
“An unverified checkpoint is the new log4j: cheap, popular, and weaponizable.”
Likewise, Principle 7 emphasizes the need to secure your AI supply chain. Evaluate all third-party models and components. Require SBOMs, perform risk assessments, and recheck regularly.
How to apply
- Verify cryptographic hashes of all downloaded weights. If there is a mismatch, fail the build.
- Additionally, for each dependency, list CVE status and licensing in a file like
third_party.md
.
8. Document AI Systems Thoroughly for Security and Audits
“If your audit trail fits on a slide, expect your fines to fill a ledger.”
Moreover, Principle 8 treats documentation as a security control. Document data sources, failure modes, guardrails, and all changes. In other words, every step in your AI system’s lifecycle should leave a traceable record. As a result, strong documentation not only improves security posture but also serves as your first line of legal protection.
How to apply
- Auto-generate a model card after each training run. This ensures consistent documentation.
- Log all prompt edits using Git commit hooks. Include author and ticket ID.
- For added traceability, tag each data source with a URL and timestamp. This helps trace back any poisoning attempts.
9. Conduct AI Red Teaming Before Every Major Release
“No AI red-team, no release—make it a sacred gate.”
Similarly, Principle 9 requires you to test like an attacker. Conduct red teaming before releasing and after major updates. Share results downstream to stakeholders.
How to apply
- To integrate this, add AI red teaming suites into your CI pipeline.
- Also, contract external testers. Ask them to simulate jailbreaks, model inversion, and extraction.
- As a rule, fail the build if jailbreak success exceeds 5% across your test prompt corpus.
10. Enable Real-Time Monitoring of AI Behavior and Drift
“The model you deploy at 9 a.m. is not the model you have at 5 p.m.—log or lose.”
Finally, Principle 10 highlights why real-time monitoring matters. Log both system and user actions. Also, keep an eye out for strange patterns or drift. In addition, monitor how models behave under changing conditions, as subtle shifts can signal deeper security issues.
How to apply
- Stream inference logs to a SIEM. Attach metadata such as user ID, prompt, response ID, and latency.
- In addition, run a Canary Prompt every hour. Set alerts if outputs deviate from the baseline.
- For example, build a Grafana dashboard to monitor toxic language scores. If there’s a spike, trigger PagerDuty.
Final Word
In summary, ETSI TS 104 223 is much more than a checklist. It offers a clear, actionable blueprint for securing AI systems across their full lifecycle. From design and development to deployment and retirement, each of the ten principles provides essential guidance. Whether you’re building AI tools in a lean startup or managing critical infrastructure in a regulated enterprise, these lessons help you stay ahead of evolving threats.
By applying them, you move from reactive firefighting to proactive defense. As a result, you reduce risks, simplify audits, and increase trust across your AI ecosystem. Most importantly, you avoid learning hard lessons from real-world incidents—because you prepared before they happened.
To go even further, consider using platforms like the Adversa AI Red Teaming Platform. It helps continuously test, monitor, and strengthen your AI systems against advanced threats. This way, you can embed resilience at every stage and prove compliance with evolving security standards.
Want to stay ahead in this fast-moving space?
Subscribe for updates
Stay up to date with what is happening! Get a first look at news, noteworthy research and worst attacks on AI delivered right in your inbox.