[Theme]

SG17_CRAMMS_special_session_v1.1.pdf

Theme Name

Security of agentic AI: from benchmarks and community controls to evidence of trust

Proposer(s)

Arnaud Taddei, Chair, ITU-T Study Group 17.

I am raising this as a gap to be filled, not as a claim on leadership. The theme needs people I do not have, above all AI specialists in the narrow sense: people who build and run model evaluations, red-team frontier models, or work on interpretability. See "Who needs to be in the room" below.

Summary

FG-TIDA has more than forty themes. Many of them touch security: attestation (#22), privilege lifecycle (#23), runtime enforcement (#26, #6), ecosystem defence (#13), model-level foundations (#11), supply chain (#35). None of them asks the question underneath all of them: when someone claims an agentic AI system is secure, what evidence supports that claim, and how is that evidence put together?

Three bodies of work exist today, built by different communities that rarely read each other:

1. LLM and agent benchmarks. They measure specific properties under specific conditions: resistance to prompt injection in tool-using agents, refusal of harmful requests, cyber-offensive capability, unsafe actions by computer-use agents, and so on.
2. Community security work, above all OWASP. It names the risks, the controls and the tests for LLM and agentic applications.
3. The CRAMMS series of ITU-T SG17. It defines what a security capability is, how a security design is reasoned about, and how secured things compose. TRAMMS, its extension to trustworthiness, is coming soon.

Each is necessary, but none is sufficient on its own. A benchmark score is a measurement, not a proof of trust. A list of risks is not an architecture. A meta-model needs measurements to be anything more than a theory. This theme proposes to connect the three, so that benchmark results and community controls can be composed into evidence of trust that a relying party, an operator or an auditor can use.

Scope / Open Questions

1. Benchmarks, and why their composition is the hard part

A single benchmark answers a narrow question: this model or agent, in this configuration, against this threat model, on this test set, at this moment. A trust claim is about something else: this system, deployed here, for this purpose, under these conditions. Getting from the first to the second needs composition, and nobody has written the composition rules down.

Open questions:
- From score to claim. Which claim is a given benchmark result actually evidence for, and with what validity limits? A low attack-success rate on one injection suite is not evidence of resistance to injection in general.
- Composition across benchmarks. How are results from several benchmarks combined into one claim? Combining scores across security, safety, privacy and robustness is itself an aggregation problem: it falls directly under the collective-choice framework of #18 and its trade-offs.
- Composition across components. A model, a harness, tools, memory and other agents each have their own evaluation. What can be said about the whole? The Juvenal constraint of X.arch-design applies: local proof is possible, whole-system measurement is not. The theme must say exactly what can be claimed, without overselling.
- Validity over time. Models are updated silently, and benchmarks get contaminated or gamed. A benchmark that becomes a target stops measuring. How long is a result valid, and what invalidates it (see #37 on continuity)?
- Binding the result. A benchmark result is only evidence if it is bound to the exact artefact evaluated, the method and the moment. This joins remote attestation (#22), supply chain and AIBOM (#35), evidence grading (#42, #43) and population-scale reading (#21).
- Coverage. Most benchmarks measure the model or the single agent. Very few measure multi-agent behaviour, delegation or the agent acting on behalf of a human principal, which is exactly where FG-TIDA's problem lies.

2. OWASP and the community work we should build on, not redo

The OWASP GenAI Security Project already gives this field much of its shared vocabulary:
- the Top 10 for LLM Applications (2026 edition);
- the Top 10 for Agentic Applications 2026 (ASI01 to ASI10, from agent goal hijack to rogue agents), produced by its Agentic Security Initiative;
- the Agent Control Standard (ACS);
- the GenAI Security Industry Framework Crosswalk;
- the AI Bill of Materials, red-teaming and evaluation, and threat-intelligence initiatives (quarterly exploit roundups);
- the AI Vulnerability Scoring System (AIVSS).

Separately, the OWASP AI Testing Guide (v1, November 2025) offers a test methodology for AI trustworthiness. The OWASP AI Exchange feeds the international and European standards track: ISO/IEC 27090 and the CEN-CENELEC JTC 21 work on the AI Act security standard.

The principle is the one SG17 applies to itself: reference and specialise, never restate. FG-TIDA should not write a new risk list or a new test guide. What it can do, and what nobody else is positioned to do, is:
- map each OWASP risk and control onto a typed security capability: its purpose, how it is realised, what level it reaches, and how it is represented for machines;
- identify what evidence would show that a control is in place and effective, and which benchmarks or tests produce that evidence;
- record the gaps: risks with no control, controls with no test, tests with no agreed composition.

Other relevant work exists in ISO/IEC JTC 1/SC 42 and SC 27, NIST, ETSI TC SAI, the IETF, CAICT's evaluation work and the AI safety institutes. A first deliverable should map this landscape, not duplicate it.

3. CRAMMS, and soon TRAMMS: the frame that makes the evidence composable

What CRAMMS is. CRAMMS stands for Cyber security reference architectures, methodologies, models and strategies. It is a series of ITU-T SG17 texts in Question 1/17, presented to the study group in a special session in Chongqing on 10 September 2026 (deck attached). Its ambition fits in one line: generalise X.800.

In 1991, X.800 gave security a normative footing on one agreed object: the OSI open system, decomposed into seven layers. Since then the objects to secure have multiplied: cloud, IoT, vehicles, 5G and 6G, distributed ledgers, digital twins, AI-native and now agentic AI. The underlying meta-model never moved. Each domain therefore invented its own definition of the object, the boundary, the security capability and composition. Fragmentation was the arithmetically inevitable result.

How it is built. Three self-imposed rules:
- Reference and specialise, never restate. For example, ISO/IEC/IEEE 42010 is referenced and specialised for security, not rewritten.
- One question, one home. Each document answers exactly one question, and no two answer the same one.
- A criterion, not a taste. A written test decides which layer a document belongs to.

Five layers, ten work items:

The pieces this theme needs most:
- X.secadef defines a security capability by four parts: purpose (the outcome), realisation (the means), level (the degree achieved, against a graded scale) and representation (a machine-readable description). The "level" part is where benchmark evidence belongs, and the "representation" part is what lets an agent discover, compare and compose capabilities.
- X.secadef's common security model distinguishes endogenous capabilities (inside the boundary of the thing secured) from exogenous ones (outside it). They are linked by a symbiotic relationship at the boundary, as with TLS and PKI. Model-level guardrails are endogenous; ecosystem defence (#13) is exogenous. Both are needed, and the model says how they relate.
- X.secadef's meta-model sets twelve requirements and evaluates twenty-two existing security models against them. None satisfies all twelve. Composition (R6) is the least served of all: almost nothing in the field says what happens when two secured things are put together. That is exactly the problem benchmarks face.
- X.arch-design has 28 principles, 24 considerations, 18 best practices and one constraint, with normative composition rules. Its rule RZ5 already requires identity verification for every class of subject, humans and machine-to-machine principals alike. It is the closest thing the series has to a rule for agents.
- X.dmst makes the trade-offs between security, privacy, safety and human rights explicit through a trustworthiness aggregation function. This is the same mathematics as #18.

What CRAMMS itself admits it lacks. The chain from a security concern to a requirement to a control is not yet written down anywhere in the series. This theme would add the last link, from a control to the evidence that it works, and benefit directly from closing the gap.

TRAMMS. CRAMMS has done this work for one element of trustworthiness: security. The same work is needed for safety, reliability, resilience, availability, privacy, accountability, transparency, explainability, fairness, human oversight and traceability. It is needed again for the tensions between them: twelve elements on a conservative list give sixty-six pairs, and none of these pairs is written down today. SG17 is preparing this extension (T for trustworthiness) in Question 1/17. This theme would be its first real test case, because evidence of trust for an agent is never evidence of security alone.

4. What exploration would need to produce

1. A landscape: benchmarks, OWASP outputs and SDO work, mapped against the CRAMMS capability model, with gaps recorded rather than ignored.
2. An evidence model: what a benchmark result must carry to count as evidence (artefact, version, configuration, threat model, method, moment, validity limits).
3. Composition rules: how evidence from several benchmarks, and from several components, combines into a scoped claim, and what can never be claimed.
4. A worked example: one FG-TIDA use case, with an agent acting on behalf of a human principal, carried from OWASP risk through capability and benchmark to the final claim.

5. Who needs to be in the room

• AI specialists in the narrow sense. Evaluation scientists, people who design and maintain benchmarks, frontier-model red-teamers, interpretability researchers. This is the expertise FG-TIDA has least of today, and the theme fails without it.
• OWASP contributors, ideally from the Agentic Security Initiative, the AI Testing Guide and the AI Exchange.
• Security architects who know the CRAMMS series or are willing to read it.
• Someone who has shipped and operated an agent in production, and one person from an assurance or audit function who has to rely on the evidence.

Related Work

• ITU-T SG17, Q1/17: the CRAMMS series (X.cramms, XSTR.CRAMMS, X.secadef, X.arch-design, XSTR.trust, X.dmst, X.cs-ra, XSTR.cs-uc, XSTR.cs-sc, X.supp-psam) and the TRAMMS extension in preparation. Q16/17: AI security work items, including XSTR.magAI-behavior.
• OWASP GenAI Security Project: Top 10 for LLM Applications 2026, Top 10 for Agentic Applications 2026, Agent Control Standard, Industry Framework Crosswalk, AIBOM, AIVSS. OWASP AI Testing Guide v1. OWASP AI Exchange.
• Benchmarks (indicative, not exhaustive): AgentDojo (prompt injection in tool-using agents), HarmBench (harmful-request compliance), CyberSecEval (cyber risk and capability), OS-Harm (computer-use agents).
• Standards: ISO/IEC 27090, CEN-CENELEC JTC 21 (AI Act security standard), ISO/IEC JTC 1/SC 42 and SC 27, ISO/IEC/IEEE 42010, NIST AI RMF, ETSI TC SAI.

Related Themes

• #18 (collective-choice formalism): combining benchmark results across characteristics is an aggregation, and the same mathematics applies.
• #11 (model-level trust foundations) and #13 (ecosystem-level agent defence): the endogenous and exogenous halves of the same picture.
• #22 (remote attestation) and #35 (supply chain, AIBOM): binding evidence to the artefact.
• #21 (population-scale evaluation), #42 and #43 (evidence grading): reading and grading the evidence.
• #6 (runtime verification) and #16 (human oversight): where the evidence is used at the moment of action.
• #37 (moderators of trustworthiness): why results expire.

This theme replaces none of these. It offers the evidence layer they share.

Discussion

As with #41, I am not pushing for a working group now. The theme can mature first, and the right moment will be when the AI evaluation expertise has joined. The draft charter below is offered so that, when that moment comes, the group does not start from a blank page.

Comments, disagreement and, above all, names of AI evaluation specialists willing to join are very welcome.

Annex — Draft future charter (for a working group, later)

Name. Evidence of Trust for Agentic AI Security (working title).

Purpose. To define how results from benchmarks, tests and community controls are turned into scoped, composable and verifiable evidence that an agentic AI system meets stated security and trustworthiness claims.

Guiding principles.
1. Reference and specialise, never restate. Existing risk lists, test guides and benchmarks are inputs, not rivals.
2. Evidence, not assurance. Every claim names the evidence behind it, the artefact it is bound to, and the limits of its validity.
3. Composition is explicit. No result is extended beyond what it measured without a written composition rule.
4. Honesty about limits. Local proof is possible; whole-system measurement is not. Deliverables say what cannot be claimed.
5. Neutrality. Vendor-, geography- and culture-neutral. No leaderboard, no ranking of products.

In scope.
- Mapping benchmark families and OWASP risks, controls and tests onto the CRAMMS capability model (purpose, realisation, level, representation).
- An evidence model for benchmark and test results.
- Composition rules: across benchmarks, across components (model, harness, tools, memory, other agents), and over time.
- The validity, contamination and expiry of evidence.
- Interfaces with attestation, supply chain, evidence grading, runtime verification and human-oversight work in FG-TIDA.

Out of scope.
- Designing new benchmarks or running evaluations as a service.
- Certification schemes, conformity assessment and regulatory interpretation (see #41).
- Ranking of models, products or vendors.
- Restating OWASP, ISO/IEC, NIST or ETSI material.

Candidate deliverables (all Focus Group outputs, feeding back to ITU-T SG17).

Sequence. D1 first. D2 and D4 in parallel. D3 once D2 is stable. D5 to test D2 to D4. D6 continuously, with a consolidated input before the end of the Focus Group's term.

Relationships.
- Inside FG-TIDA: #6, #11, #13, #16, #18, #21, #22, #35, #37, #42, #43.
- ITU-T: SG17 Q1/17 and Q16/17; the AI-related Focus Groups.
- Outside: the OWASP GenAI Security Project, OWASP AI Exchange and AI Testing Guide; ISO/IEC JTC 1/SC 42 and SC 27; CEN-CENELEC JTC 21; NIST; ETSI TC SAI; the IETF; the AI safety institutes; academic benchmark authors.

Membership the group must have. At least two AI evaluation specialists, at least one OWASP contributor, at least one security architect familiar with CRAMMS, at least one operator of a production agent, and at least one assurance or audit practitioner. If the first category is missing, the group should not start.

Leadership. To be found. The proposer does not seek it.

Success criteria.
- A relying party can read a claim about an agentic system and know which evidence supports it and what it does not cover.
- At least one OWASP risk category is traced end to end, from risk through capability, control and benchmark to claim.
- The results are taken up in SG17 texts and acknowledged by the communities whose work they build on.

Attachment: SG17 CRAMMS special session, Chongqing, 10 September 2026 (deck, v1.1)