proposal: reference ATR community detection rules in A2A security guidance

[eeee2345]

The A2A security guidance (docs/topics/security-and-trust/) covers authentication and transport security well. One gap: there is no reference to runtime threat detection for A2A message content — specifically, attacks that target the agent payload itself rather than the channel.

ATR (Agent Threat Rules) is an MIT-licensed corpus of 425 detection rules for AI agent threats: prompt injection via A2A messages, tool-call hijacking, credential exfiltration in artifacts, and inter-agent manipulation patterns. It is referenced in the OWASP Agentic Security Handbook and deployed in production by Microsoft Copilot SWE Agent and Cisco AI Defense.

Proposal: define ATR integration as an A2A Extension rather than a protocol-level requirement. This keeps the core spec minimal and transport-agnostic while letting implementations that need runtime detection opt in. An extension keeps the A2A protocol clean and avoids over-constraining deployments that run fully trusted internal agents.

[msampathkumar]

Hi @eeee2345 Thank you for request! This is a great proposal. Here is a question. In a way, A2A sits on top of Agentic Applications to be a communication layer. With A2A layer itself there is no LLM involved. So should this agent-threat-rule be part of A2A Protocol definition?

As an A2A Extension, I would say Yes. As A2A standard, I need to check.

[eeee2345]

@bbednarski9 — the A2A Extension path makes sense. The detection layer sits at the agent boundary rather than inside the protocol itself, which is the right separation. An extension keeps the A2A spec clean and lets implementations opt into detection without it becoming a protocol requirement.

Happy to draft the extension spec once there is a defined extension mechanism in the repo. If you have a pointer to how extensions are being scoped, I will follow that shape.

[bbednarski9]

@eeee2345 - thanks for the context, acknowledged. Let me know if you need anything specific on my end.

[eeee2345]

@msampathkumar — Extension is the right call. Keeping detection out of the core protocol spec means A2A stays minimal and transport-agnostic; implementations that need runtime threat detection can opt in without it becoming a hard protocol requirement.

That flexibility matters in practice: some A2A deployments run fully trusted internal agents, others face untrusted external callers — a protocol-level mandate would over-constrain the first group. An extension lets each deployment decide.

Happy to draft an extension spec once there is a defined extension format in the repo. Is there an existing extension template or schema to follow, or is the format still being shaped?

[eeee2345]

@bbednarski9 — apologies for the misfire tag. For context: ATR is pursuing two parallel integration tracks — NeMo as a 3P PreInvoke plugin (following your guidance on #1955), and A2A as an optional extension at the message-content detection layer. Different surfaces, no overlap.

[eeee2345]

@msampathkumar — wanted to share two concrete cases from the last two weeks that motivate the Extension shape, since the question of "what would runtime detection actually catch at the A2A boundary" is the practical version of "should this be in the protocol or an extension."

Case 1 — Microsoft Semantic Kernel CVE-2026-26030 + CVE-2026-25592, 2026-05-07 → 2026-05-11.
MSRC published the two SK CVEs on May 7. Microsoft Copilot SWE Agent opened microsoft/agent-governance-toolkit#1981 on May 11 with regression-test fixtures presuming ATR detection. ATR v2.1.2 (rules ATR-2026-00440 + 00441) shipped to npm 2h 16m later, with the two CVE payloads covered as true_positives and the safety gate passing. Microsoft Copilot then ran the fixtures against the new rules in-toolkit.

The relevant property for A2A: the detection layer was decoupled from the protocol layer. Microsoft did not wait on a protocol revision to ship regression coverage — they pulled the rule corpus through an existing tool's integration surface. If runtime threat detection lived inside the A2A spec, that 2h 16m loop becomes a multi-week protocol-revision cycle.

Case 2 — PraisonAI CVE-2026-44338, 2026-05-16 → 2026-05-17.
Sysdig published exploitation telemetry showing CVE-Detector/1.0 scanning public-internet PraisonAI instances 3h 44m after GHSA-6rmh-7xcm-cpxj. The unauthenticated /agents and /chat endpoints accepted POST requests with no auth header — the kind of payload that an A2A-equipped agent caller could trigger inadvertently or maliciously. ATR rule ATR-2026-00527 covers this surface (config-without-auth + tool-call-without-auth + content describing the surface).

The relevant property for A2A: the detection signal is at the message content layer (POST body, tool-call shape, response shape), not at the transport layer. A2A as transport is correct to stay transport-agnostic; an Extension that runs over the message content gives implementations the option without making it a hard requirement for the trusted-internal-agents case.

Concrete proposal for the Extension:

• Surface: a security_extension.threat_detection block in the A2A message envelope, opt-in per deployment.
• Content: lists matched rule IDs from any conforming detection layer (ATR, custom, vendor-specific), plus a bundle hash for reproducibility. The Extension defines the envelope, not which rules; deployments wire whatever detector they want behind it.
• Producer: the calling agent's runtime, before the message leaves the boundary. Or the receiving agent's runtime, before dispatch. Either side can attach.
• Consumer: any A2A endpoint that wants to enforce or audit detection signals. Default behavior is informational; deployments that want enforcement opt in.

This keeps the A2A protocol minimal (extension is optional), keeps detection out of the standards path (the registry of rule IDs lives elsewhere — ATR for our case), and lets the trusted-internal-agents case skip the layer entirely.

If pointing me at how Extensions are currently scoped in the A2A repo (existing templates, schema conventions, an example extension PR to mirror) would help, that's the unblocker on my end. Happy to draft the spec shape against whatever pattern is current.

[bbednarski9]

@eeee2345 lets keep sub-package convo on: NeMo-Agent-Toolkit

[chopmob-cloud]

The Extension shape is the right architectural call, and the two concrete CVE cases @eeee2345 surfaced (Microsoft Semantic Kernel CVE-2026-26030 + CVE-2026-25592) are exactly the runtime-detection cases an A2A boundary needs to cover. One adjacent piece of ecosystem infrastructure worth surfacing for the working group: ATR's detection rules pair naturally with an adversarial test corpus, and the AlgoVoi Agent Trust Bench (ATB) is publicly live as that complement.

The bench at agent-trust-bench.algovoi.co.uk runs 132 adversarial and benign x402 profiles across 30 threat categories, with the same profiles exposed on 8 chains (Base, Algorand, Solana, Stellar, Hedera, Tempo, VOI, ARC testnet). Provider-neutral by design: works against any x402 facilitator, no AlgoVoi-account dependency, no signing keys held server-side, $1 USDC cap per call (enforced at server startup), 30-day responsible-disclosure window, all proceeds donated. Machine-readable discovery for CI / automation at:

GET https://agent-trust-bench.algovoi.co.uk/.well-known/x402.json

Complementary positioning vs ATR:

• ATR catches threats at runtime via its 425 detection rules (prompt-injection patterns, tool-call hijacking, credential-exfiltration patterns).
• ATB tests whether an agent CORRECTLY REFUSES the adversarial payments those threats produce, end-to-end through the x402 flow.
• Together: rules + corpus = detection + behavioural validation.

An A2A agent that adopts the ATR Extension for runtime detection gets the rules side. Running the same agent in ATB's policy persona (zero adversarial profiles settled + at least 90% correct decisions across the 132-profile sweep) gives the behavioural-validation side. The two compose without overlap: ATR is the runtime gate; ATB is the regression corpus.

For @msampathkumar's "protocol vs extension" question: the same shape that frames ATR detection-rules as out-of-protocol can frame ATB adversarial-test-corpus as out-of-protocol. A deployment that opts into ATR for runtime detection MAY also opt into running ATB in CI for behavioural regression coverage. Neither sits inside the core spec; both are referenceable from the security guidance as ecosystem-infrastructure that A2A implementations can cite.

For implementations that test against the bench:

python bench_runner.py --persona policy

A badge for downstream agent frameworks that pass the standard suite:

[![Agent Trust Bench](https://img.shields.io/badge/Agent_Trust_Bench-Tested-238636)](https://agent-trust-bench.algovoi.co.uk)

ATB is ecosystem infrastructure (MIT licence on the runner + Apache 2.0 on the AlgoVoi-published substrate it composes with), maintained by AlgoVoi's APM (Agent Payment Module) -- the production agentic-payment platform at api.algovoi.co.uk that runs the receipt-format substrate the bench is built to test agents against. APM runs the same x402 / AP2 / MPP surface on the same 8 chains the bench exercises.

A2A-specific profile suggestions are welcome if the WG identifies particular adversarial patterns ATR's detection layer covers that the bench's behavioural corpus should also cover empirically. The cross-validation of ATR rules vs ATB profile catches is the natural CI loop for an A2A deployment that adopts both extensions.

-- AlgoVoi

[andysalvo]

Two layers worth separating because they compose: payload-threat detection (adversarial content, jailbreak vectors) is one plane. Canonicalization-integrity testing (timestamp precision attacks, replay windows, extra-field injection, key-order ambiguity) is a separate plane underneath it.

We've been shipping the integrity layer: verify.crestsystems.ai, 12 vectors with cross-language runners, plus 8 A2A cross-validation vectors covering the transactional lifecycle. Foundation PR #2398 has the x402 set.

A threat-detection rule firing on a message whose canonical form is ambiguous has a substrate problem. Happy to contribute canonicalization vectors as a precondition tier if useful.

[chopmob-cloud]

Updating the ATB data since the original comment -- profile count is now 138 (30 threat categories), and OWASP LLM Top-10 alignment is formally mapped and documented at docs.algovoi.co.uk/agent-trust-bench.

The mapping covers 8 categories with explicit per-profile assignment:

• LLM01 Prompt Injection -- injection, jailbreak-meta, replay, jailbreak-sequence
• LLM07 Insecure Plugin Design -- malformed schema, structural placement, amount formatting
• LLM08 Excessive Agency -- orchestrator-auth bypass, capability-inject, commitment-forcing
• LLM09 Overreliance -- authority spoofing, urgency, mismatch, currency drift
• LLM06 Sensitive Info Disclosure -- credential exposure, key-leak probes
• LLM02 Insecure Output Handling -- response validation, output injection
• LLM05 Supply Chain -- dependency confusion, tampered tool response
• FATF -- sanctioned counterparty, jurisdiction override, velocity

Empirical result under policy persona (Claude Haiku, 200+ runs): 128/138 pass. The 10 failures cluster in malformed-schema and context-stripping categories -- the same surface ATR's detection rules cover at runtime. That clustering is the useful data point for the working group: where detection rules fire, behavioural validation tends to fail too. The two layers are tracking the same failure modes from different directions.

Run tracking is now live: POST /runs to create a named run, tag requests with X-ATB-Run-ID, view the per-profile breakdown at /runs/{id}/report. Straightforward CI integration -- one run ID per pipeline execution.

[woshilaohei]

The Extension shape is the right call — keeping A2A minimal and letting implementations opt into threat detection preserves protocol flexibility.

One architectural question worth surfacing explicitly: where does safety live in the stack?

The ATR integration as proposed catches known threat patterns at the message-content layer. That's necessary. But the PipeLeak and ShareLeak disclosures last week showed that even well-guarded messages can lead to compromised actions if the safety boundary is at the wrong layer.

Two different security postures:

• Message-layer detection = scan what comes in (ATR/ATB approach — pattern matching on known threats)
• Action-layer enforcement = constrain what goes out (regardless of what came in, the agent can only execute within defined boundaries)

They're not competing — they're complementary. But most agent security stacks I see are 90% message-layer and 10% action-layer, which means once something bypasses the message scanner (novel injection, encoding trick, multi-step attack), there's nothing catching it at execution time.

The Forrester AEGIS framework puts this as "least agency" — constrain decision scope, not just access. The OWASP agentic security handbook calls it "defense in depth at the action boundary."

For the A2A Extension specifically, it might be worth defining two optional sub-extensions: one for message-content threat detection (ATR-style) and one for action-boundary enforcement. Implementations that need both get a complete stack; implementations that only need message scanning don't pay the action-enforcement cost.

We built vsos-guard as a zero-dependency action-boundary guard specifically because the message-layer-only approach leaves the hardest attacks uncaught. Happy to share architectural notes if it's useful for the Extension spec.

[chopmob-cloud]

The message/action layer framing is useful and maps onto the ATB failure data directly.

Updating the bench numbers first: ATB is now at 144 profiles / 31 categories (Phase 8 -- receipt-substrate-integrity -- added 2026-05-30). Updated docs at docs.algovoi.co.uk/agent-trust-bench.

On the layering question: the 10 ATB failures under policy persona cluster at a specific point in the stack. Prompt-injection variants at the message layer are handled correctly -- the agent rejects the adversarial payment. The failures occur when the malformed-schema and context-stripping profiles reach the decision step: the agent's output (settle or refuse) is wrong even though the input was not a novel injection. That is exactly the action-layer failure mode you are describing.

Phase 8 (receipt-substrate-integrity) was added specifically to test this surface. A valid-looking payment request backed by an invalid JWS or a non-conformant JCS canonical form should fail -- not because the message is flagged as adversarial, but because the action of settling requires substrate integrity. An agent that passes message-layer detection but settles on a malformed receipt has cleared one gate and left the action-boundary open.

The ATB profile corpus covers both planes:

• Profiles 1-120: message-content adversarial (injection, jailbreak, spoofing, relay)
• Profiles 121-144 (Phase 8): receipt-substrate-integrity (JWS/JCS validity, field injection, canonical-form attacks, nonce replay)

An implementation that passes both planes has cleared both sub-extensions. The sub-extension split you propose (message-content detection + action-boundary enforcement) matches that split cleanly.

For the Extension spec shape: the natural hook is whether the security_extension.threat_detection block @eeee2345 proposed should be two sibling blocks (threat_detection + action_boundary) or a single block with a detection_plane discriminator. Either composes with ATR rules on the message side and corpus validation on the action side.

AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition

[woshilaohei]

The Phase 8 update is a significant addition — receipt-substrate-integrity closes a gap that message-layer detection alone leaves open, and your benchmark now covers both planes explicitly.

On the profile corpus split (1-120 message-content, 121-144 receipt-substrate): This is the cleanest way to represent the two failure surfaces. Profiles 1-120 test whether adversarial content gets flagged; profiles 121-144 test whether structurally valid but cryptographically invalid payloads get actioned. The split means implementers can pass one plane and fail the other — which is exactly the right signal. An agent that clears injection detection but settles on a malformed receipt has a real vulnerability that would be invisible if the bench only measured message-layer success.

On the sub-extension question (two sibling blocks vs single block with discriminator): Two sibling blocks composes better. threat_detection and action_boundary have different consumers — the first feeds alerting and logging, the second gates execution. A discriminator in a single block forces the consumer to parse before acting, which adds latency at the enforcement point. Sibling blocks let each consumer subscribe to exactly what it needs. The ATR rules on the message side and corpus validation on the action side compose independently either way, but the sibling shape avoids coupling them in the spec structure.

One thing I want to push on: Profiles 1-120 catch adversarial content — but what about adversarial content that arrives encoded or obfuscated in a way that defeats pattern matching but not semantic intent? Base64-wrapped injection, unicode normalization attacks, ROT13-shifted instructions — these pass the message-content filter because the filter sees the encoded form, not the decoded intent. ATB's message-layer profiles appear to test the decoded semantic content, which is the right test for the agent's decision quality, but it may not test whether the input boundary could have caught the encoded form before it reached the decision layer at all.

This matters because the cost of catching an encoded injection at the input boundary (microseconds, deterministic) is four orders of magnitude cheaper than letting it reach the decision layer and relying on the agent's behavioral validation to reject it (LLM inference, token consumption, contaminated context). If ATB's message-layer profiles assume decoded input, the 120/124 pass rate might overestimate what a production deployment sees — because production inputs arrive encoded, and the first gate is a pattern matcher, not a semantic reasoner.

We're testing this exact surface with VSOS Guard — the v0.5.2 release adds encoding detection (base64, unicode escape, hex escape, ROT13, leet speak) as an input-boundary layer. The open question is how many of ATB's message-layer profiles would shift from "agent correctly rejects" to "input boundary catches before agent sees it" when encoding normalization is in the pipeline. That's the measurement that would quantify the real cost savings of the two-plane model.

[chopmob-cloud]

On the encoding question: ATB profiles are primarily semantic tests. The adversarial payload arrives at the agent in structured form. That is by design. The bench measures decision quality at the action layer, not input-boundary resilience. The pass rate does not quantify what an encoding-normalisation layer would catch upstream. That is an honest characterisation of what the bench measures.

The two measurements are complementary. VSOS Guard's encoding detection catches the encoded form before the agent sees it. ATB measures what happens when structurally valid but semantically adversarial content reaches the decision step. Neither substitutes for the other.

The cost asymmetry holds: encoding-obfuscated attacks that are catchable at the input boundary should be caught there. The 10 ATB failures are in the category that survives input-boundary normalisation: clean at the encoding layer, adversarial at the semantic layer. That is the residual surface the action layer has to cover.

On the sibling blocks: agreed on the consumer-subscription rationale.

AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition