Submitted by: [name], member, Security, Trust and Privacy Working Group Date: 26 August 2026 (working version) Against: Working draft MTSFB2510R0, Artificial Intelligence - Cybersecurity Requirements for Telecommunication and Multimedia Sector
The draft establishes a sound structure: the AISCF alignment, the three-asset model, the licence-category context and the 42-activity mapping give the Working Group a complete skeleton to build on. These comments propose amendments in three areas that would benefit from settling first: the normative posture of the code, governance and accountability roles, and AI criticality as the proportionality mechanism. Nine further recommendations and the supporting drafting text follow. Proposed text is offered in ISO verbal forms (shall, should, may) for the Working Group to adopt, adapt or reject.
GOVERNANCER1. Make the requirements assessable. The code is titled Requirements and registration under section 95 gives licensees a compliance defence under section 98. That defence is strongest when the code states testable obligations and defines what a claim of conformity looks like. It is recommended that Annex B be made normative as the control-objective baseline, that the measures carrying the code’s intent be expressed as “shall” provisions, and that a conformity clause be added covering the Statement of Applicability, retained evidence, annual attestation and a transition period. (Amendments: Clause 2, 6.2, new Clause 9, Annex B.)
GOVERNANCER2. Establish governance and accountability roles. Annex B provides for sign-offs by risk, architecture, model-review and governance bodies; the code would be strengthened by a short subclause establishing the roles those sign-offs rely on: an accountable executive, an owner per material AI system, and approval and risk-acceptance authorities scaled to risk, with smaller licensees permitted to combine bodies. (Amendment: new 5.4.)
GOVERNANCER3. Use AI criticality as the proportionality mechanism. Annex C already collects criticality, autonomy and privileges. Defining AI criticality with a derivation method, and keying control depth, independence of testing, reassessment frequency and acceptance authority to the tier, gives the sector one proportionality mechanism that works for a national NSP and a small ASP alike, and supports a phased transition. (Amendments: Clause 4, 6.4, 8.4, new C.1A.)
CYBERSECURITYR4. Key applicability to activity and criticality. Threat exposure follows what an AI system does (the activity performed, the interaction surface, the autonomy level) more closely than the licence held. Recasting Annex B applicability as activity-conditioned statements (“applies where the service provider develops, fine-tunes or self-hosts models”), with licence categories retained as illustration, ensures the obligations land where the exposure sits. (Amendments: 6.4, Annex B applicability column.)
GOVERNANCER5. Express control objectives as testable outcomes with expected evidence. Annex B’s recommended controls would serve assessors and licensees better restated as outcomes with performance attributes, with tool names retained as implementation examples, an Expected evidence column seeded from the AISCF expected outputs, and a mapping to ISO/IEC 27001:2022 and ISO/IEC 42001 controls so certified licensees implement the AI-specific extension rather than a parallel control set. (Amendments: Annex B structure.)
CYBERSECURITYR6. Provide for consumed and third-party models. Most licensees adopt AI under modes (a) and (b) of 5.1 (embedded in products; consumed as a service) rather than build it. It is recommended that the code state that prompts, retrieval corpora and tool configurations remain in scope where the model is consumed; that each Annex B activity carry a disposition (perform, obtain provider assurance, or not applicable with justification); that change classes cover provider-initiated model changes with re-evaluation as a trigger; and that a contractual floor be defined for material third-party AI services. (Amendments: Clause 1, new 6.2A, 7.1, new 7.1.2, Table 8.)
CYBERSECURITYR7. Govern agents and autonomy. The draft already recognises agents in the asset inventory, including the suspension mechanism field in 6.3.3. Building on that: an autonomy tiering subclause (assistive, human-approved action, autonomous within bounds), tool allow-lists with least-privilege credentials, human approval for consequential actions, and a tested suspension path would give the code coverage of the deployment pattern growing fastest in the sector. (Amendments: Clause 4 definitions, 6.1 principle, 6.3.3, new 7.4, 8.1.)
CYBERSECURITYR8. Strengthen the risk assessment method. Annex C would benefit from sample likelihood and impact scales and a matrix, a separation of target risk from residual risk (residual re-rated on implementation and effectiveness evidence), defined acceptance authorities, a maximum reassessment interval for higher tiers, and, for threats operating through model behaviour, scoring by tested attack success rate and reachable impact rather than classical likelihood. (Amendments: C.1, C.2, worked example.)
CYBERSECURITYR9. Anchor the threat taxonomy and complete the per-threat entries. Clause 8’s three lists are the code’s core content; drafting the per-threat entries to the structure already promised in 5.3.2, anchored to the published taxonomies (OWASP LLM Top 10 2025, MITRE ATLAS, NIST AI 100-2e2025) with a reference-identifier column, would resolve the overlapping prompt entries, place each threat with the asset where the vulnerability sits, and allow the 2025 to 2026 threat classes (indirect prompt injection, model backdoors, serialization attacks, tool-use abuse, telemetry poisoning of self-optimising network functions) to be added on a maintained anchor. A new subclause for network-automation AI would carry the sector-specific content only this code can contribute. (Amendments: Clause 8 template, 8.1 to 8.3, new 8.5.)
GOVERNANCER10. Simplify 5.1 into adoption modes with an offered-service flag. The current use-case list describes where AI is used; the obligations turn on how AI arrives. Recasting 5.1 as three adoption modes (embedded in procured products; consumed as a service; built or fine-tuned by the service provider) with one recorded flag (used internally or offered within a licensed service) gives licensees a two-question classification that drives the shared-responsibility matrix, materiality and criticality, while Table 1 is retained as the functional view. (Amendments: 5.1 replacement text.)
GOVERNANCER11. Align with the proposed national AI governance framework. The AI Governance Bill (NAIO public consultation, July 2026) proposes Sectoral Leads implementing a national framework through sector instruments, Developer and Deployer duties assigned by degree of control, harm-anchored risk tiers, and incident reporting including near misses. A registered Technical Code is well placed to serve as the sector’s implementing instrument. It is recommended that the code: extend the Foreword review triggers to include enactment of national AI legislation; carry an Introduction outlook NOTE (consultation status, never cited as binding); map the 5.1 adoption modes to the proposed Developer/Deployer roles in a NOTE; extend the C.1A criticality criteria to answer the Bill’s harm factors (likelihood, severity and scale, duration and reversibility) so one assessment serves both regimes; and align the code’s risk language with the Bill’s harm-anchored three-tier direction, in which organisational risk appetite plays no part in classification. (Amendments: Foreword, Introduction, 5.1 NOTE, 8.4, C.1A.)
CYBERSECURITYR12. Adopt practice-tested deployer controls and implementation patterns. International practice offers ready material: the EU AI Act’s deployer duty set (use per provider instructions, competent assigned human oversight, input-data control, monitoring with suspension, incident notification, minimum log retention, worker notification) and its downstream-documentation entitlement for model buyers; and the current implementation patterns for the controls this code proposes: the model gateway as the enforcement point for approved-model allow-lists, budgets and logging; the tool-level gateway as the second control point for agent tool calls; sandboxed execution and human-approval gates for agents (per the OWASP Top 10 for Agentic Applications 2026, ASI01 to ASI10); and evaluation harnesses run as release gates producing the evidence Annex B expects. The Databricks AI Security Framework v3.0 (March 2026: 97 risks and 73 controls, including 35 agentic risks structured as agent core, tool-server and tool-client sub-components, mapped to MITRE ATLAS, OWASP, NIST and CSA) serves as an informative completeness cross-check. (Amendments: 7.1.2, Annex B implementation notes, OM03, VV05, exclusions carve-back, Bibliography.)
Proposed text is drafting language for the Working Group to lift or adapt.
[Title] Current: “…for Telecommunication and Multimedia Sector”; © Copyright 2027. Proposed: “…for the Communications and Multimedia Sector”; copyright year set at registration. Reason: Aligns the title with the Act’s terminology used throughout the body.
[Foreword] Current: “…valid and effective from the date of its registration until it is replaced or revoked.” Proposed: Append: “This Technical Code shall be reviewed by the Working Group no later than twenty-four (24) months after registration, and earlier upon any revision of the AISCF or upon material change in AI capability or threat landscape identified by the Commission, and the outcome of each review shall be recorded.” Reason: AI capability and the threat picture move quickly; a stated review clock keeps the registered code current and manages the effect of AISCF revisions.
[Introduction] Current: “…confidentiality, integrity, availability, safety, and trustworthiness…”; “preventing, detecting, responding to and recovering from AI cybersecurity incidents”. Proposed: “This Technical Code addresses the protection of AI systems against adversarial compromise of the confidentiality, integrity and availability of AI assets and of AI system behaviour. Safety and reliability failures are within scope where they can be adversarially induced or exploited. AI systems can also be misused as instruments of attack against communications and multimedia infrastructure; such offensive use is addressed by the sector’s general security instruments and is considered in this Technical Code as a factor in assessing threat likelihood and speed.” Either tag each Annex B objective to the four functions (prevent, detect, respond, recover) or omit the four-function sentence. Reason: Fixes one canonical set of protected properties and states the security scope precisely.
[Introduction, audience] Current: “…intended to assist telecommunication licensees, AI solution providers, communications and multimedia service providers, system integrators and other relevant stakeholders…” Proposed: “The requirements of this Technical Code apply to service providers licensed under the CMA 98. AI solution providers, system integrators and other suppliers are reached through the contractual requirements that service providers shall impose under 7.1.2, and may use this Technical Code as guidance.” Reason: A section 95 code binds licensees; suppliers are reached through the licensee’s contracts, which 7.1.2 provides for.
[Whole document] Current: Drafting notes (“Input from…”) remain in the text; Committee representation, Acknowledgements, registered date and the Bibliography are placeholders; several cross-references point to pre-renumbering clauses; Table 3 carries highlight markup. Proposed: Editorial sweep before wider circulation: remove drafting notes, complete front and back matter, convert cross-references to Word field references and verify each against the current numbering (5.3.2 and the Clause 7 introduction refer to Clause 8; 7.2 and 7.3 refer to Clause 6; the Table 3 NOTE refers to 6.4/Annex B). Reason: Standard pre-circulation hygiene.
[1, para 2] Current: “…AI systems supporting communications and multimedia services regulated by the regulatory, including those implemented by [NFP, NSP, ASP, CASP].” Proposed: “This Technical Code applies to service providers holding an individual or class licence under the Communications and Multimedia Act 1998 in respect of material AI systems (see 4.12) that support their licensed services. It applies regardless of deployment model and across all modes of adoption under 5.1 (embedded in procured products; consumed as a service; built or fine-tuned by the service provider); where an AI model is consumed as a service, the associated prompts, system instructions, retrieval corpora, tool and agent configurations, and integration components remain within scope. AI systems used solely for internal enterprise purposes and not embedded in a licensed service are outside the scope of this Technical Code, except that they shall be recorded in the AI asset inventory under 6.3.” Reason: Completes the sentence, names the obligated population, keeps consumed-model components in scope, and settles the treatment of internal-use AI explicitly.
[1, new final paragraph] Proposed: “This Technical Code addresses the cybersecurity of AI systems, including AI systems used as security tools. It does not address AI ethics and responsible-AI governance (see the National Guidelines on AI Governance and Ethics), content regulation, or the provenance and labelling of AI-generated content, which are addressed by other instruments.” Reason: Explicit exclusions prevent scope questions during registration and public comment.
[1, deployment list] Proposed: Align the deployment wording to the single taxonomy adopted in 7.1 (the Table 8 set). Reason: One taxonomy, referenced consistently.
[4.2, 4.4] Proposed: Recast as noun phrases (“data used throughout the AI lifecycle, including…”). Reason: Definition form.
[4.5] Current: “An event that compromises or has the potential to compromise…” Proposed: “AI security event: an observed occurrence indicating a possible compromise of the security of an AI system or its supporting assets, including a guardrail bypass or out-of-scope agent action without confirmed impact. AI security incident: one or more AI security events assessed as having compromised the confidentiality, integrity or availability of an AI asset or of AI system behaviour. NOTE: Statutory incident definitions under the Cyber Security Act 2024 (Act 854) and applicable Commission instruments apply according to their own terms.” Reason: Separating event from incident keeps OM06’s reporting duties proportionate and consistent with the definitions licensees apply under other regimes.
[4.8] Proposed: Keep the OECD-derived definition with a source note “[SOURCE: OECD 2023; EU AI Act, Article 3(1), adapted]”; move the asset-composition sentence to 6.3 and state the count as three classes there. Reason: Aligns the definition with its international source and resolves the three-versus-four count.
[4.10] Proposed: Define data drift, concept drift and performance degradation separately, with the NOTE: “Deliberate poisoning and adversarial campaigns can present as drift; unexplained drift is investigated as a potential security event before retraining (see OM04, CR02).” Reason: The three phenomena carry different detection methods, and the security investigation step protects the retraining loop.
[4.11] Proposed: “Prompt injection: an attack in which untrusted data entering an AI system’s input context is interpreted as instructions, overriding the intended behaviour of the system. Direct prompt injection is delivered through the user input channel; indirect prompt injection is delivered through content the system retrieves or processes, including documents, web content, messages and tool outputs. Jailbreak: an attack in which a user adversarially defeats the safety behaviour of the model itself.” [SOURCE: OWASP LLM01:2025; MITRE ATLAS AML.T0051, AML.T0054] Reason: Defining injection by its mechanism (untrusted data in the instruction channel) identifies where the defence sits and separates it cleanly from jailbreak.
[4, additions] Proposed: Add definitions for: material AI system; AI criticality; AI system owner; accountable executive; agent; tool call; autonomy level (per 7.4); system prompt; guardrail; embedding; model backdoor; membership inference; model inversion; model extraction; shadow AI. Give 4.9 (human oversight) an operative form distinguishing in-the-loop, on-the-loop and after-the-fact oversight. Reason: These terms carry the proposed normative text; “material AI system” in particular is the scoping unit used in 6.3 and 7.1.
[Tables 1, 2, 3, 7] Proposed: Keep Table 1 and one licence-category table; merge the remainder. In the NSP row, name the standardised network-AI functions (3GPP NWDAF, ETSI ENI, O-RAN RIC xApps/rApps) and add one row for internal LLM copilots. Remove the Table 3 NOTE sentence linking the adoption distribution to control applicability; applicability follows the documented risk assessment under Annex C. Reason: A single authoritative table avoids drift between revisions; the network-AI functions and copilots are the sector’s live deployment reality.
[5.3, new NOTE] Proposed: “NOTE: Certain C&M use cases, including eKYC and identity verification, deepfake detection, content moderation and fraud detection, operate under sustained adversarial pressure by nature. For these use cases, the service provider should treat the systems as High criticality candidates and apply continuous adversarial re-testing regardless of licence category.” Reason: For these systems, evasion is the operating condition, and testing cadence should reflect that.
[5.3.2] Proposed: Add to the per-threat structure: “(f) the autonomy level at or above which the threat requires the enhanced measures of 7.4; and (g) the applicable reference identifiers (OWASP LLM Top 10 2025, MITRE ATLAS, NIST AI 100-2e2025).” Reason: Threat severity varies with autonomy, and reference identifiers keep the taxonomy maintainable.
[NEW 5.4 Governance and accountability] Proposed (full text):
5.4 Governance and accountability for AI cybersecurity
5.4.1 The service provider shall assign accountability for AI cybersecurity to a designated senior management role (the accountable executive) and shall record the assignment.
5.4.2 The service provider shall assign a named owner to each material AI system and shall record the assignment in the AI asset inventory under 6.3.
5.4.3 The service provider shall define and record the approval authorities for: (a) authorisation of a material AI system to operate; (b) acceptance of residual risk, such that residual risk rated High or Critical is accepted only by the accountable executive or a governance body to which the accountable executive belongs, and not by the AI system owner proposing it; and (c) changes under the change classes defined in 6.2A.
5.4.4 For AI systems rated High or Critical, verification, validation and security testing under phases P3 and P6 shall be performed or reviewed by a function independent of the team that develops or operates the system.
5.4.5 The accountable executive shall receive, at least annually, a report covering the AI asset inventory and its completeness reconciliation, the criticality distribution, the highest residual risks, third-party AI dependencies, and AI security events and incidents.
5.4.6 A service provider may combine the roles and bodies in 5.4.1 to 5.4.5 with existing governance structures, provided the accountability assignments remain individually identifiable and the separation in 5.4.3 (b) is preserved.
Reason: Provides the roles the Annex B sign-offs rely on, ties risk acceptance to a defined authority, and gives smaller licensees a proportionate path through 5.4.6.
[Clause 6, structure] Current: 6.1 AI security principles; 6.2 AI security lifecycle; 6.3 AI assets (6.3.1 data, 6.3.2 models, 6.3.3 infrastructure and applications); 6.4 controls mapping. Proposed: Reorder to: 6.1 AI security principles; 6.2 AI assets (6.2.1 AI data, 6.2.2 AI models, 6.2.3 AI infrastructure and applications, carrying the inventory, identifier, use-case, component-documentation, prompt-management and suspension provisions); 6.3 AI security lifecycle (carrying the assessable-baseline sentence and the change classes, which become 6.3A); 6.4 controls mapping and risk-based scaling (unchanged position). Retitle the clause “Artificial Intelligence (AI) security principles, assets and lifecycle”. Reason: The lifecycle tables reference the three asset classes before the current 6.3 introduces them; placing assets before lifecycle removes the forward reference, follows the AISCF’s own construction (security built upon the three core assets) and aligns with Clause 8’s asset-based organisation. The clause then reads: why (principles), what is protected (assets), when and how (lifecycle), how much (scaling by criticality). NOTE: The remaining entries in these comments cite the draft’s current numbering; on adoption of this reorder, 6.2 references become 6.3, 6.3/6.3.1/6.3.3 references become 6.2/6.2.1/6.2.3, and 6.2A becomes 6.3A, with cross-references resolved by Word field references per the editorial amendment.
[6.1, Table 4] Proposed: Add principle 8: “Constrained autonomy and least privilege. AI system outputs and actions are treated as untrusted. Permissions, tool access and consequential actions are bounded independently of model behaviour, and every agent has a tested suspension path.” Give principle 5 an operative home: “For AI systems rated High or Critical, the service provider shall define human oversight intervention points, shall implement an override and suspension mechanism, and shall test that mechanism at least annually.” Add a principle-to-activity traceability table or column. Reason: Published mitigations for prompt injection reduce reachable impact rather than attack success, which makes the bounding principle architectural; the oversight requirement gives principle 5 a testable form.
[6.2] Proposed: “The assessable baseline for conformity with this Technical Code is the control objectives in Annex B. The AISCF’s activity descriptions, expected outputs and standards mappings provide implementation guidance.” Add 6.2A Change classes: “The service provider shall define change classes for material AI systems covering at least: data-only changes (including retrieval-corpus updates), prompt and configuration changes, model version changes (including provider-initiated changes), and tool or integration changes; and shall define for each class the required re-validation and the approval authority under 5.4.3 (c).” Reason: States which document an assessor tests against, and gives the frequent change traffic of consumed-model systems a defined, proportionate route.
[6.3] Proposed: “The service provider shall maintain an AI asset inventory covering all AI data, AI models, and AI infrastructure and applications, including agents and other autonomous components. Each material AI system shall carry a unique persistent identifier used consistently across the inventory, Annex B evidence and Annex C assessments, and shall record at minimum: the system owner (5.4.2), the mode of adoption and offered-service status (5.1), the autonomy level (7.4), the criticality rating (Annex C), and the intended use case(s) and purpose. The service provider shall reconcile the inventory against procurement, configuration-management and network-discovery records at least annually, and the accountable executive shall attest to its completeness. For each material AI system, the service provider shall document its components and dependencies, including the model and its version lineage, datasets, system prompts, tools and third-party services. NOTE: This component documentation may take the form of an AI Bill of Materials (4.1); machine-readable formats include the OWASP CycloneDX ML-BOM and the SPDX AI profile, with model, agent and data cards as the narrative layer.” Reason: The persistent identifier joins the runtime and governance evidence; the intended use case is the unit of risk assessment (the same model in two use cases carries two risk profiles); and expressing the component documentation as an outcome, with the AI-BoM named in a NOTE, matches the approach of the international baseline (ETSI EN 304 223 Principle 8 mandates the documentation outcome; its companion guide names the ML-BOM formats).
[6.3.1] Proposed: Add: “System prompts and AI configuration shall be managed as versioned configuration items: changes shall be version-controlled, reviewed, and subject to the re-validation defined for the prompt-and-configuration change class in 6.2A. Embeddings shall inherit the classification and handling requirements of their source data.” Reason: Prompt changes can alter safety behaviour and embeddings can reveal source content; both controls are inexpensive to operate.
[6.3.3] Proposed: Add: “For every agent with tool access, the service provider shall implement a suspension mechanism capable of halting the agent’s actions, shall assign a role authorised to invoke it, and shall test it at least annually. The suspension path shall not depend solely on infrastructure the agent itself can modify.” Reason: Builds on the suspension field already present in the inventory by making the mechanism itself a tested control.
[6.4] Proposed: “The service provider shall scale the application and depth of the security activities according to the AI criticality rating of each material AI system determined under Annex C. Table 6 is illustrative and does not limit the applicability determined by the documented risk assessment.” Reason: Scales obligations by the risk of the system rather than the size or class of the licensee.
[7.1/7.1.1/Table 8] Proposed: Adopt the Table 8 set as the single deployment taxonomy; recast 7.1’s three models as an introductory grouping; fold the 7.1.1 list into it; align Clause 1. Add: “Use of any deployment model or third-party arrangement does not transfer the service provider’s accountability for conformity with this Technical Code.” Reason: One taxonomy for licensees to inventory against, and the standard accountability principle for outsourced arrangements.
[7.1, output artefact] Proposed: “For each material AI system, the service provider shall document a shared-responsibility matrix, consistent with the adoption mode recorded under 5.1, allocating responsibility for each AI asset class (data, model, infrastructure and applications) between the service provider, providers and other parties, including who holds the model weights and who holds the training data; and shall review the matrix upon any provider, model-version or deployment change.” Reason: Records the determinations 7.1 already requires, in a form an assessor can review; the weights and training-data allocation identifies which threats apply.
[NEW 7.1.2 Contractual requirements for material third-party AI services] Proposed (full text):
For each material third-party AI service, the service provider shall include in its contractual arrangements, or shall document why an equivalent assurance is otherwise obtained:
- security requirements consistent with the applicable objectives of Annex B;
- notification of security incidents affecting the service within a defined period;
- advance notification of material model or service changes, and model-version pinning where the provider offers it;
- restriction on use of service-provider and subscriber data for provider training without documented agreement;
- audit or assurance rights, for which current ISO/IEC 27001 or ISO/IEC 42001 certification or an equivalent independent assurance report may be accepted; and
- exit, data-return and portability terms.
Reason: The contractual route is how a licensee-scoped code reaches suppliers, and it completes the audience amendment in the Introduction.
[Table 8, rows 3 and 6] Proposed: Row 6 (foundation-model integration): add indirect injection via retrieved or fetched content; system-prompt confidentiality; provider-initiated model change (re-run the acceptance and adversarial test suite on any provider model change); provider data-use and logging terms; egress control on model-initiated tool and web access. Row 3 (edge): add signed model artefacts verified on-device before load, and on-device model confidentiality across the deployed device population. Add a NOTE describing the central LLM gateway pattern (authentication, per-tenant rate limiting, prompt and completion logging, redaction, cost caps) as a recommended implementation architecture. Reason: Completes the considerations for the two deployment models with the fastest-moving risk, and names one implementation pattern that operationalises several Annex B objectives at once.
[NEW 7.4 Autonomy levels and action scope] Proposed (full text):
7.4.1 The service provider shall assign each material AI system one of the following autonomy levels and shall record it in the AI asset inventory:
- Level 1 - Assistive. The system produces information or recommendations only; all actions are taken by humans.
- Level 2 - Human-approved action. The system proposes actions that are executed only upon human approval before execution.
- Level 3 - Autonomous within bounds. The system executes actions without per-action human approval, within defined tool, scope and rate bounds.
7.4.2 For every Level 2 and Level 3 system, the service provider shall document the action scope: the tools the system may invoke, the credentials and permissions granted to each tool, and the systems and data each tool can reach. Tool access shall be granted on an allow-list basis with least-privilege credentials per tool.
7.4.3 For every Level 3 system, the service provider shall additionally implement and test: (a) rate limits and scope caps bounding the maximum effect of one decision cycle; (b) the suspension mechanism under 6.3.3; and (c) rollback or compensation procedures for the actions the system can take, in addition to rollback of deployments of the system. Level 3 systems with write access to live network elements shall be rated at least High criticality.
7.4.4 Consequential actions, as defined by the service provider and including at minimum changes to live network configuration, payments, and disclosure of subscriber personal data, shall require human approval unless the system is authorised at Level 3 for that action class by the authority under 5.4.3 (a).
Reason: Distinguishes the systems that only inform from the systems that act; the autonomy level is the variable the criticality rating and several Clause 8 threats depend on.
[8, intro] Proposed: Restart the second list’s lettering at a). Adopt the per-threat structure as normative and draft all entries to it: (a) description and mechanism; (b) C&M manifestation with licence-category scenarios where applicable; (c) potential impact expressed in regulated-service consequences (licensed-service availability, subscriber and traffic data, content integrity, network integrity, lawful-interception obligations); (d) the autonomy level at or above which enhanced measures under 7.4 apply; (e) recommended security measures, ordered by effectiveness, with Annex B activity identifiers; (f) reference identifiers (OWASP LLM Top 10 2025, MITRE ATLAS, NIST AI 100-2e2025). Reason: Completes the structure the code already promises in 5.3.2, and item (c) is what distinguishes a sector code from a general AI-security list.
[8.1 to 8.3, taxonomy] Proposed: When drafting the entries: retain prompt injection in 8.1 (the vulnerability is in the application’s prompt assembly) and jailbreak in 8.2 (a property of the model’s safety behaviour), with a cross-reference; withdraw “prompt manipulation” (8.2 f) in favour of the two defined terms; define model theft (artefact exfiltration) and model extraction (query-based replication) with their different control sets; move membership inference and model inversion to 8.2 with training-side and API-side mitigations added to Annex B; recast “hallucination” as “exploitation of model confabulation (including hallucinated package or resource squatting)” and “model drift” as “undetected degradation or adversarially induced drift masking attack”, with general reliability routed to the risk assessment per ISO/IEC 23894. Reason: Placing each threat with the asset where the vulnerability sits ensures the recommended measures land with the right owner.
[8.1, additions] Proposed: Add: indirect prompt injection via retrieved or processed content (own entry; 8.3 h covers the stored-KB variant); insecure output handling (model output flowing unencoded into HTML, SQL, shell or downstream systems); tool-use and function-calling abuse (tool allow-lists, least-privilege credentials, human approval for consequential actions per 7.4.4, tool descriptions and retrieved content treated as untrusted); unbounded consumption (per-key quotas, token ceilings, spend alerts). Develop “agentic AI abuse” into: persistent memory poisoning; tool misuse and excessive agency; inter-agent and tool-chain trust exploitation (including tool-server supply chain). Reason: These are the highest-frequency practical exposures for the deployment patterns in Tables 2 and 7.
[8.2, additions] Proposed: Add: model backdoors (trigger-conditioned behaviour that passes accuracy validation; mitigations are provenance and trigger-scanning); model serialization attacks under compromised repositories (safe serialization formats such as safetensors or ONNX; no pickle-based artefacts from untrusted sources; artefact scanning); a note that multi-turn jailbreaks defeat single-turn input filters. Under poisoning, distinguish web-scale pre-training poisoning from fine-tuning and feedback poisoning. Reason: Mechanism-level threats with published identifiers; the serialization measure in particular is inexpensive and closes a real code-execution path.
[8.3, addition] Proposed: Add training-data extraction via memorisation. Reason: Completes the privacy-attack set with the variant that discloses content.
[NEW 8.5 Risk scenarios specific to network-automation AI] Proposed (full text):
8.5.1 This subclause applies to AI systems that observe or act on live network infrastructure, including SON, NWDAF-based analytics, RAN Intelligent Controller xApps and rApps, AIOps and closed-loop automation.
8.5.2 Telemetry and feedback poisoning. An attacker who can shape observable traffic, measurement reports or feedback signals may steer a self-optimising model into degrading coverage, opening capacity for abuse or masking an intrusion. The service provider shall treat telemetry feeding closed-loop network AI as an integrity-protected asset, shall validate measurement inputs against independent sources where available, and shall investigate unexplained optimisation behaviour as a potential security event before retraining or reinforcing the loop.
8.5.3 Compromise of defensive AI. For AI systems used for threat detection and SOC automation, evasion of the detection model and poisoning of its feedback loop are the priority scenarios; the consequence of compromise is the downstream missed intrusion. Detection models exposed to attacker-influenced input shall be subject to adversarial testing under CR06.
8.5.4 Systems in scope of this subclause operating at autonomy Level 3 shall meet 7.4.3, and their maximum single-cycle effect shall be bounded by canary or partition domains where technically feasible.
Reason: Closed-loop automation converts a data-integrity issue into a network-integrity incident; this subclause carries the sector-specific content that gives the code its distinct value next to the horizontal standards.
[8.4] Proposed: “The service provider shall complete a documented risk assessment per material AI system before authorisation to operate, and shall reassess upon the triggers in 6.2A and CR09 and at least every twelve (12) months for systems rated High or Critical. The assessment and any residual-risk acceptance shall be approved by the authorities defined under 5.4.3. NOTE: For interconnected services, the consequences of AI failure may propagate across networks through signalling, interconnection and roaming; the impact assessment considers sector-wide effects in addition to the service provider’s own exposure.” Reason: Gives the risk-based mechanism its owner, cadence and approval route in normative text.
[NEW Clause 9 Conformity] Proposed (full text):
9.1 Conformity with this Technical Code is assessed against the control objectives in Annex B, as scoped by the criticality tier of each material AI system and the disposition recorded under 9.2.
9.2 The service provider shall maintain, per material AI system or documented group of systems, a Statement of Applicability recording, for each Annex B activity, whether it is performed by the service provider, assured through a provider under 7.1.2, or not applicable with a documented justification.
9.3 The service provider shall retain, for each material AI system: the risk assessment and its approvals; the Statement of Applicability; the shared-responsibility matrix; the evidence identified in the Expected evidence column of Annex B, traceable to the AI system identifier; and records of tests under 5.4.4, 6.3.3 and 7.4.3.
9.4 The service provider shall attest conformity annually through the accountable executive. For AI systems rated High or Critical, conformity shall additionally be assessed by a party independent of the system’s development and operation, which may be an internal function satisfying 5.4.4 or an external assessor, on a cycle aligned with the service provider’s existing Commission security-assessment obligations.
9.5 Transition: the AI asset inventory under 6.3 and criticality ratings under Annex C shall be completed within twelve (12) months of registration; full conformity for High and Critical systems shall be achieved within twenty-four (24) months.
Reason: Defines what a claim of conformity consists of, reuses the Statement of Applicability mechanism certified licensees already operate, and gives the sector a realistic transition path.
[Status and structure] Proposed: Mark “(normative)” and retitle “Control objectives for the 42 AISCF activities”. Restructure each table to: Ref ID | Activity | AI assets | Control objective (a testable outcome in “shall” form) | Expected evidence (seeded from the AISCF expected outputs) | Applicability (activity-conditioned) | Implementation notes (informative; current tool names become examples here). Replace the three-way physical/technical/administrative split with physical controls stated only where they carry weight (DP02, OM02, RT01, RT03, CR06) and a general reference to ISO/IEC 27002 physical controls in the preamble. Replace licence-category applicability with statements such as “applies where the service provider develops, fine-tunes or self-hosts models”, “applies where the model is exposed to adversarial or public input”, “applies at criticality High and above”. Remove the colour-coding sentence (the phase name appears in each banner). Add a mapping column to ISO/IEC 27001:2022 Annex A and ISO/IEC 42001 controls with the rule that an existing certified control satisfies the activity, extended for the AI-specific scope where indicated. Reason: Implements R1, R4 and R5 in one restructure and avoids duplicating the certified ISMS.
[DD03] Proposed: Applicability: “applies where the service provider develops, fine-tunes or self-hosts a model, or operates a model exposed to adversarial input, at any licence category”. At design, specify robustness acceptance criteria; testing sits in VV02/CR06. Add design-side privacy measures: training-data deduplication, and differential privacy or regularisation where feasible. Reason: Directs the control to the systems under adversarial pressure and places testing in its phase.
[DD06] Proposed: “Threat-modelling methodology (e.g. STRIDE) informed by adversarial-ML knowledge bases (e.g. MITRE ATLAS, NIST AI 100-2).”
[Table B.3 banner] Proposed: “P3 - VERIFICATION AND VALIDATION”.
[VV02/VV05] Proposed: Split VV05 into (a) pre-release evaluation gates (an evaluation suite tied to the service provider’s own use cases, run before authorisation and re-run per change class under 6.2A, with defined pass thresholds) and (b) runtime output controls (guardrails, output encoding, safety classifiers, escalation). Add to VV02 a regurgitation test against sensitive training data for models trained or fine-tuned on personal data, and confidence-output suppression as an API-side privacy measure. Reason: The two layers have different owners and evidence; the regurgitation test also supports PDPA obligations.
[DP03/OM05] Proposed: “The service provider shall operate a model registry recording model identity, version, approval status, stage promotion and decommissioning for material AI models. Changes within a pre-approved retraining envelope (fixed pipeline, fixed data sources, evaluation thresholds enforced as automated release gates) may be promoted automatically; changes outside the envelope shall follow the change-approval process under 6.2A. Deployment, canary, rollback and retirement operations shall be executed through the registry’s stage gates.” Reason: Reconciles automated retraining with change approval and gives DP03, OM05, CR08 and RT02 one auditable mechanism.
[OM03] Proposed: Define the minimum AI log record per inference or agent action: request identifier, model and prompt version, tool calls and results, guardrail verdicts, token counts, and prompt and completion capture subject to a stated privacy rule (“conversation logs containing subscriber personal data shall be redacted or access-restricted and retained per the retention schedule”). Retain SIEM integration as an implementation note. Reason: Specifies the telemetry OM03 relies on and provides the forensic record OM06 needs.
[OM04/CR02] Proposed: Add: “Unexplained drift or degradation shall be investigated as a potential security event, including an adversarial hypothesis, before retraining or feedback reinforcement.”
[CR06] Proposed: Keep one CR06 row noting it applies in both P6A and P6B. For High/Critical systems, define minimum testing rigour: “(a) scoped to the documented threat model; (b) covering the deployed system including prompts, tools, retrieval corpora and memory; (c) measuring attack success rate against defined harm categories; (d) re-run as regression upon model, guardrail or prompt change per 6.2A”, with multi-turn coverage included. Below High criticality these are recommendations. Reason: Defines what adequate testing consists of while keeping the cost proportionate through the tiers.
[Additional control groups] Proposed: Add under DD04/DP02: multi-tenant GPU isolation, driver and container-toolkit patching, no unauthenticated ML service endpoints. Add under DD01/DD05: vector-store authentication, tenant and collection separation, integrity and change control on corpus ingestion, embedding classification per 6.3.1. Add under DD05/OM02: per-agent tool allow-lists and least-privilege tool credentials per 7.4.2, and egress controls on agent-initiated network access. Reason: Provides the implementing controls for the GPU, knowledge-base and agent threats named in Clause 8.
[Table B.7] Proposed: Align the legend’s retirement prefix with the table (RT, subject to verification against the AISCF). Add to RT01/RT02: “A trained model may retain the informational content of its training data. Where an erasure obligation applies to data used in training or fine-tuning, deletion of the source record alone may not discharge the obligation; the service provider shall assess whether retraining from a cleansed dataset or retirement of the model is required.” Reason: Reflects the practical state of machine unlearning and supports PDPA erasure duties honestly.
[C.1/C.2] Proposed: Add sample likelihood and impact scales (keyed to step 4’s impact dimensions, plus persistence: the cost and time to remediate where remediation means retraining or replacement) and a sample matrix, marked adaptable. Add C.1A Criticality assessment: derive the rating from service-disruption impact, subscriber scale, data sensitivity and autonomy level, with the consequence table: Low = inventory plus baseline ISMS controls; Moderate = plus documented risk assessment; High/Critical = full applicable Annex B, independent testing (5.4.4), governance-level acceptance (5.4.3 b), 12-month reassessment. Amend step 7: “Residual risk shall be re-rated only upon evidence that the selected measures are implemented and operating effectively; before such evidence exists the post-treatment rating is the target residual risk. Risk acceptance is required at or above [defined threshold] and shall follow 5.4.3 (b).” Add a maximum reassessment interval of twelve (12) months for High and Critical systems. Reason: Makes assessments reproducible and comparable across licensees, and connects the criticality rating to its consequences.
[Behavioural-threat scoring] Proposed: Add a NOTE to steps 4 and 7: “For threats operating through model behaviour (injection, jailbreak, extraction), attempt likelihood approaches certainty for any public interface. Likelihood should be scored as the tested attack success rate for the current model, prompt and guardrail versions, and impact as the worst action or data reachable given current privileges. Residual-risk claims for such threats require post-mitigation testing evidence.” Reason: Aligns the scoring method with how these threats behave in practice.
[Worked example] Proposed: Align C.4/C.5 columns to the C.1/C.2 template. Reorder R01’s measures by effectiveness: privilege restriction; separation of trusted and untrusted content; tool allow-listing and approval gates (add); monitoring; security testing; input validation last. Hold R05’s residual at Medium pending effectiveness evidence. Add R06: insecure output handling. Add log redaction to R02 and provider model-version pinning with re-evaluation to R04. Populate the AISCF reference placeholders. Add a second worked example for a Level 3 network-automation agent, cross-referencing 8.5 and 7.4. Reason: The worked example is the pattern licensees will copy; it should model the method in full, including the sector’s harder case.
[5.1, replacement] Current: seven-item list of services where AI may be deployed. Proposed: “AI enters a service provider’s environment in three modes:
embedded in procured products - network equipment, OSS/BSS, security tooling and SaaS platforms with AI features, including the network-native AI functions (NWDAF, RAN Intelligent Controller applications, SON); obligations follow their autonomy level and criticality under 7.4 and Annex C;
consumed as a service - enterprise-integrated foundation-model and cloud AI consumption, managed services operated on the service provider’s data, and workforce use of general AI tools; use outside sanctioned channels constitutes shadow AI, addressed through the inventory under 6.3; and
built or fine-tuned by the service provider - including self-hosted open-weight models, where the service provider takes custody of the model weights and the change cadence.
For each material AI system the service provider shall record: (i) the mode of adoption; and (ii) whether the system forms part of a service offered to customers. AI offered within a licensed service carries higher exposure and is assessed accordingly under Annex C. Within any mode, AI may serve the functional domains illustrated in Table 1. NOTE: The proposed national AI governance framework (public consultation, July 2026) assigns duties to Developers and Deployers by degree of control. A service provider under mode (c), including one that fine-tunes or integrates a third-party model, would correspond to a Developer; under modes (a) and (b), to a Deployer. This NOTE is informational; the consultation document is not law.” Reason: Two questions (how did it arrive; who does it face) classify any system in seconds; each mode gives a distinct answer on who holds the model, the data and the change cadence, which is what the shared-responsibility matrix and Annex B dispositions need.
[Foreword, review triggers] Proposed: extend the earlier review-clock amendment: “…and earlier upon any revision of the AISCF, enactment of national AI legislation, designation of the Commission as a Sectoral Lead under such legislation, or material change in AI capability or threat landscape identified by the Commission…” Reason: Keeps the registered code aligned with the national framework as it lands.
[Introduction, outlook NOTE] Proposed: “NOTE: A national AI governance statute is under public consultation. This Technical Code is designed so that conformity with it can support the sector’s implementation of any resulting framework.” Reason: Positions the code as the sector’s implementing instrument without citing a consultation draft as law.
[6.2A, addition] Proposed: add to the change classes: “A substantial modification is an out-of-envelope change that alters the service provider’s degree of control over the AI system, including fine-tuning or integration of a consumed model, or the use of the system for a purpose materially different from its recorded intended use case. A substantial modification triggers reclassification of the system’s adoption mode and, where the intended use has changed, a new risk assessment under Annex C.” Reason: The duty profile follows control and purpose: a change that shifts either must resurface the classification, because the same system pointed at a new use case carries a different risk profile even where its components are unchanged.
[7.1.2, addition] Proposed: add item (g): “provision of model documentation covering capabilities, limitations, intended and prohibited uses, evaluation summaries and integration guidance.” Reason: Gives the licensee by contract the model information international practice provides by statute.
[Annex B, OM03] Proposed: add a minimum retention period for the AI log records: “retained for not less than [six (6)] months or the period required under applicable instruments, whichever is longer.” Reason: A numeric floor makes the logging obligation assessable; the figure is for the Working Group to settle.
[Annex B, consuming-licensee duties] Proposed: add two objectives for consumed AI systems: use in accordance with the provider’s documented instructions and limitations; and notification of affected workers where an AI system is used in ways that affect staff. Reason: Completes the practice-tested deployer duty set; the remaining items already exist in the proposed 5.4, 6.3.3, OM03, OM06 and 7.4.
[VV05 runtime controls / Clause 1 exclusions] Proposed: add one transparency measure: “customer-facing AI systems in licensed services shall inform users that they are interacting with an AI system”; narrow the Clause 1 exclusion accordingly (provenance and labelling of AI-generated content remain excluded; interaction disclosure is included). Reason: Low-cost, aligned with the transparency principle in both the national guidelines and international practice; its absence would be conspicuous in any future crosswalk.
[7.4, NOTE] Proposed: “NOTE: Service providers may use available regulatory sandbox arrangements to trial Level 3 automation under supervision before production authorisation.” Reason: Connects the autonomy tiers to the supervised innovation route the national framework proposes.
[Annex C, C.1A and assessments] Proposed: extend the criticality criteria so the assessment also records the harm factors used in the proposed national framework (likelihood; severity and scale; duration and reversibility, which also carries the persistence dimension). Add: “The AI risk assessment may incorporate, or be incorporated into, the service provider’s personal data protection impact assessment and any assessment required under applicable AI legislation, provided each regime’s criteria are addressed and traceable.” Reason: One assessment serving multiple regimes avoids duplicate documentation; the harm factors future-proof the method.
[Annex B, implementation notes; Bibliography] Proposed: name the current implementation patterns in the informative notes: the model gateway as the enforcement point for approved-model allow-lists, per-tenant budgets and central logging (the shadow-AI and unbounded-consumption controls); the tool-level gateway as the second control point governing which tools an agent may invoke and under whose identity; sandboxed execution for agent code; human-approval gates for consequential actions; evaluation harnesses run as release gates. Add to the Bibliography: OWASP Top 10 for Agentic Applications 2026 (ASI01 to ASI10, December 2025) as the agentic threat reference for the Clause 8 agentic entries, CSA MAESTRO as an agent threat-modelling method alongside STRIDE in DD06, and the Databricks AI Security Framework v3.0 (March 2026; 97 risks, 73 controls, including the 35-risk agentic extension) as an informative completeness cross-check for the Clause 8 taxonomy. The agentic extension’s tool-server versus tool-client split (poisoned tool definitions and descriptions on the server side; malicious servers, client-side code execution and connection data leakage on the client side) is recommended as the drafting structure for the tool-chain entry in 8.1, and its reasoning-trace observability control supports adding “agent reasoning or plan traces, where the runtime exposes them” to the OM03 minimum log record. Reason: Every recommended control should name a pattern licensees can deploy today; the references are current, public and maintained.
[8.4 and Annex C, risk-language alignment] Current: 8.4 determines applicability and significance through the organisation’s “risk appetite” alongside the documented risk assessment. Proposed: “The applicability and tier of each risk scenario shall be determined by the documented risk and criticality assessment under Annex C, assessed against the harm factors (likelihood; severity and scale; duration and reversibility). Organisational risk acceptance criteria apply only to the acceptance of residual risk under 5.4.3 (b) and shall not be used to determine the applicability of risk scenarios or the criticality tier of an AI system. NOTE: The proposed national AI governance framework (public consultation, July 2026) adopts a three-tier, harm-anchored risk framework: Tier 1, unacceptable (an AI system developed or deployed with intent to cause a defined harm); Tier 2, high risk (no intent, but a risk of a defined harm occurring), carrying structured obligations including risk assessment, documentation, internal controls, human oversight, monitoring and mitigation; Tier 3, low risk (no foreseeable material AI harm), carrying baseline due-regard duties. The defined harms are death; bodily injury; unlawful deprivation of fundamental liberty; and contravention of any written law, expandable per sector. The consultation paper does not use the concept of organisational risk appetite. This NOTE is informational; the consultation document is not law.” Reason: Classification against defined harms is objective and comparable across licensees; appetite is subjective and belongs only to the acceptance decision. Aligning now avoids licensees building assessment processes around a concept the coming statute does not use, and notes that the fourth defined harm (contravention of any written law) can bring personal-data and licence-condition breaches within a harm pathway.
An editorial pass accompanies the above: British and Malaysian spelling (“licence” as noun), numeral-style consistency, definition ordering and grammar, “Tables C.1 to C.3” phrasing, and qualification of the Table 2 NFP reference to data-centre facilities against the current MCMC licensing framework.
| Order | Item | Depends on |
|---|---|---|
| 1 | Settle the normative posture: normative Annex B, Clause 9 Conformity, transition timeline (R1) | Nothing; shapes every clause |
| 2 | Governance subclause 5.4 and role definitions (R2) | 1 |
| 3 | Criticality method C.1A and its consequence table (R3) | 2 |
| 4 | Clause 8 per-threat template settled (R9, structure) | Nothing |
| 5 | Scope, “material AI system”, exclusions; Clause 2 references and review clock (R6 part) | Nothing; parallel |
| 6 | Draft the per-threat entries against the anchors; new 8.5 (R9) | 4 |
| 7 | Autonomy tiering 7.4, principle 8, suspension controls (R7) | 2 |
| 8 | Consumed-model provisions: 6.2A change classes, SoA dispositions, 7.1.2 (R6) | 1 |
| 9 | Model registry and retraining envelope (part of R6) | 8 |
| 10 | Annex B restructure (R4, R5) | 1, 3 |
| 11 | Annex C repair and second worked example (R8) | 3 |
| 12 | Editorial sweep and Bibliography | Last, after renumbering settles |
These comments are working material for the MTSFB Security, Trust and Privacy Working Group drafting process, offered for discussion. Statements touching the Communications and Multimedia Act 1998, the Cyber Security Act 2024 (Act 854), the PDPA 2010 and MCMC technical-code and assessment regimes are drafting observations, not legal or regulatory advice.