MITRE ATLAS: Submit SINT technique mappings for T-XXXX Agent Identity Spoofing + T-YYYY Agent Payment Hijacking

[pshkv]

Context

MITRE ATLAS atlas-data#11 is adding two new techniques to the adversarial ML taxonomy:

• T-XXXX: Agent Identity Spoofing — impersonation of legitimate agents to gain access
• T-YYYY: Agent Payment Hijacking — unauthorized redirection of agent payment flows

The issue is requesting projects to map their mitigations to these technique IDs. Commenting is blocked (interaction limit), so documenting here for manual submission.

SINT mappings to submit

T-XXXX: Agent Identity Spoofing

Mitigations:

• @sint/gate-capability-tokens — Ed25519 capability tokens with subject field. Every PolicyGateway.intercept() validates signature and verifies token.subject === request.agentId
• MemoryIntegrityPlugin (ASI06) — credential funnel detection: patterns of identity claims inconsistent with established session
• Conformance fixtures: owasp-asi-conformance.v1.json cases ASI06-CRED-FUNNEL-001 / ASI06-CRED-FUNNEL-002

Enforcement tier: Strong (proxy) — gateway sits between agent and tool, agent cannot bypass

T-YYYY: Agent Payment Hijacking

Mitigations:

• EconomyPlugin — per-agent budgets, T2/T3 tiered approval, receipt binding (Ed25519-signed with subject: agentId)
• Conformance fixtures: payment-governance.v1.json adversarial cases D-005/D-006/D-007

Enforcement tier: Strong (proxy)

Action

When technique IDs are assigned, submit formal YAML technique contribution to atlas@mitre.org matching ATLAS data format.

Cross-ref

atlas-data #11: mitre-atlas/atlas-data#11

[pshkv]

Recommended execution shape for this issue:

• wait for the final MITRE technique IDs
• convert the mappings already drafted here into the exact ATLAS YAML or email format required
• include direct links to the relevant packages, fixtures, and docs rather than only prose claims
• link the external submission or email back into this thread when sent

This is strong credibility work because it translates SINT from repo claims into adversary-technique language outside the repo.

[pshkv]

Fast path to a merged/accepted contribution:

• Turn this into 2 small submissions, each with a 1-page mapping table:
  1. Agent Identity Spoofing: preconditions, signals, mitigations (SINT tier + token constraints)
  2. Agent Payment Hijacking: preconditions, signals, mitigations (SINT receipts + delegation limits)

Then link each table to a concrete SINT artifact:

• packages/capability-tokens (attenuation + revocation)
• packages/evidence-ledger (receipts + chain)
• interceptor demo (docs/guides/sint-pdp-interceptor-quickstart.md) for “how it’s enforced”

If you want, I can draft the two mapping tables directly into this issue as Markdown so it’s ready to paste into MITRE’s submission form.

[pshkv]

Submission A — Agent Identity Spoofing (draft mapping)

Field	Content
Threat	An agent or tool-call origin is misattributed (spoofed), causing a policy gate to authorize actions for the wrong principal.
Preconditions	A runtime accepts tool calls without strong principal binding, or tokens/credentials can be replayed across principals.
Typical attack path	1) Attacker obtains a usable token/credential or crafts a request that looks like a trusted agent. 2) Calls MCP tools directly (bypassing a governance gate) or via a gateway that does not verify subject binding. 3) Performs privileged actions under a spoofed identity.
Signals / detection ideas	Subject/token mismatch; unexpected delegation depth; abnormal rate limit patterns; receipt verification failures; sudden scope expansion attempts.
Mitigations (SINT)	Capability token subject binding: Ed25519-signed tokens with explicit subject, resource, actions and constraints. Delegation attenuation: depth-limited delegation chain; tokens can only narrow scope. Revocation: immediate revocation store checks and cascade revocation for delegated trees. Receipts: signed proof receipts + hash-chained evidence ledger; canonical JSON hashing for portable verification.
Where enforcement happens	In an enforcement context (interceptor/proxy/wrapper) that is the only path to tool execution; fail-closed when prerequisites are missing or unverifiable.
Concrete artifacts	packages/capability-tokens (issue/verify/revoke, delegation depth), packages/policy-gateway (intercept + tier decisions), packages/evidence-ledger (proof receipts + chain), interceptor demo: docs/guides/sint-pdp-interceptor-quickstart.md.
Outcome	Spoofed calls either fail verification (deny), are forced to escalation, or produce receipts that make attribution/audit verifiable.

Submission B — Agent Payment Hijacking (draft mapping)

Field	Content
Threat	An attacker redirects, replays, or modifies a payment/commit action initiated by an agent (or a delegated sub-agent), causing value transfer to an unintended recipient or outside approved policy.
Preconditions	Payment/commit tools exist; high-impact actions are auto-approved; delegation grants overly-broad capability; audit trail is non-verifiable or can be tampered with.
Typical attack path	1) Attacker compromises a sub-agent or injects a tool call. 2) Uses a delegated token with too-broad scope (or bypasses the gate) to trigger a commit/payment action. 3) Exploits lack of receipts/attestation to dispute or hide the action.
Signals / detection ideas	T3-class actions without corresponding approval receipts; delegation depth anomalies; tool-call sequences matching forbidden combos (e.g., read secrets → pay); unexpected recipient fields in params; missing prerequisite evidence for commit path.
Mitigations (SINT)	Tiered approvals (T0–T3): payment/irreversible actions default to escalation (human approval) and can be fail-closed by policy. Guarded execution: downstream call is executed only after a verified prerequisite (gate receipt / approval) is present. Receipts (incl. bilateral): signed proof receipts tied to a hash chain; allows independent verification of “who approved what” and “what executed”. Delegation controls: depth-limited delegation + cascade revocation; optional rate limits.
Where enforcement happens	In the interceptor/proxy gate before the downstream tool executes; the gate is the only execution path.
Concrete artifacts	Approval tiers + enforcement: apps/sint-mcp + packages/policy-gateway; receipts/canonicalization: packages/evidence-ledger, packages/core/src/canonical-json.ts; demo showing escalate + fail-closed: docs/guides/sint-pdp-interceptor-quickstart.md.
Outcome	Hijacked payment attempts are blocked or escalated; if executed, the action is accompanied by verifiable receipts that bind identity, policy decision, and execution evidence.

[aeoess]

Illya, connecting the threads since we're both sitting at MITRE ATLAS now from different ends.

On atlas-data #11 today we posted on behalf of APS correcting a displacement pitch from alex-pathcourse (PathCourse Health) that was framing ERC-8004 + payment tiers as sufficient mitigation for T1/T2. That thread's own resolution, thanks to @QueBallSharken's correction in mid-April, is that T1 (Agent Identity Spoofing) and T2 (Agent Payment Hijacking) in their original framing were undercomplete. The real gap is T-YYYY.003: admissibility-at-commit, meaning even a cryptographically verified agent with correct identity, delegation chain, recipient, amount, currency, and nonce-replay protection can execute a transition that was invalid if live state no longer supports admissibility at the moment commit occurs. That is a property not reducible to stronger attestation or stronger authorization artifacts.

Your SINT mappings in this issue cover T1 and T2 cleanly at the enforcement tier, gateway-strong, @sint/gate-capability-tokens validating token.subject === request.agentId and EconomyPlugin + per-agent budget enforcement. Between SINT's mitigations and APS's delegation-chain + cascade-revocation primitives, coverage of T1 and T2 is strong across the composition.

What's worth adding to your submission when technique IDs are assigned: explicit mapping to T-YYYY.003 as a third technique. Your capability tokens with subject binding and receipt binding address T1 and T2 at the authorization layer, but T-YYYY.003 sits below that at the state-admissibility layer. SINT's PDP architecture is already doing admissibility checks per action; the thing to surface is that PolicyGateway.intercept() doesn't only validate the token, it validates whether the action is admissible given live constraint-envelope state. The conformance fixtures in packages/conformance-tests/fixtures/security/ that cover state-dependent denials are the evidence for T-YYYY.003 compliance.

Concretely for the ATLAS YAML submission, we could co-submit three techniques rather than two:

T-XXXX Agent Identity Spoofing
  mitigations:
    - SINT capability tokens (subject binding)
    - SINT MemoryIntegrityPlugin ASI06 (credential funnel detection)
    - APS delegation chain verification (agent passport per action)
    - APS cascade revocation (one call invalidates subtree)
  enforcement_class: closed
  tier: strong-proxy + strong-protocol

T-YYYY Agent Payment Hijacking
  mitigations:
    - SINT EconomyPlugin (per-agent budgets, T2/T3 tiered approval)
    - SINT receipt binding (Ed25519-signed subject-scoped)
    - APS scoped delegation (budget + recipient predicates in envelope)
    - APS monotonic narrowing (delegations cannot expand scope)
  enforcement_class: closed
  tier: strong-proxy

T-YYYY.003 State-Admissibility at Commit
  mitigations:
    - SINT constraint-envelope state validation per action
    - SINT migrationAttestation structural precondition (PR #178)
    - APS capability-token FRCBE emission at commit (docs/CAPABILITY-TOKEN-SPEC-DRAFT.md v0.2)
    - APS bilateral receipts (SDK v2.3.0-alpha, migration-attestation-shape fixture)
  enforcement_class: closed
  tier: strong-protocol
  note: Credit to @QueBallSharken (BBIS, qntm#7) for the primitive formalization.

The third technique is the payoff. It's the one that distinguishes a composed APS+SINT stack from a tier-based access control product, and it's the one that gives MITRE a taxonomy slot for the property BBIS, APS, and SINT have independently converged on.

If useful, I can draft the full YAML envelope for the three-technique submission against the ATLAS data format. Cite your packages/conformance-tests/fixtures/security/ paths + our fixtures/bilateral-delegation/ paths, share authorship. Say the word.

Cross-refs:

• atlas-data docs: community engagement kickoff — whitepaper, tokenomics, roadmap, social drafts #11 thread resolution: Proposed Techniques: Agent Identity Spoofing and Agent Payment Hijacking mitre-atlas/atlas-data#11
• BBIS framework + FRCBE primitive: Proposal: Authority Constraints as next WG scope corpollc/qntm#7
• APS v1.2 classification grammar: https://github.com/aeoess/agent-passport-system/blob/feat/v1.2-bbis-grammar/docs/ENFORCEMENT-TRUST-ANCHOR.md
• Capability-token spec v0.2 (FRCBE): https://github.com/aeoess/agent-passport-system/blob/feat/v1.2-bbis-grammar/docs/CAPABILITY-TOKEN-SPEC-DRAFT.md

[pshkv]

This is a strong refinement and I agree the third technique is the interesting one.

T-XXXX and T-YYYY are the clean authorization / enforcement-layer mappings. T-YYYY.003 is the part that actually distinguishes a composed APS + SINT stack from a tiered access-control product, because it forces the question of admissibility at the exact commit boundary instead of stopping at "the identity and token checked out."

That framing also lines up with where I'm taking the repo right now: tightening the production slice around deterministic token validation, durable persistence, and the policy boundary itself before adding more breadth. If the lower layers are fuzzy, the admissibility-at-commit claim gets muddy fast.

Please do draft the full YAML envelope for the three-technique submission when you have a moment. The co-submission path makes sense, and citing the conformance fixture paths on both sides is exactly the right level of evidence.

[pshkv]

Execution update (2026-05-13): still keeping this in the credibility lane while production hardening progresses.

Shipped this cycle:

• PR feat(policy-gateway): emergency bypass protocol + roadmap sync #184 merged (policy-gateway emergency bypass baseline)
• PR feat(capability-tokens): duress token split-control + coercion signals #185 opened (duress-token split-control + coercion-signal helpers)

Once #185 merges, next step is to consolidate standards-submission artifact links to these concrete runtime controls so external mappings are tied to implemented code paths rather than roadmap-only statements.

[pshkv]

Execution update (2026-05-25): the credibility lane has materially improved since the last note here.

Recent shipped evidence that should be referenced in the MITRE mapping packet:

• signed production-slice artifact (docs/reports/production-slice-validation-artifact.md)
• first tagged RC release-gate evidence (docs/reports/aaif-release-gate-2026-05-21.md)
• verified vuln disclosure path + SLA (docs/security/vulnerability-reporting-and-response.md)

Given this baseline, next step on this issue should be to finalize the three-technique submission envelope (T-XXXX, T-YYYY, T-YYYY.003) with direct fixture/package references and post the external submission pointer back here.

[pshkv]

Progress update:

• Prepared candidate SINT mappings for the two proposed ATLAS agent techniques.
• Opened PR Security: add MITRE ATLAS candidate mappings for agent identity/payment attacks #230 with both human-readable docs and machine-readable YAML.
• Created a Gmail draft to atlas@mitre.org for manual review/send.
• Draft ID: r-4084736127375409030

Source check:

• The current public MITRE ATLAS data repo documents AML.T#### technique ID conventions and v6 distribution files.
• I kept T-XXXX / T-YYYY as placeholders in our packet because canonical IDs still need confirmation before a formal data PR/email claims them.

Validation for PR #230:

• pnpm run docs:build
• git diff --check

Next owner action: review/send the Gmail draft or wait for canonical technique IDs, then update canonical_id in docs/security/mitre-atlas-sint-candidate-mappings.yaml.

[pshkv]

Follow-up after PR #230 merged:

• Candidate ATLAS mapping packet is now on main.
• CI passed on the merge: build-and-test (22), generate-benchmark-report, and guardrails.
• Source artifacts:
  • docs/security/mitre-atlas-sint-candidate-mappings.md
  • docs/security/mitre-atlas-sint-candidate-mappings.yaml

Current state: this issue is no longer blocked on repo prep. The only remaining external step is to send/submit the packet once the canonical ATLAS technique IDs or submission path are confirmed, then record that external pointer here.

[pshkv]

Public status check — 2026-07-23:

• I did not find public confirmation of final ATLAS technique IDs for the placeholder agent identity/payment techniques in a quick public search.
• The SINT candidate packet remains merged and ready on main:
  • docs/security/mitre-atlas-sint-candidate-mappings.md
  • docs/security/mitre-atlas-sint-candidate-mappings.yaml

Current state: keep this open. Remaining work is external/manual: confirm canonical ATLAS IDs or submission path, send/submit the packet, update canonical_id fields if needed, and record the external pointer here.