EVIDENCE TRAIL
Agent admission controls — vet peers before they join
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The phrase "agent admission controls" is Helmwart's normalised label — upstream sources use "cryptographic identity verification for AI agents" (OWASP Playbook 4), "workload attestation" (SPIFFE/SPIRE), and "authentication for API endpoints" (MITRE ATLAS AML.M0019).
Last cross-checked against upstream sources: · 8 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP Agentic AI — Threats & Mitigations v1.0
§T13 Rogue Agents in Multi-Agent Systems — Mitigation (Agentic Threats Taxonomy, p. 18)
"Restrict AI agent autonomy using policy constraints and continuous behavioral monitoring. While cryptographic attestation mechanisms for LLMs do not yet exist, agent integrity can be maintained via controlled hosting environments, regular AI red teaming, and input/output monitoring for deviations."
Supports: Names T13 as the threat class this control directly addresses. Confirms that agent integrity and controlled hosting are the recognised mitigations. Acknowledges LLM-specific attestation gaps that SPIFFE workload attestation partially fills.
Does not prove: Does not prescribe a formal admission checkpoint or SPIFFE/SVID mechanism. The v1.0 document predates the v1.1 named scenarios (Compromised Agent Reasoning, Insider Threat MAS, Compromised Peer Tool Access) cited in the MDX frontmatter — those appear in the updated release.
OWASP Agentic AI — Threats & Mitigations v1.0
§Playbook 6: Securing Multi-Agent Communication & Trust Mechanisms — Step 1: Secure AI-to-AI Communication Channels (Proactive) (p. 36)
"Require message authentication & encryption for all inter-agent communications. Deploy agent trust scoring to evaluate reliability of multi-agent transactions. Use consensus verification before executing high-risk AI operations."
Supports: Names message authentication and agent trust scoring as the upstream proactive controls for the multi-agent threat surface — the layer that an admission checkpoint enforces before any inter-agent communication begins.
Does not prove: Playbook 6 is a communication-security playbook, not an admission-gate playbook. It does not define an admission lifecycle (register → attest → admit → monitor → revoke).
OWASP Agentic AI — Threats & Mitigations v1.0
§Playbook 4: Strengthening Authentication, Identity & Privilege Controls — Step 1: Implement Secure AI Authentication Mechanisms (Proactive) (p. 35)
"Require cryptographic identity verification for AI agents. Enforce mutual authentication for AI-to-AI interactions. Prevent unauthorized inter-agent communication by requiring bidirectional verification."
Supports: Verbatim call for cryptographic identity verification and mutual authentication for AI-to-AI interactions — the exact mechanism that SPIFFE SVIDs and mTLS provide in the illustrative admission policy.
Does not prove: Does not specify SPIFFE, OIDC, or any concrete identity technology. The control is stated at the principle level, not the implementation level.
SPIFFE / SPIRE — Concepts (official documentation)
SPIRE Concepts — "Attestation" definition
"Attestation in the context of SPIRE, is asserting the identity of a workload. SPIRE achieves this by gathering attributes of both the workload process itself and the node that the SPIRE Agent runs on from trusted third parties and comparing them to a set of selectors defined when the workload was registered."
Supports: Defines workload attestation as the technical primitive underlying the identity layer of agent admission. The "gathering attributes … from trusted third parties" formulation maps directly to the aws_iid attestor in the illustrative admission policy.
Does not prove: SPIFFE is an infrastructure identity system for workloads, not an agentic-AI admission framework. It does not cover capability-claim validation, SBOM verification, or policy evaluation against agent roles.
Model Context Protocol Specification — Lifecycle (2025-11-25)
§Lifecycle Phases — Initialization
"The initialization phase MUST be the first interaction between client and server. During this phase, the client and server: Establish protocol version compatibility; Exchange and negotiate capabilities; Share implementation details."
Supports: Establishes that MCP peers exchange capabilities at initialization before any operation. This is the protocol-level analogue of an admission handshake: the server can refuse to proceed if the client's declared capabilities are outside policy.
Does not prove: MCP initialization is a capability-negotiation protocol, not a security admission gate. The specification does not mandate cryptographic identity verification of the connecting party — it states that clients and servers MAY negotiate their own authentication strategies.
NIST SP 800-207 — Zero Trust Architecture
§5.7 Use of Non-person Entities (NPE) in ZTA Administration
"Artificial intelligence and other software-based agents are being deployed to manage security issues on enterprise networks. These components need to interact with the management components of ZTA … How these components authenticate themselves in an enterprise implementing a ZTA is an open issue. It is assumed that most automated technology systems will use some means to authenticate when using an API to resource components."
Supports: NIST explicitly names AI agents as a class of NPEs that must authenticate to ZTA management components, and flags authentication of software agents as an open design problem — the same gap that SPIFFE/SPIRE and admission controls address.
Does not prove: Published in 2020, the document predates LLM-based multi-agent systems. "Open issue" language means NIST identifies the problem but does not specify the solution. Section 3.4 covers network components and is less relevant than §5.7 for this mitigation.
NIST SP 800-207 — Zero Trust Architecture
§2 Zero Trust Basics — core ZTA principle (p. 5)
"The idea is to explicitly authenticate and authorize all subjects, assets and workflows that make up the enterprise."
Supports: Foundational ZTA principle that agent admission controls operationalise: "all subjects" includes AI agents, requiring explicit authentication before joining an enterprise workflow.
Does not prove: A high-level design principle, not a deployment specification. Does not address how multi-agent peer identities are established or verified beyond the general ZTA framework.
MITRE ATLAS AML.M0019 — Control Access to ML Models and Data in Production
AML.M0019 — Mitigation description (from MITRE ATLAS catalogue)
"Require users to verify their identities before accessing a production model. Require authentication for API endpoints and monitor production model queries to ensure compliance with usage policies and to prevent model misuse."
Supports: Names identity verification and API authentication as the baseline controls for protecting production AI models — directly cited in the MDX frontmatter as a cross-reference. The authentication requirement extends to agent-to-agent API calls in multi-agent systems.
Does not prove: Scoped to access to ML models, not to peer-agent admission into a multi-agent orchestration layer. Does not address capability validation, SBOM provenance, or binary signing.