Create Agentic AI Threat Modeling Gap Analysis (Draft v0.1).md by flucktemberg-sap · Pull Request #8 · aaif/wg-security-and-privacy

flucktemberg-sap · 2026-07-21T13:29:14Z

Here's the initial gap analysis on threat modeling for Agentic AI.

This serves as basis information for those participating in the sub-workgroup

Gap Analysis on threat modeling for Agentic AI

zeroasterisk · 2026-08-03T09:33:51Z

+
+**Finding.** Across all eight areas, the major frameworks jointly provide adequate vulnerability classification, adversary-technique coding, and architectural layering in most cases. The WG does not need to build a competing taxonomy. But the analysis surfaces real, evidenced voids of three different shapes: five areas where a concrete technical or methodological gap warrants new WG-led work; two areas where the gap is real but the architectural fix belongs to a different AAIF working group, and this WG's contribution should be the governance framing plus a handoff; and one area that is not primarily a missing-control problem at all, but an unresolved jurisdictional question between this WG and the Accuracy and Reliability WG.
+
+**Recommendation.** Adopt the existing frameworks as the WG's baseline classification system for all subsequent deliverables, and direct new WG effort at the specific voids identified in Section 6, rather than re-deriving classification work already done well elsewhere.


Agree, thank you

zeroasterisk · 2026-08-03T09:34:52Z

+
+**The structural premise underlying most of the eight gap areas.** Agentic systems share a single architectural root cause: language models process instructions and untrusted data through the same token pipeline, with no architectural separation equivalent to parameterized queries in SQL.
+
+This becomes exploitable when three conditions converge: access to private data, exposure to untrusted content, and external communication capability (Willison's "Lethal Trifecta"). Every agent with meaningful business capability has all three, and none of the three elements alone is dangerous.


zeroasterisk · 2026-08-03T09:36:00Z

+
+This is the best-covered of the eight gap areas in classification terms.
+
+**Gap:** the protocol itself, Model Context Protocol, now governed by AAIF under the Linux Foundation as of December 9, 2025, has two structural trust-model defects no framework closes: OAuth 2.1 authentication is marked *optional* in the specification, and stdio transport (the most common deployment mode) is explicitly *exempt* from the OAuth framework entirely. First-party and third-party servers are indistinguishable at the protocol level.


Re review in light of new spec, just released

zeroasterisk · 2026-08-03T09:37:42Z

+- **Host-as-issuer:** the client mints short-lived, scoped tokens for each server it spawns, instead of every server running its own authorization server.
+- **Transport-appropriate local tokens for stdio:** a lightweight, host-issued token at spawn time, instead of forcing a network-auth flow onto a local pipe.
+- **Provenance and signing for the first-party-vs-third-party problem:** supply-chain-level package signing instead of session-level authorization.
+- **Reference auth library:** AAIF ships or endorses a minimal drop-in auth sidecar so implementers are not building an authorization server from scratch.


Convenient for many scenarios and therefore a good idea, but sidecar isn't always the right answer

zeroasterisk · 2026-08-03T09:39:03Z

+
+**Gap:** OWASP names the principle, but no framework specifies a pre-deployment measurement methodology for quantifying how much agency an agent actually needs versus how much it has been granted. Without a measurement standard, "excessive" has no operational definition an auditor or procurement reviewer can apply consistently across vendors.
+
+**Severity:** High. This is an unusually tractable build-new finding: it requires a measurement methodology, not a new architecture, and the WG's own gap-analysis-and-guidance format is the right vehicle to propose one directly.


zeroasterisk · 2026-08-03T09:41:48Z

+
+Protocol-level primitives exist to narrow this gap technically (RFC 8693 token exchange with `act`/`may_act` claims; SPIFFE/SPIRE workload attestation; UCAN v1 capability tokens, specification-complete July 2025), but no IETF working group has ratified an agent-identity standard, and the median IETF timeline from draft to RFC (two to four years) makes near-term ratification unlikely.
+
+**Severity:** High. This is a build-new finding, with one caveat: per the WG's own scope division, the architectural specification work for agent identity and delegated authorization belongs to the Identity and Trust WG, not this WG. This WG's contribution should be the governance/accountability framing above, handed off via the Cross-WG Security and Privacy Review Checklist (Deliverable 5), not a competing identity architecture.


We have 4 Identity scopes:

agent as user (impersonation)

on behalf of user (delegated)

workload identity (iam)

workforce identity (agent as actor)

zeroasterisk · 2026-08-03T09:44:39Z

+
+**Gap:** this is the largest blank space identified in this analysis. No standards body has yet produced a payment-agent-specific threat classification, which means there is no OWASP code to adopt, no ATLAS technique to detect against, and no MAESTRO layer assignment to default to.
+
+**Severity:** High as a gap, but explicitly out of this WG's lane per its own scope division. The appropriate action mirrors Section 4.6: document the gap and hand it off rather than building a competing classification inside this WG. Recommend routing through the Cross-WG Security and Privacy Review Checklist (Deliverable 5) once the Agentic Commerce WG has a charter mature enough to receive it.


Check with FIDO and AP2, which was developed entirely around risk and Verifiable Intent (which is basically AP2)

zeroasterisk · 2026-08-03T09:47:11Z

You cover MCP, perhaps consider A2A (much more complicated due to multi-hop, we are about to publish a white paper) and ACP

jamesward · 2026-08-03T21:17:53Z

+
+This is the best-covered of the eight gap areas in classification terms.
+
+**Gap:** the protocol itself, Model Context Protocol, now governed by AAIF under the Linux Foundation as of December 9, 2025, has two structural trust-model defects no framework closes: OAuth 2.1 authentication is marked *optional* in the specification, and stdio transport (the most common deployment mode) is explicitly *exempt* from the OAuth framework entirely. First-party and third-party servers are indistinguishable at the protocol level.


There are valid reasons for an MCP server to be open (no auth). For instance my javadocs.dev MCP server is intended to be used by anyone without requiring auth. Not sure if something needs to adjust in this section to make sure that users know they can have public MCP servers (if that is what they want).

mindpower · 2026-08-04T16:27:26Z

+
+**Primary recommendation: adopt and extend, do not build from scratch.** Use OWASP/ATLAS/MAESTRO as the WG's baseline classification system for all subsequent deliverables (the Taxonomy, the Pattern Catalog, the Best Practices Guide). Direct new WG effort at the specific voids below, grouped by what kind of action each one needs.
+
+**Build new, this WG leads directly (five findings):**


How about "Supply chain integrity"? Should that (defining AI-BOM) be added to this "Build New" recommendation as well?

mindpower · 2026-08-04T16:30:58Z

+
+The tooling that exists (Cisco Skill Scanner, Snyk Agent Scan, Syft/Grype for traditional SBOM) is vendor- or community-driven and useful, but it is not a ratified standard, and no two tools share a manifest format.
+
+**Severity:** High. This is a build-new finding, and one the WG is well positioned to address without waiting on a standards body, since the deliverable format the WG already committed to (a gap-analysis-and-guidance document, followed by a pattern catalog) is the right shape for filling exactly this kind of void.


Also check https://spdx.github.io/spdx-spec/v3.0.1/scope/ which covers Agentic AI through its specialized AI Profile introduced in the SPDX 3.0 specification

flucktemberg-sap added 2 commits July 21, 2026 09:27

Create Agentic AI Threat Modeling Gap Analysis (Draft v0.1).md

900fa53

Gap Analysis on threat modeling for Agentic AI

Update Agentic AI Threat Modeling Gap Analysis (Draft v0.1).md

f2a9230

awfrazer mentioned this pull request Jul 29, 2026

July 2026 Monthly Report — WG Security & Privacy (SPAA) #10

Open

zeroasterisk reviewed Aug 3, 2026

View reviewed changes

jamesward reviewed Aug 3, 2026

View reviewed changes

mindpower reviewed Aug 4, 2026

View reviewed changes

Navigation Menu

Uh oh!

Create Agentic AI Threat Modeling Gap Analysis (Draft v0.1).md - #8

Create Agentic AI Threat Modeling Gap Analysis (Draft v0.1).md#8
flucktemberg-sap wants to merge 2 commits into
aaif:mainfrom
flucktemberg-sap:feature/threat-modeling-gap-analysis

flucktemberg-sap commented Jul 21, 2026

Uh oh!

zeroasterisk Aug 3, 2026

Uh oh!

zeroasterisk Aug 3, 2026

Uh oh!

zeroasterisk Aug 3, 2026

Uh oh!

zeroasterisk Aug 3, 2026

Uh oh!

zeroasterisk Aug 3, 2026

Uh oh!

zeroasterisk Aug 3, 2026

Uh oh!

zeroasterisk Aug 3, 2026

Uh oh!

zeroasterisk commented Aug 3, 2026 •

edited

Loading

Uh oh!

jamesward Aug 3, 2026

Uh oh!

mindpower Aug 4, 2026

Uh oh!

mindpower Aug 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants


		Finding. Across all eight areas, the major frameworks jointly provide adequate vulnerability classification, adversary-technique coding, and architectural layering in most cases. The WG does not need to build a competing taxonomy. But the analysis surfaces real, evidenced voids of three different shapes: five areas where a concrete technical or methodological gap warrants new WG-led work; two areas where the gap is real but the architectural fix belongs to a different AAIF working group, and this WG's contribution should be the governance framing plus a handoff; and one area that is not primarily a missing-control problem at all, but an unresolved jurisdictional question between this WG and the Accuracy and Reliability WG.

		Recommendation. Adopt the existing frameworks as the WG's baseline classification system for all subsequent deliverables, and direct new WG effort at the specific voids identified in Section 6, rather than re-deriving classification work already done well elsewhere.


		The structural premise underlying most of the eight gap areas. Agentic systems share a single architectural root cause: language models process instructions and untrusted data through the same token pipeline, with no architectural separation equivalent to parameterized queries in SQL.

		This becomes exploitable when three conditions converge: access to private data, exposure to untrusted content, and external communication capability (Willison's "Lethal Trifecta"). Every agent with meaningful business capability has all three, and none of the three elements alone is dangerous.


		This is the best-covered of the eight gap areas in classification terms.

		Gap: the protocol itself, Model Context Protocol, now governed by AAIF under the Linux Foundation as of December 9, 2025, has two structural trust-model defects no framework closes: OAuth 2.1 authentication is marked optional in the specification, and stdio transport (the most common deployment mode) is explicitly exempt from the OAuth framework entirely. First-party and third-party servers are indistinguishable at the protocol level.


		Gap: OWASP names the principle, but no framework specifies a pre-deployment measurement methodology for quantifying how much agency an agent actually needs versus how much it has been granted. Without a measurement standard, "excessive" has no operational definition an auditor or procurement reviewer can apply consistently across vendors.

		Severity: High. This is an unusually tractable build-new finding: it requires a measurement methodology, not a new architecture, and the WG's own gap-analysis-and-guidance format is the right vehicle to propose one directly.


		Protocol-level primitives exist to narrow this gap technically (RFC 8693 token exchange with `act`/`may_act` claims; SPIFFE/SPIRE workload attestation; UCAN v1 capability tokens, specification-complete July 2025), but no IETF working group has ratified an agent-identity standard, and the median IETF timeline from draft to RFC (two to four years) makes near-term ratification unlikely.

		Severity: High. This is a build-new finding, with one caveat: per the WG's own scope division, the architectural specification work for agent identity and delegated authorization belongs to the Identity and Trust WG, not this WG. This WG's contribution should be the governance/accountability framing above, handed off via the Cross-WG Security and Privacy Review Checklist (Deliverable 5), not a competing identity architecture.


		Gap: this is the largest blank space identified in this analysis. No standards body has yet produced a payment-agent-specific threat classification, which means there is no OWASP code to adopt, no ATLAS technique to detect against, and no MAESTRO layer assignment to default to.

		Severity: High as a gap, but explicitly out of this WG's lane per its own scope division. The appropriate action mirrors Section 4.6: document the gap and hand it off rather than building a competing classification inside this WG. Recommend routing through the Cross-WG Security and Privacy Review Checklist (Deliverable 5) once the Agentic Commerce WG has a charter mature enough to receive it.


		Primary recommendation: adopt and extend, do not build from scratch. Use OWASP/ATLAS/MAESTRO as the WG's baseline classification system for all subsequent deliverables (the Taxonomy, the Pattern Catalog, the Best Practices Guide). Direct new WG effort at the specific voids below, grouped by what kind of action each one needs.

		Build new, this WG leads directly (five findings):


		The tooling that exists (Cisco Skill Scanner, Snyk Agent Scan, Syft/Grype for traditional SBOM) is vendor- or community-driven and useful, but it is not a ratified standard, and no two tools share a manifest format.

		Severity: High. This is a build-new finding, and one the WG is well positioned to address without waiting on a standards body, since the deliverable format the WG already committed to (a gap-analysis-and-guidance document, followed by a pattern catalog) is the right shape for filling exactly this kind of void.

Uh oh!

Conversation

flucktemberg-sap commented Jul 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zeroasterisk commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

zeroasterisk commented Aug 3, 2026 •

edited

Loading