Securing the AI input channel
Language models now sit inside ordinary products. Every prompt, image, document and voice command they read can carry instructions. SafetyGrid is an open initiative to make that channel governed, testable and evidenced under the EU Cyber Resilience Act, with controls any manufacturer can afford.
Aligned with MITRE ATLAS and the OWASP Top 10 for LLM Applications. SafetyGrid adds no new taxonomy. It connects the ones that exist to the CRA.
The multimodal attack grid
Select an attack class to see where it enters, how it is controlled and which CRA requirement it supports.
| Attack class | Text | Image | Document | Audio | Tools |
|---|
Why the CRA needs to see the AI layer
- Models do not separate data from instructionsAnything a model reads can steer it, whether typed by the user, hidden in a web page, or written in white text on an image.
- Injection becomes actionIn agents with email, payments, files or equipment, one injected instruction can trigger an outcome that is fast, severe and irreversible. Detection has to be paired with containment.
- Encryption hides the contentModel traffic travels over TLS, so the network sees timing and destinations, never the prompt. Inspection must happen on the device before encryption, with network enforcement so it cannot be bypassed.
- Protection is priced for enterprisesCommercial AI security platforms are licensed for large organisations and often inspect content in the cloud. SMEs carry the same CRA obligations without an affordable route.
- The standards are being written nowHarmonised standards under Standardisation Request M/606 do not yet treat the LLM input channel specifically. The CRA applies in full from 11 December 2027.
The AI input channel of every product with digital elements should be governed, testable and evidenced, protected by open controls that any manufacturer can run on commodity hardware.
Ten principles
Everything SafetyGrid produces, from standard text to reference code, is held to these.
- Interoperability over inventionReference MITRE ATLAS and OWASP. Never a competing taxonomy or numbering scheme.
- Enforceability by designA control that can be silently bypassed is not a control. Specify what an assessor can verify.
- Inspection where content existsOn the device before encryption. Transport security is never weakened to inspect.
- Multimodal by defaultText, images, documents and audio are equal carriers of instructions.
- Containment as well as detectionLeast privilege, confirmation outside the model and a safe stop for high-impact actions.
- Affordable and hardware-neutralEvery requirement achievable on entry-level, interchangeable hardware without enterprise licences.
- Resilient offlineSigned, locally stored detection updates keep protection working on ships, remote sites and air-gapped networks.
- Private by architectureInspection runs locally. User content is not sent to third parties for analysis.
- OpenSpecifications, schemas, data and reference code under open licences.
- Neutral and proportionateOutcome-based contributions. Reference implementations prove feasibility; they are never the standard.
Inspect before encryption. Enforce at the edge.
The reference concept shows that the principles work on low-cost hardware. It validates the approach; any implementation that achieves the same outcomes is equally valid.
Endpoint inspection agent
A lightweight agent on the device intercepts model-bound traffic at a local point under the owner's control, before encryption. It inspects prompts, attachments, images and audio, and checks model outputs on the way back. Detection combines registry signatures, heuristics and small classifiers. On a match it blocks, sanitises, warns or logs, and it defends itself against tampering.
Edge enforcement
An entry-level appliance, or the same function in an existing firewall, allows traffic to model endpoints only from an inspected path. It works on encrypted traffic using destinations, name resolution and client authentication issued by the agent. This closes the bypass through alternative clients or a disabled agent.
Signed, offline-capable updates
Detection content comes from the registry as signed bundles, verified on receipt and kept in a local store. Protection continues on vessels, remote sites and air-gapped networks. Updating a bundle is handled as a security update in the sense of the CRA.
Evidence for conformity
Every decision, enforcement event, signature version change and tamper alert is written to a structured event schema. That is the monitoring the CRA expects, and the proof a manufacturer needs after an incident or during assessment.
From detection to containment
No detector catches everything. Severe outcomes are prevented by limiting what an injected instruction can reach.
Pathway into European standardisation
| Body | Instrument | Intended input |
|---|---|---|
| ETSI TC CYBER | CRA harmonised standards under M/606 | Threat characterisation, control and test considerations, and AI-layer vulnerability handling. Primary target. |
| ETSI TC SAI | Securing AI baseline requirements | Liaison to keep threat characterisation and controls aligned. |
| CEN-CENELEC JTC 13 | Horizontal CRA standards | Liaison on handling AI-layer attack vectors within vulnerability handling. |
| CEN-CENELEC JTC 21 | AI Act standards under M/593 | Consistency with cybersecurity and robustness requirements for AI systems. |
Scope
In scope
- The LLM input channel as an attack surface: direct, indirect and multimodal injection, tool hijacking and exfiltration
- Architecture-neutral control and test considerations
- Vulnerability handling for AI-layer attack vectors, including offline update distribution
- An evidence schema for monitoring and conformity assessment
- Open reference code, schemas and datasets on commodity hardware
- Standardisation contributions, workshops and SME outreach
Out of scope
- A commercial product, or any vendor proposed as a standard
- A new taxonomy competing with ATLAS or OWASP
- Publishing offensive tooling or weaponised jailbreak payloads
- Training, alignment and internal safety of foundation models
- Moderating lawful content or monitoring users beyond security
- Certification itself, which remains with manufacturers and notified bodies
An open registry for AI attack vectors
CVE entries describe flaws in code. Many AI attacks are techniques that work against a whole class of models, and the fix is often a new detection signature rather than a patch. The registry fits these vectors into the vulnerability handling the CRA already requires, instead of building a parallel system.
What a record holds
Each record describes one attack vector: how to recognise it, what it can damage, how to stop it, and where it sits in the taxonomies practitioners already use. Records reference CVE and CWE entries where they exist.
Records describe indicators and detection. They never publish working attack payloads.
The record on the right is illustrative. The schema is in draft and will be published for comment.
# illustrative draft record id: SG-2026-0001 title: Low-contrast text instructions in images vector_class: indirect-injection modalities: [image, document] mappings: mitre_atlas: [AML.T0051.001] owasp_llm: [LLM01:2025] cve: [] preconditions: - product passes user images to a vision model indicators: - text regions near background luminance - imperative phrasing in extracted text impact: [integrity, confidentiality] cra_annex_i: [I(2)(f), I(2)(j)] detection: bundle: sg-sig-2026.10 actions: [strip-region, log] disclosure: public status: draft
Mapped to the taxonomies you already use
Indicative mappings for the main attack classes. They will be validated with the community before the first release.
| Attack class | MITRE ATLAS | OWASP LLM Top 10 (2025) |
|---|---|---|
| Direct injection | AML.T0051.000 LLM Prompt Injection: Direct | LLM01 Prompt Injection |
| Jailbreak | AML.T0054 LLM Jailbreak | LLM01 Prompt Injection |
| Indirect and multimodal injection | AML.T0051.001 LLM Prompt Injection: Indirect | LLM01 Prompt Injection |
| Tool and agent hijacking | AML.T0053 LLM Plugin Compromise | LLM06 Excessive Agency |
| Data exfiltration | AML.T0057 LLM Data Leakage | LLM02 Sensitive Information Disclosure |
| Unsafe output use | AML.T0051 (downstream effect) | LLM05 Improper Output Handling |
How a vector enters the registry
Curation is what makes a registry credible. Governance is designed to move from the founder to a neutral community group as adoption grows.
- SubmitResearchers, vendors and users report a vector privately, with evidence.
- TriageReviewers check novelty, map it to ATLAS and OWASP, and contact affected vendors.
- Validate and scoreThe vector is reproduced in a controlled setting and its impact assessed.
- Coordinated disclosureAffected parties get time to respond before the record is public.
- Publish and distributeThe record is released and detection content ships in the next signed bundle.
- MaintainRecords are versioned, revised and deprecated as the landscape changes.
Tools you will be able to use
Code under Apache 2.0. Specifications, schemas, data and documentation under CC BY 4.0. Releases archived on Zenodo.
Commitments to 2029
The work follows the CRA timeline: standards drafted now, full application from 11 December 2027, revision as experience accumulates. Standardisation dates follow working group schedules.
Q4 2026
Manifesto published. Gap analysis of M/606 drafts against LLM threats. Target work items confirmed with ETSI TC CYBER. Draft registry schema released for comment.
2027
Three contributions submitted to TC CYBER, with liaison to TC SAI and JTC 13. Reference concept validated across commercial and open models. Agent, edge profiles, seed data and test corpus released. SME workshops in Athens with the University of Piraeus and at the Stavros Niarchos Foundation Cultural Center.
2028
Comment resolution and follow-up contributions. Registry governance formalised with an open review group. Annual public release of records, signatures and test corpus.
2029
Lessons from the first period of CRA application turned into revision inputs. Registry and tools maintained. Governance transferred to a neutral host if adoption warrants it.
What we commit to
- Sustained standards participationActive ETSI CRA work, with membership funded independently of any grant.
- Open by licenceSpecifications, schemas, data and code published openly and kept available at least until the end of 2029.
- Vendor neutralityEvery standards contribution free of commercial interest and of any named product.
- Honest reportingLimitations and negative results published, including where detection falls short.
- New contributorsBringing new people into European standardisation through mentoring in the StandICT.eu 2029 programme.
Who benefits
Standardisation community
Neutral, validated input on the fastest-growing product category, mapped to known taxonomies, with an open schema to test during comment periods.
Manufacturers and SMEs
A realistic route to conformity for the AI layer: clear expectations, entry-level hardware, no licence cost, no cloud inspection of customer content.
Assessors and authorities
Test considerations, reference cases and an evidence schema to ask, and verify, whether the AI input channel is controlled.
Researchers
A place to document AI attack vectors under responsible disclosure and see them turned into deployed detection.
People using AI products
Protection against manipulation of the tools they rely on, implemented locally and respecting the confidentiality of their content.
Help write the controls
SafetyGrid only works if others test, criticise and adopt what it produces. Standards experts, manufacturers, SMEs, researchers, test laboratories, notified bodies and universities are all invited.
Review draft contributions
Comment on the threat characterisation, control considerations and vulnerability-handling profile before they reach TC CYBER.
Test the schema and tools
Apply the record and event schemas to your products and tell us where they break.
Report attack vectors
Submit vectors privately for coordinated disclosure. Credit is given in the published record.
Host or join a workshop
Bring SMEs and standardisation people together to try the controls on real products.
Read the manifesto
The full text sets out the problem, vision, principles, reference concept, scope, standardisation pathway and roadmap. It is deposited on Zenodo with a persistent identifier under CC BY 4.0.
Sampokilis, P. (2026). Securing the AI Input Channel: Open, enforceable and affordable controls against prompt injection and multimodal attacks on LLM-integrated products, as an enabler for the EU Cyber Resilience Act (Version 1.0). Zenodo. https://doi.org/10.5281/zenodo.[reserved DOI]
Get involved
Write with your area of interest and how you would like to take part. Vulnerability reports should be marked as such in the subject line.
Email panos@cognitycc.com