MTSFB2510R0: Member comments and proposed amendments

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 has 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, starting with three decisions worth settling first: whether the code states requirements or guidance, who is accountable, and how obligations scale with risk. Nine further recommendations follow, each with ready drafting text (shall / should / may used deliberately) for the Working Group to adopt, adapt or reject.

A. Recommendations

GOVERNANCER1. Write requirements an assessor can test.

The code is titled Requirements, but the draft contains seven “shall” statements; nearly everything else is written as “should”, which each licensee can read as optional. In that form the sector gets no common baseline: two licensees can both say they follow the code while doing very different things, and an assessor has no consistent basis to check either. A requirement is a duty a licensee can implement and an assessor can mark as done or not done. Recommended:

1. Make Annex B normative.
2. Write the key measures as “shall” provisions.
3. Add a conformity clause stating how a licensee demonstrates compliance.

(Amendments: Clause 2, 6.2, new Clause 9, Annex B.)

GOVERNANCER2. Name who is accountable for AI security.

Annex B asks for sign-offs from several committees the code never sets up. Recommended, in one short subclause:

1. An accountable executive.
2. An owner for each material AI system.
3. Defined authorities for approving systems and accepting risk.
4. Smaller licensees may combine roles.

(Amendment: new 5.4.)

RISKR3. Match the depth of controls to the risk of the system.

Annex C already collects criticality, autonomy and privileges, but nothing changes based on the answers. Recommended:

1. Define how criticality is rated.
2. Let the rating decide control depth, who tests, how often reassessment happens, and who can accept the risk.

This lets one code work for a national NSP and a small ASP alike. (Amendments: Clause 4, 6.4, 8.4, new C.1A.)

CYBERSECURITYR4. Apply controls based on what the system does, not the licence category.

Threat exposure follows the activity: does the licensee build models, is the system public-facing, how autonomous is it. It does not follow the licence category. Recommended:

1. Rewrite Annex B applicability as conditions such as “applies where the service provider develops, fine-tunes or self-hosts models”.
2. Keep licence categories as illustration.

(Amendments: 6.4, Annex B applicability column.)

GOVERNANCER5. Define each control by its outcome and evidence, not by a tool name.

Annex B currently lists tools (“SIEM/SOAR”, “IAM/PAM”). A tool being bought proves nothing. Recommended:

1. State each control as an outcome an assessor can check.
2. Keep tool names as examples.
3. Add an “Expected evidence” column.
4. Map to ISO/IEC 27001 and 42001 so certified licensees reuse what they already have.

(Amendments: Annex B structure.)

CYBERSECURITYR6. Set clear rules for AI that is bought or subscribed to, not built.

Most licensees buy AI in products or consume it as a service; few build it. Recommended:

1. Keep prompts, knowledge bases and tool settings in scope even when the model is not owned.
2. Let each Annex B activity be marked performed / assured through the provider / not applicable.
3. Treat a provider changing the model as a trigger to re-check.
4. Set minimum contract terms for material third-party AI services.

(Amendments: Clause 1, new 6.2A, 7.1, new 7.1.2, Table 8.)

CYBERSECURITYR7. Set rules for AI that takes actions on its own (agents).

The draft already lists agents in the asset inventory; this is the fastest-growing deployment pattern in the sector. Recommended:

1. Three autonomy levels: advises only; acts with human approval; acts within set bounds.
2. Tool allow-lists with least-privilege credentials.
3. Human approval for consequential actions.
4. A tested way to stop an agent.

(Amendments: Clause 4 definitions, 6.1 principle, 6.3.3, new 7.4, 8.1.)

RISKR8. Make the risk assessment method repeatable and evidence-based.

Annex C needs the basics, plus one change specific to AI. Recommended:

1. Sample scales and a matrix.
2. A clear split between planned risk reduction and evidenced risk reduction.
3. Named acceptance authorities and a maximum reassessment interval.
4. For attacks that work through model behaviour (injection, jailbreak): score the tested attack success rate, because estimated likelihood carries no information when attack attempts are near-certain.

(Amendments: C.1, C.2, worked example.)

CYBERSECURITYR9. Complete the 43 threat descriptions using recognised international references.

Clause 8 currently lists 43 threat names with no content. Recommended:

1. Draft each entry to the structure the code already promises, anchored to OWASP LLM Top 10 2025, MITRE ATLAS and NIST AI 100-2e2025 so the names stay maintainable.
2. Fix the overlapping prompt entries and add the newer threat classes.
3. Add a subclause for network-automation AI: the sector-specific content only this code can provide.

(Amendments: Clause 8 template, 8.1 to 8.3, new 8.5.)

GOVERNANCER10. Classify each AI system by how it arrived and who it faces.

Two questions classify any AI system: how did it arrive (in a product; as a service; built or fine-tuned in-house) and who does it face (internal use, or provided to customers). Recommended:

1. Replace the 5.1 use-case list with these two questions, recorded per system.
2. Keep Table 1 as the functional view.

(Amendments: 5.1 replacement text.)

GOVERNANCER11. Prepare the code for the coming national AI law.

The AI Governance Bill (public consultation, July 2026) points to sector regulators implementing a national framework through sector instruments, duties split between Developers and Deployers, and harm-based risk tiers. A registered Technical Code is well placed to be the sector’s implementing instrument. Recommended:

1. Add enactment as a review trigger and note the direction in the Introduction.
2. Map the 5.1 modes to Developer/Deployer in a NOTE.
3. Rate criticality using the Bill’s harm factors so one assessment serves both regimes.
4. Do not use “risk appetite” for classification; the Bill does not.

All references carry the consultation-status caveat. (Amendments: Foreword, Introduction, 5.1 NOTE, 8.4, C.1A.)

CYBERSECURITYR12. Recommend controls and tools already proven in practice.

International practice offers ready material. Recommended:

1. The EU deployer duty set: follow provider instructions, assigned human oversight, monitoring with the power to suspend, incident notification, minimum log retention.
2. The buyer’s right to model documentation, secured by contract.
3. Name the deployable patterns: a model gateway (approved-model list, budgets, logging); a tool-level gateway for agent tool calls; sandboxed execution; human-approval gates; evaluation harnesses as release gates.
4. Use the Databricks AI Security Framework v3.0 (97 risks, 73 controls, including 35 agentic risks) as a completeness cross-check.

(Amendments: 7.1.2, Annex B implementation notes, OM03, VV05, Clause 1 exclusions, Bibliography.)

B. Proposed amendments by clause

Proposed text is drafting language for the Working Group to lift or adapt.

GOVERNANCEForeword and Introduction

• GOVERNANCE[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, 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, and the outcome of each review shall be recorded.”

  Reason: AI moves faster than registration cycles; a review clock keeps the code current.

• CYBERSECURITY[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.

  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.” Either tag each Annex B objective to the four functions (prevent, detect, respond, recover) or omit the four-function sentence.

  Reason: One consistent list of what is protected, a precise security scope, and a forward look at the national framework without citing a draft as law.

• GOVERNANCE[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: The code can only bind licensees; suppliers are reached through the licensee’s contracts (7.1.2).

GOVERNANCEClause 1: Scope

• GOVERNANCE[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 Clause 4) 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: Fixes the broken sentence, says who is bound, and settles what is in and out of scope.

• GOVERNANCE[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. Disclosure to users that they are interacting with an AI system is within scope (see VV05).”

  Reason: The exclusions keep ethics and content regulation out of a cybersecurity code, which prevents scope disputes at registration. One transparency measure is retained: disclosure that the user is interacting with an AI system. It costs one line in the interface, and it is already required in comparable regimes (EU AI Act Article 50) and by the transparency principle in the National Guidelines, so its absence would stand out in any comparison.

Clause 2: Normative references

• Current: Undated AISCF reference; four ISO titles listed as normative in shortened form. Proposed:

  1. Cite “AISCF:[edition/year], AI Systems Cyber Security Framework, National Cyber Security Agency (NACSA)” as the normative reference, adding: “This Technical Code incorporates the AISCF security activities identified in Annex B. Other elements of the AISCF remain voluntary national guidance.”
  2. Move ISO/IEC 5338, 23894, 27001 and 42001 to the Bibliography with exact titles.
  3. Add the deconfliction rule: “Controls already implemented and evidenced under a registered technical code or a certified ISMS conforming to ISO/IEC 27001 need not be re-implemented; the service provider shall implement and evidence only the AI-specific extension identified in Annex B.” Reason: A dated citation stops the code’s obligations changing whenever the AISCF is revised; the deconfliction rule avoids double compliance for ISO 27001-certified licensees. (The official AISCF title spells “Cyber Security” as two words.)

Clause 4: Terms and definitions

• CYBERSECURITY[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: Without the split, every unpatched vulnerability becomes a reportable incident.

• GOVERNANCE[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 Clause 6 and state the count as three classes there (the AISCF itself defines three core assets).

  Reason: Matches the international source; the AISCF itself says three assets, the draft says four.

• CYBERSECURITY[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 are detected differently, and retraining on poisoned feedback entrenches the attack instead of removing it.

• CYBERSECURITY[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 the mechanism shows where the defence sits; injection and jailbreak need different owners.

• [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: The proposed requirements use these terms; without definitions they cannot be assessed.

Clause 5: AI in the C&M sector

• GOVERNANCE[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:

  1. 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;

  2. 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

  3. 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.

  4. Within any mode, an AI system is either used internally or provided to customers as part of a licensed service, and the two orientations carry different cybersecurity obligations. The service provider shall record the orientation for each material AI system. AI provided to customers attracts the runtime output controls and interaction disclosure under VV05, higher exposure in the criticality assessment under Annex C, and, where the system is built or fine-tuned by the service provider under mode (c), the fuller set of design, validation and documentation obligations of a developing party; AI used internally carries the baseline obligations of its mode and criticality.

  Within any mode and orientation, 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 classify any system: how it arrived, and who it faces. Each mode settles who holds the model, the data and the pace of change; the orientation in (d) then settles the second half of the duties, because AI provided to customers carries more obligations than AI used internally.

• [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: One table cannot drift out of sync with itself; the added rows reflect what operators actually run.

• CYBERSECURITY[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: These systems face a live human adversary every day; testing should match that.

• CYBERSECURITY[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: A threat is more serious when the system can act; the reference IDs keep the list maintainable.

• GOVERNANCE[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: Names who signs, who accepts risk, and lets small licensees combine roles.

Clause 6: Principles, assets and lifecycle (presented as the proposed structure)

Clause 6 is proposed to be restructured, so the changes are shown against the proposed structure rather than as line edits. One reorder and four upgrades:

Why the reorder: the lifecycle tables refer to the three asset classes before the current 6.3 introduces them. Assets-before-lifecycle removes that forward reference and follows the AISCF’s own construction. The clause then reads: why (principles), what is protected (assets), when and how (lifecycle), how much (scaling).

• CYBERSECURITY[Principles (proposed 6.1)]

  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.” Make principle 5 testable: “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.”

  Reason: Prompt injection cannot be reliably prevented, so the design principle is to limit what a compromised output can reach; the oversight requirement makes principle 5 testable.

• GOVERNANCE[AI asset inventory (proposed 6.2)]

  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 orientation (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 ID ties all evidence to one system; the use case is what gets risk-assessed (one model, two uses, two risk profiles); and requiring the documentation outcome, with the AI-BoM as a NOTE, matches how ETSI EN 304 223 handles it.

• CYBERSECURITY[Prompts and embeddings (proposed 6.2.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. Embeddings shall inherit the classification and handling requirements of their source data.”

  Reason: A prompt edit can switch off safety behaviour without any code change, and embeddings can be inverted to recover their source text. Both controls reuse practices licensees already run: version control for prompts, classification inheritance for embeddings.

• [Agents: a tested stop mechanism (proposed 6.2.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: A stop mechanism that is recorded but never built or tested is not a control.

• [Lifecycle baseline and change classes (proposed 6.3 and 6.3A)]

  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 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). 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: Says what an assessor tests against, gives everyday changes a proportionate route, and forces a fresh look when a system’s control or purpose changes.

• GOVERNANCE[Risk-based scaling (proposed 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: Risk, not licence class, should set the depth of controls.

NOTE: Other sections of these comments cite the draft’s current numbering; cross-references are resolved by the editor on adoption of the reorder.

Clause 7: Deployment landscape

• GOVERNANCE[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 list to classify against, and outsourcing never transfers accountability.

• GOVERNANCE[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: Turns 7.1’s “determine” duties into a document an assessor can review.

• GOVERNANCE[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:

  1. security requirements consistent with the applicable objectives of Annex B;
  2. notification of security incidents affecting the service within a defined period;
  3. advance notification of material model or service changes, and model-version pinning where the provider offers it;
  4. restriction on use of service-provider and subscriber data for provider training without documented agreement;
  5. audit or assurance rights, for which current ISO/IEC 27001 or ISO/IEC 42001 certification or an equivalent independent assurance report may be accepted;
  6. exit, data-return and portability terms; and
  7. provision of model documentation covering capabilities, limitations, intended and prohibited uses, evaluation summaries and integration guidance.

  Reason: Contracts are how this code reaches suppliers; item (g) secures the model documentation buyers need.

• CYBERSECURITY[Table 8, rows 3 and 6]

  Proposed:

  1. 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.
  2. Row 3 (edge), add: signed model artefacts verified on-device before load; on-device model confidentiality across the deployed device population.
  3. Add a NOTE describing the central LLM gateway pattern (authentication, per-tenant rate limiting, prompt and completion logging, redaction, cost caps, enforcement of the approved-model allow-list) as a recommended implementation architecture.

  Reason: These two deployment models change fastest; the gateway pattern enforces several controls at once, including the approved-model list that stops shadow AI.

• CYBERSECURITY[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:

  1. Level 1 - Assistive. The system produces information or recommendations only; all actions are taken by humans.
  2. Level 2 - Human-approved action. The system proposes actions that are executed only upon human approval before execution.
  3. 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).

  NOTE: Service providers may use available regulatory sandbox arrangements to trial Level 3 automation under supervision before production authorisation.

  Reason: A system that advises and a system that acts are different risks; the autonomy level is what criticality and several threats key on.

Clause 8: Risk scenarios and measures

• CYBERSECURITY[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: Delivers the structure 5.3.2 already promises; stating impact in regulated-service terms is what makes this a sector code.

• CYBERSECURITY[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: Each threat sits with the asset where the weakness is, so the fix lands with the right owner.

• CYBERSECURITY[8.1, additions]

  Proposed: Add four threats:

  1. Indirect prompt injection via retrieved or processed content (own entry; 8.3 h covers only the stored knowledge-base variant).
  2. Insecure output handling: model output flowing unencoded into HTML, SQL, shell or downstream systems.
  3. Tool-use and function-calling abuse: measures are tool allow-lists, least-privilege credentials, human approval for consequential actions per 7.4.4, and treating tool descriptions and retrieved content as untrusted.
  4. Unbounded consumption: per-key quotas, token ceilings, spend alerts.

  Develop “agentic AI abuse” into three entries:

  1. persistent memory poisoning;
  2. tool misuse and excessive agency; and
  3. tool-chain trust exploitation, drafted as two mechanisms along the direction of trust: tool-side (poisoned tool definitions and descriptions; controls: supply-chain vetting, tool-manifest integrity) and client-side (connection to a malicious tool server, client-side code execution, data leakage; controls: sandboxing, egress control, allow-listed connections).

  Add inter-agent communication risks, noting that fabricated output from one agent, consumed as ground truth by another, amplifies the confabulation entry in 8.2.

  Reason: These are the attacks operators actually see; splitting tool-side from client-side matters because the fixes have different owners.

• CYBERSECURITY[8.2, additions]

  Proposed: Add:

  1. Model backdoors: trigger-conditioned behaviour that passes accuracy validation; mitigations are provenance and trigger-scanning.
  2. Model serialization attacks under compromised repositories: safe serialization formats (safetensors, ONNX); no pickle-based artefacts from untrusted sources; artefact scanning.
  3. A note that multi-turn jailbreaks defeat single-turn input filters.
  4. Under poisoning, distinguish web-scale pre-training poisoning from fine-tuning and feedback poisoning.

  Reason: These are published attack mechanisms with reference identifiers. The serialization measure needs only a file-format restriction (safetensors or ONNX instead of pickle), and it closes a path where loading a model file executes attacker code.

• CYBERSECURITY[8.3, addition]

  Proposed: Add training-data extraction via memorisation.

  Reason: This is the privacy attack that actually leaks content.

• RISK[8.4]

  Current: “documented risk assessment” with no owner, approver or cadence; applicability and significance determined through the organisation’s risk appetite.

  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 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. The assessment and any residual-risk acceptance shall be approved by the authorities defined under 5.4.3.

  NOTE 1: 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.

  NOTE 2: 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: Gives the risk assessment an owner, a schedule and an approver. Classification follows defined harms, which are objective and comparable across licensees; risk appetite applies only to the decision to accept residual risk, and only by the defined authority. Note the fourth harm (breaking any written law) can pull data-protection and licence breaches into a harm pathway.

• CYBERSECURITY[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: When AI acts on the live network, poisoned data becomes a network incident. This is the content only a telco code can provide.

• GOVERNANCE[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 compliance consists of and what evidence supports it, reuses the Statement of Applicability mechanism ISO 27001-certified licensees already operate, and sets a defined transition period (12 months for the inventory and ratings, 24 for full High/Critical conformity).

CYBERSECURITYAnnex B

• GOVERNANCE[Status and structure]

  Proposed:

  1. Mark “(normative)” and retitle “Control objectives for the 42 AISCF activities”.
  2. Restructure each table to: Ref ID | Activity | AI assets | Control objective (a testable outcome in “shall” form) | Expected evidence | Applicability (activity-conditioned) | Implementation notes (informative; current tool names become examples here).
  3. State physical controls only where they carry weight (DP02, OM02, RT01, RT03, CR06), with a general reference to ISO/IEC 27002 physical controls in the preamble.
  4. Replace licence-category applicability with conditions such as “applies where the service provider develops, fine-tunes or self-hosts models” or “applies at criticality High and above”.
  5. 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.
  6. 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 affects staff.

  Reason: One restructure delivers R1, R4 and R5, and avoids making certified licensees do everything twice.

• CYBERSECURITY[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: Points the control at the systems actually under attack, and puts testing where testing happens.

• CYBERSECURITY[DD06]

  Proposed: “Threat-modelling methodology (e.g. STRIDE) informed by adversarial-ML knowledge bases (e.g. MITRE ATLAS, NIST AI 100-2).” For agent systems, CSA MAESTRO may be used alongside STRIDE.

• CYBERSECURITY[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), including the measure: “customer-facing AI systems in licensed services shall inform users that they are interacting with an AI system”. 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: Pre-release evaluation and runtime guardrails have different owners and produce different evidence, so they need separate provisions. The disclosure measure costs one interface line and matches EU AI Act Article 50 and the National Guidelines’ transparency principle. The regurgitation test checks whether a model reproduces personal data it was trained on, which also supports PDPA obligations.

• CYBERSECURITY[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: As drafted, every automated retrain would need committee approval; the registry with a pre-approved envelope resolves that, and four controls become auditable through one mechanism.

• CYBERSECURITY[OM03]

  Proposed: Define the minimum AI log record per inference or agent action:

  1. request identifier;
  2. model and prompt version;
  3. tool calls and their results;
  4. guardrail verdicts;
  5. token counts;
  6. agent reasoning or plan traces, where the runtime exposes them; and
  7. 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”).

  Records are retained for not less than [six (6)] months or the period required under applicable instruments, whichever is longer. SIEM integration stays as an implementation note.

  Reason: Says exactly what to log and for how long; the reasoning trace is the difference between knowing an agent acted and knowing why.

• CYBERSECURITY[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.”

• CYBERSECURITY[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: Without a rigour floor, a one-day scan passes as testing; the tiers keep cost proportionate.

• CYBERSECURITY[Additional control groups]

  Proposed:

  1. Under DD04/DP02: multi-tenant GPU isolation; driver and container-toolkit patching; no unauthenticated ML service endpoints.
  2. Under DD01/DD05: vector-store authentication; tenant and collection separation; integrity and change control on corpus ingestion; embedding classification.
  3. Under DD05/OM02: per-agent tool allow-lists and least-privilege tool credentials per 7.4.2; egress controls on agent-initiated network access.
  4. In the implementation notes, name the current patterns: the model gateway (approved-model allow-lists, per-tenant budgets, central logging); the tool-level gateway (which tools an agent may invoke, under whose identity); sandboxed execution for agent code; human-approval gates for consequential actions; evaluation harnesses run as release gates.

  Reason: Clause 8 names these threats; this gives them controls, using patterns available today.

• CYBERSECURITY[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: Deleting a database row does not delete what a model learned from it; the code should say so honestly.

RISKAnnex C

• RISK[C.1/C.2]

  Proposed:

  1. Add sample likelihood and impact scales (including persistence: the cost and time to remediate where remediation means retraining or replacement) and a sample matrix, marked adaptable.
  2. Add C.1A Criticality assessment: rate each system on service-disruption impact, subscriber scale, data sensitivity and autonomy level, recording also the harm factors used in the proposed national framework (likelihood; severity and scale; duration and reversibility).
  3. Give the rating consequences: 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.
  4. 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).”
  5. 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: Makes assessments repeatable and comparable, gives the criticality rating consequences, and avoids writing the same assessment twice for different regimes.

• RISK[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: Scores these threats the way they actually behave.

• RISK[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: Licensees will copy the worked example, so it must model the method properly, including the hard case.

GOVERNANCEBibliography

• Proposed: Populate with:

  • the four ISO/IEC standards with exact titles; PDPA 2010 (Act 709); ISO/IEC 27090 (under development);
  • OWASP Top 10 for LLM Applications 2025; OWASP Top 10 for Agentic Applications 2026 (ASI01 to ASI10, December 2025); MITRE ATLAS; NIST AI 100-2e2025; CSA MAESTRO;
  • the Databricks AI Security Framework v3.0 (March 2026; 97 risks, 73 controls, including the 35-risk agentic extension), as a completeness cross-check for Clause 8;
  • the MIT AI Risk Repository and the IBM AI Risk Atlas (risk-taxonomy libraries); Canada’s Algorithmic Impact Assessment (precedent for a scored criticality instrument; verify the current version before citing);
  • the National Guidelines on AI Governance and Ethics; O-RAN WG11 security specifications; applicable registered MCMC technical codes; and the AISCF citation and permission for Figure 1.

Editorial corrections (title wording, drafting-note removal, cross-references, abbreviations, spelling and numbering) are compiled separately for the drafting editor and are not itemised here.

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, the proposed AI Governance Bill (consultation status) and MCMC technical-code and assessment regimes are drafting observations, not legal or regulatory advice.