AI and Agent Security: A Cross-Framework Synthesis

Scope and Method

This document draws from forty-one publicly available papers, listed in full under Source Documents. Sections 1 through 11 cover agent-specific security: identity, delegation, autonomy, and the Model Context Protocol. Sections 12 through 20 cover the broader supply-chain, data, governance, and application-security material that agentic systems sit on top of without being specific to agents themselves. The two halves are meant to be read together, since almost every agent-specific rule in the first half assumes a foundation from the second half is already in place; an organization that has solved delegation-chain narrowing but not model provenance has only secured half the stack.

Rather than summarizing each paper on its own, the document groups the recurring axioms, invariant rules, and principles by topic, so a single idea can be cited once even when three or four different organizations independently arrived at it. Each claim below names the source or sources it came from, using the short codes defined in the source table, so a reader can trace any single sentence back to its origin without re-reading the whole paper. Each section also closes with an OpenCRE crosswalk line, naming the OpenCRE topic categories the section's sources map to, so the material can be cross-referenced against OpenCRE's own taxonomy rather than treated as a closed, self-contained vocabulary.

Where sources disagree, or where one organization's position goes further than the rest, that difference is called out rather than smoothed into a false consensus. Several sections note where a rule first appeared in an older, narrower paper and was later restated in stronger form by a newer one; where that happens, both are cited, since the earlier paper is often more specific about the mechanism even when the newer one states the principle more forcefully.

1. Agent Identity and Non-Human Principals

Across nearly every source, the starting move is to stop treating an agent as a variant of a human user or a shared service account. CSA-IAM states this most directly: agents are first-class identities, distinct from human users and traditional service accounts, and an agent's identity has to encode its capabilities, provenance, and security posture, not just who it claims to be. It adds that no implicit or default trust exists between autonomous agents, which rules out the common shortcut of treating "it's an internal agent" as sufficient grounds for trust. COSAI-IAM treats a shared-account agent as an accountability failure rather than a convenience, and frames the whole problem as an extension of existing IAM infrastructure rather than a rip-and-replace effort: the identity plane an organization already has for humans and service accounts is the right starting point, not a reason to build something separate.

OWASP-TOP10 names the gap that results when this isn't done: most current architectures still lack a distinct, governed agent identity, which it calls the attribution gap, and treats this as a structural problem across the industry rather than a mistake specific to any one deployment. OWASP-STATE adds a scale problem on top of the design problem: non-human identities already outnumber human ones in production and the gap keeps widening, which means the attribution gap isn't a slow-burning risk to plan for eventually, it's already the majority-case identity plane in most environments. CIS-AGENTS and CIS-MCP both treat this as a lifecycle-management problem rather than a one-time provisioning decision, requiring the same issuance, rotation, and retirement discipline for a non-human identity that a human credential would get, and explicitly rejecting the idea that an agent identity, once created, needs less ongoing governance than a human one.

• Every agent needs its own distinct, verifiable identity, never a shared account or reused human credential (CSA-IAM, COSAI-IAM, OWASP-MCP-DEV, OWASP-STATE)
• Identity claims must be cryptographically verifiable and attestable (CSA-IAM, OWASP-TOP10, OWASP-STATE)
• Credentials must be short-lived and task-scoped rather than standing (COSAI-IAM, OWASP-TOP10, OWASP-STATE)
• Non-human identities require the same lifecycle management (issuance, rotation, retirement) as any other governed credential (CIS-AGENTS, CIS-MCP, OWASP-MCP-DEV)
• No implicit or default trust exists between agents simply because both are internal to the same organization (CSA-IAM)
• Agentic IAM extends existing identity infrastructure rather than requiring a parallel, separate system (COSAI-IAM)

OpenCRE crosswalk: Access Control, Authentication, Identity Management, Secrets Management, Session Management.

2. Zero Standing Privilege and Continuous Authorization

Least privilege shows up in every single source in this corpus, but the agentic version goes further than the classical one in a specific, repeated way. Static privilege, granted once and left in place, is rejected outright rather than merely discouraged. COSAI-IAM names this Zero Standing Privilege and pairs it with a capability-risk classification: controls should scale proportionally with what a given agent can actually do and how sensitive the data it touches is, rather than applying a single uniform policy to every agent regardless of its blast radius. CSA-IAM requires access to be continuously re-verified rather than permanently granted, and frames this as fine-grained, dynamic, attribute-based and policy-based access control rather than the role-based model most human IAM systems still run on.

OWASP-TOP10 extends the idea past access into behavior, coining "Least-Agency" for the constraint on what an agent is allowed to decide and do, not just what it can technically reach, on the theory that an agent with narrow data access but broad decision-making latitude is still under-constrained. COSAI-FUTURE applies the same logic to the reasoning layer itself, arguing that least privilege has to reach the agent's cognitive process and not stop at its network and file permissions, restoring elevated context only through explicit just-in-time provisioning rather than granting it up front. OWASP-MCP-CHEAT applies the identical rule at the MCP server boundary specifically, requiring just-in-time access with automatic expiration rather than a standing grant that happens to sit unused most of the time.

• Access is continuously re-verified against current context, not granted once and left standing (CSA-IAM, OWASP-STATE)
• Credentials and permissions are short-lived, scoped, and automatically revocable (COSAI-IAM, OWASP-TOP10, OWASP-STATE, OWASP-MCP-CHEAT)
• Least privilege extends to the agent's decision-making layer, not only its infrastructure access (COSAI-FUTURE, OWASP-TOP10)
• Controls scale with an agent's actual capability and the sensitivity of what it touches, rather than applying uniformly to every agent (COSAI-IAM)
• Access control uses fine-grained, attribute- and policy-based models rather than coarse role-based grants (CSA-IAM)

OpenCRE crosswalk: Access Control, Authentication, Authorization, Configuration Management.

3. Delegation Chains and Scope Narrowing

Once one agent calls another, or acts on a user's behalf, the sources converge on a specific rule: authority can only narrow as it passes down a chain, and every hop has to enforce that independently rather than trust that an earlier check already covered it. COSAI-IAM states this as an invariant: delegation scope never expands at any hop, and revoking a delegation anywhere in the chain automatically invalidates everything downstream of it, which means a single revocation event can safely be trusted to cut off an entire multi-agent workflow rather than requiring a separate revocation at every node. It frames its full model as "delegation with full lineage," meaning on-behalf-of tokens that carry both the agent's identity and the originating user's identity together, narrowing the scope at each hop rather than passing the same token unchanged.

OWASP-MCP-DEV names the specific failure this design prevents: passing a raw upstream token to a downstream API is never permitted, because it recreates the confused deputy problem, where a downstream service acts with more authority than the caller actually possesses because it can't distinguish a legitimately scoped request from an inherited, overly broad one. COSAI-FUTURE requires that a downstream call made by one agent on another's behalf stays traceable to the exact thread or event that authorized it, and separately requires that a retrieval agent never query as a super-admin regardless of convenience, since its query scope must always be bounded by the invoking identity's actual entitlements rather than the retrieval agent's own broad access. OWASP-STATE frames the same requirement from the audit side: delegated authority must preserve traceability back to the originating human principal at every step, so a downstream action can always be traced back to a specific person's original request rather than dead-ending at an intermediate agent.

• Delegated authority narrows at every hop and never expands (COSAI-IAM, COSAI-MCP)
• Raw upstream tokens are never forwarded downstream; only newly scoped credentials pass along the chain (COSAI-IAM, OWASP-MCP-DEV)
• Each hop enforces authorization independently rather than assuming a perimeter check elsewhere already covered it (COSAI-IAM, OWASP-MCP-DEV)
• Delegation chains stay traceable back to the human principal that originated them (OWASP-STATE, COSAI-FUTURE)
• Revoking a delegation at any point in a chain automatically invalidates every downstream delegation built on it (COSAI-IAM)
• A retrieval or query agent never operates with broader entitlements than the identity that invoked it, regardless of the agent's own standing access (COSAI-FUTURE)

OpenCRE crosswalk: Access Control, Authentication, Session Management, Authorization.

4. Ephemeral Execution and Ephemeral Compute

Several sources treat the lifetime of an agent's execution environment as a control in its own right, not just an efficiency choice made for cost reasons. COSAI-FUTURE calls this Zero-State Initialization: every autonomous loop starts from a pristine, cryptographically verified image and is destroyed immediately after it runs, so nothing persists between executions for an attacker to re-enter, and no compromise from one run can carry forward into the next. It pairs this with "guaranteed teardown" as a distinct operational requirement, meaning the destruction of the execution environment isn't best-effort cleanup but a property the platform has to actually enforce. OWASP-TOP10 and OWASP-MCP-CHEAT both require just-in-time access that expires automatically rather than persisting past the task that needed it, which extends the same ephemerality principle from compute environments to the credentials those environments use while they're alive.

The underlying logic connects back to the untrusted-input problem covered in Untrusted Input and the Prompt Injection Problem: since no source in this corpus claims prompt injection can be fully prevented, ephemeral execution functions as a containment strategy for a class of attack that can't be stopped at the input layer. If an injected instruction can't be reliably filtered out before it reaches the model, limiting how long a compromised execution context can persist, and guaranteeing it's destroyed rather than reused, becomes one of the few remaining levers available.

• Autonomous execution loops start from a verified image and are destroyed immediately after each run (COSAI-FUTURE)
• Access grants expire automatically instead of persisting past the task that required them (OWASP-TOP10, OWASP-MCP-CHEAT)
• Environment teardown is a guaranteed platform property, not best-effort cleanup (COSAI-FUTURE)
• Ephemeral execution functions as a containment strategy for attacks that can't be reliably filtered at the input layer (COSAI-FUTURE, cross-referenced with OWASP-STATE)

OpenCRE crosswalk: Secure Product Design, Configuration Management, Access Control.

5. Human Oversight, Kill Switches, and Autonomy Tiers

Every source keeps a human override somewhere in the loop, but none of them apply oversight uniformly; it scales with how autonomous the agent is. COSAI-SRF is the most precise on this point, because it's the only source in the corpus that ties oversight formally to a numbered autonomy scale: it requires immediate human intervention capability regardless of autonomy level, formal documentation and quarterly review once an agent reaches autonomy level L3, and a contractual accountability clause from the provider once an agent reaches full autonomy at L5. Its autonomy scale is explicitly adapted from SAE J3016, the same framework used to classify self-driving vehicle autonomy, and it pairs this with a separate scale of Human Override Tiers running from automated soft guidance up to a CISO- or executive-authorized emergency shutdown, so the corpus doesn't just say "a kill switch must exist" but specifies who is authorized to pull it at each severity level.

COSAI-SBD requires agentic systems to stay under meaningful human control, with the degree of oversight tied to the risk of the business outcome rather than fixed in advance, and adds that systems must be continuously validated against their intended purpose and predefined failure modes, not just checked once at launch. OWASP-TOP10 and OWASP-STATE both require human approval before any high-impact, irreversible, or goal-changing action, and both require a kill-switch or circuit-breaker capable of halting a compromised agent; OWASP-STATE adds a budget-limit requirement specifically for fully autonomous agents, treating a spending or resource cap as its own kind of emergency brake distinct from an outright shutdown. COSAI-MCP requires human-in-the-loop consent as a fail-safe default for MCP-mediated actions specifically, reinforcing the same rule at the protocol layer rather than only at the application layer.

• Human intervention capability exists regardless of an agent's autonomy level (COSAI-SRF)
• Human approval is required before high-impact, irreversible, or goal-changing actions (OWASP-TOP10, OWASP-STATE, COSAI-MCP)
• A kill-switch, circuit-breaker, or budget limit exists for fully autonomous agents (OWASP-STATE)
• Oversight requirements scale with autonomy level and business risk rather than applying as a flat rule (COSAI-SRF, COSAI-SBD)
• Authority to invoke each tier of human override is explicitly assigned, up to CISO- or executive-level authorization for emergency shutdown (COSAI-SRF)
• Systems are continuously validated against their intended purpose and predefined failure modes, not checked once at launch and left alone (COSAI-SBD)

OpenCRE crosswalk: Access Control, Governance Risk and Compliance, Log Management.

6. Observability, Audit Trails, and Traceability

Logging is treated as a security control in this corpus, not an operational nicety, and several sources specify that the log itself has to be tamper-evident, not merely present. OWASP-TOP10 requires comprehensive, immutable, tamper-evident logging of agent actions, tool calls, and inter-agent messages, and pairs this with a separate requirement for observability into agent goals and decision paths, on the theory that a log of actions taken without a record of the reasoning behind them is forensically incomplete. COSAI-IAM requires the chain of authority behind a delegated action to be preserved in immutable logs, which connects directly to the traceability requirement in Delegation Chains and Scope Narrowing: the log isn't just a record of what happened, it's the mechanism that makes the narrowing-authority rule enforceable after the fact.

CIS-AGENTS and CIS-MCP both extend existing CIS Controls v8.1 logging requirements to agent actions rather than writing new ones, keeping them bounded and auditable, which reflects a broader pattern across the CIS material of treating agentic AI as a new surface for old controls rather than a domain that needs its own control catalog from scratch. COSAI-SBD goes further than the rest, requiring telemetry across the full decision path, meaning inputs, plans, decisions, communications, and outputs together, not just the final action taken, so an auditor can reconstruct not only what an agent did but what it considered and rejected along the way. OWASP-STATE frames the underlying goal as parity with existing software supply chain practice: execution provenance should be kept as traceable as a static software inventory, which is a notably higher bar than most organizations currently hold their AI systems to, since a static inventory is checked periodically while execution provenance has to be captured continuously.

• Logging of agent actions, tool calls, and inter-agent messages is immutable and tamper-evident (OWASP-TOP10, COSAI-IAM)
• Telemetry covers the full decision path, not just the final action taken (COSAI-SBD)
• Execution provenance is kept as traceable as a static software inventory (OWASP-STATE)
• Observability extends to agent goals and decision paths, not only the actions ultimately taken (OWASP-TOP10)
• Existing CIS Controls v8.1 logging requirements are extended to agent actions rather than replaced with a new control set (CIS-AGENTS, CIS-MCP)

OpenCRE crosswalk: Log Management, Error Handling, Governance Risk and Compliance.

7. Untrusted Input and the Prompt Injection Problem

This is the one place in the corpus where the sources admit an open, unsolved problem instead of a settled control. COSAI-FUTURE states plainly that proving an LLM will never execute an injected instruction hidden in untrusted content is currently considered theoretically impossible, and adds a related point about visibility: being able to read a chat log is not the same as having cryptographic control over code integrity, so monitoring an agent's conversation isn't a substitute for controlling what it's actually allowed to execute. OWASP-STATE calls prompt injection an unsolved architectural flaw, because an LLM merges its data and control planes into a single token stream, which means the same channel that carries the content the model is supposed to process also carries anything an attacker manages to smuggle in as an instruction. OWASP-TOP10 adds that agents and models cannot reliably tell instructions apart from the untrusted content surrounding them, and frames this as an amplification problem more than a new one: agents mostly amplify existing LLM-level vulnerabilities by giving a model with this flaw the ability to act on the world, rather than introducing an entirely new class of vulnerability.

Since the underlying flaw resists a permanent fix, the sources converge instead on treating everything an agent reads, meaning tool descriptions, retrieved documents, and other agents' output, as untrusted input requiring validation at every boundary it crosses, rather than trusted once and passed along. COSAI-MCP and OWASP-MCP-DEV both flag tool descriptions and metadata specifically as untrusted unless they come from an already-trusted server, which closes a specific loophole: a tool's own self-description is exactly the kind of content an attacker could poison, so treating it as trustworthy by default because it comes from the tool's own manifest rather than from a document the agent retrieved would defeat the purpose of the broader rule. OWASP-STATE's "lethal trifecta" and "Rule of Two" give this problem its most concrete operational form: an agent that has private data access, is exposed to untrusted content, and has an outbound communication channel, all three at once, is treated as exploitable end to end regardless of how well any single piece is defended, which is why the Rule of Two caps an agent at satisfying no more than two of the three properties without requiring human approval to proceed.

• All tool descriptions, retrieved content, and inter-agent messages are treated as untrusted input, never trusted by default (COSAI-MCP, OWASP-MCP-DEV, OWASP-TOP10)
• Input is validated at every trust boundary it crosses, not only at the outermost one (COSAI-MCP)
• The "Lethal Trifecta," meaning private data access plus exposure to untrusted content plus outbound communication, is treated as exploitable end to end; the "Rule of Two" caps an agent at satisfying no more than two of the three without human approval (OWASP-STATE)
• Visibility into an agent's conversation or chat log is not equivalent to cryptographic control over what it can execute (COSAI-FUTURE)
• Agents are treated as amplifying existing LLM-level vulnerabilities rather than introducing an entirely new vulnerability class (OWASP-TOP10)

OpenCRE crosswalk: Input Validation, Injection Prevention, Data Protection, Threat Modeling.

8. MCP Protocol Security

Five of the sources in this corpus address the Model Context Protocol specifically, since MCP has become the default way agents discover and invoke tools. COSAI-MCP and CIS-MCP both treat MCP as a distinct third layer, separate from the model and the agent, carrying its own risk profile, and COSAI-MCP is explicit that existing risk frameworks such as MITRE ATLAS, NIST AI RMF, and MAESTRO were built assuming predictable component behavior and don't fully address MCP's specific failure modes. It cites three real incidents, at Asana, WordPress AI Engine, and Supabase, as evidence that MCP threats are active rather than theoretical, and states flatly that containers alone are not a strong security boundary for MCP execution, since a container isolates the process but not the trust decisions the process makes on the model's behalf.

OWASP-MCP-DEV requires OAuth 2.1 or OIDC for every remote MCP server, with issuer, audience, expiry, and signature validated on every request, and explicitly forbids passing a token through to a downstream API unchanged, which is the same confused-deputy prevention rule from Delegation Chains and Scope Narrowing applied specifically to the MCP transport layer. It adds several MCP-specific hygiene rules not covered elsewhere in the corpus: users, sessions, and execution contexts must be fully isolated with no global or shared state for user data, secrets must never be exposed to the LLM itself, and error responses returned to the model must never include stack traces, tokens, file paths, or other tool internals, since a verbose error message is itself a disclosure channel an attacker can use to map the system. OWASP-MCP-CHEAT adds a governance layer on top of the technical one: a security reviewer and a domain owner both have to sign off before a third-party server is enabled, and approved versions are pinned and checksum-verified so a silent upgrade can't slip in unnoticed, treating an MCP server the same way a security-conscious organization would treat any other third-party dependency with code-execution capability.

• Every capability or tool is granted individually and explicitly, never through a broad or opaque grant (CIS-MCP)
• Remote MCP servers require OAuth 2.1/OIDC with per-request validation of issuer, audience, expiry, and signature (OWASP-MCP-DEV)
• A security reviewer and a domain owner both sign off before a third-party MCP server is enabled (OWASP-MCP-CHEAT)
• Containers alone are not treated as a sufficient security boundary for MCP execution (COSAI-MCP)
• User sessions and execution contexts are fully isolated, with no shared global state across users (OWASP-MCP-DEV)
• Error responses returned to the model never include stack traces, tokens, file paths, or other internal details (OWASP-MCP-DEV)
• Real, documented MCP incidents are cited as evidence the threat is active, not a hypothetical worst case (COSAI-MCP)

OpenCRE crosswalk: Access Control, Authentication, Input Validation, Secure Communication, Supply Chain, Log Management.

9. Supply Chain and Provenance for Agentic Components

Models, tools, and MCP servers are all treated as supply-chain components requiring provenance, not just runtime controls applied after the fact. COSAI-SBD requires provenance, model integrity, and runtime validation as part of its secure AI supply chain principle, and frames supply chain security as inseparable from the rest of its secure-by-design agentic principles rather than a bolt-on compliance checkbox. OWASP-TOP10 and OWASP-STATE both call for SBOM- or AIBOM-style provenance records and signed manifests specifically for agent and tool components, extending a practice that originated in traditional software supply chain security into the agentic domain. OWASP-MCP-DEV requires cryptographic integrity and signing for tools, manifests, and dependencies, not only for the deployed application itself, which closes a gap the other sources leave implicit: it isn't enough to sign the final agent application if the tools it calls at runtime were never verified.

This section connects directly to the deeper treatment in Data and Model Provenance Across the AI Supply Chain, which covers the underlying signing and attestation mechanics in more depth; the rules here are the agent-specific application of that broader supply chain discipline, applied to the tools and MCP servers an agent depends on at runtime rather than to the model or training data it was built from.

• Model and tool provenance is verifiable through signed manifests or SBOM/AIBOM-style records (COSAI-SBD, OWASP-TOP10, OWASP-STATE, OWASP-MCP-DEV)
• Approved server and tool versions are pinned and checksum-verified to block a silent malicious upgrade (OWASP-MCP-CHEAT)
• Cryptographic signing extends to tools and dependencies invoked at runtime, not only the deployed agent application (OWASP-MCP-DEV)
• Supply chain security is treated as inseparable from the rest of an agent's secure-by-design posture, not a separate compliance step (COSAI-SBD)

OpenCRE crosswalk: Supply Chain, Cryptography, Secure Product Design.

10. Shared Responsibility and Layered Accountability

The newest source in the corpus, COSAI-SRF, gives this problem its most complete treatment: exactly one party is accountable for each activity or component, security and governance requirements cascade down from the business layer through every supporting layer, and accountability shifts predictably from the end user toward the application developer and the agentic provider as an agent's autonomy level rises. Its five-layer model, AI Business & Usage, AI Information, AI Application, AI Platform, and AI Model Provider, is explicitly calibrated by operating model as well as by layer: an organization running an AI-SaaS product carries less infrastructure-layer responsibility than one running its own Agent-PaaS or IaaS deployment, so the same activity can land on a different accountable party depending on how the system is actually operated, not just what layer it technically belongs to. COSAI-SRF is also explicit about its relationship to other frameworks rather than positioning itself as a replacement: NIST AI RMF defines what to do, ISO 42001 defines how to manage it, and CoSAI's own SRF defines who is accountable for it, three complementary answers to three different questions rather than three competing frameworks.

COSAI-SBD anticipated a narrower version of the same idea earlier, requiring accountability to be shared among stakeholders and scaled to risk, though without the five-layer model or the autonomy-linked responsibility shift that COSAI-SRF later formalized. OWASP-STATE draws the same line differently and more narrowly: model-level safety belongs to the model provider, while deployment-layer security controls belong to the organization doing the deploying, and the two cannot be governed as a single function, which is a two-party version of the same principle COSAI-SRF generalizes across five layers and four operating models.

• Exactly one party is accountable per activity or component; overlapping accountability is not permitted (COSAI-SRF)
• Accountability shifts toward the application developer and agentic provider as autonomy increases (COSAI-SRF)
• Model-level safety and deployment-layer security are distinct responsibilities that cannot be governed as one function (OWASP-STATE, COSAI-SRF)
• The same activity can land on a different accountable party depending on the operating model in use (AI-SaaS, AI-PaaS, Agent-PaaS, IaaS), not only on which architectural layer it belongs to (COSAI-SRF)
• Shared-responsibility frameworks are treated as complementary to, not competitive with, process frameworks like NIST AI RMF and management-system standards like ISO 42001 (COSAI-SRF)

OpenCRE crosswalk: Governance Risk and Compliance, Access Control, Log Management.

11. Emerging Risk Models

Two named concepts recur without a settled mitigation yet. OWASP-STATE states that every organization already has agents running that haven't been discovered or governed, calling this Shadow AI, and treats it as a present condition rather than a future risk, on the same logic that shadow IT was never a hypothetical problem organizations could choose to prepare for on their own timeline. OWASP-TOP10 names the attribution gap, meaning the absence of a distinct, governed agent identity discussed in Agent Identity and Non-Human Principals, as a structural problem across current architectures rather than an oversight specific to any one deployment, which is the same underlying gap driving Shadow AI: an organization can't govern what it can't attribute to a specific, accountable agent identity in the first place.

OWASP-STATE also names deployment-layer safety and security as functions that cannot be governed separately for autonomous agents, which is less a fully resolved risk model than an early diagnosis of a coordination failure most organizations haven't yet built the internal structure to solve: security and safety teams that operate independently for traditional software often can't simply be merged for agentic systems without real organizational change, and none of the sources in this corpus claim to have a proven template for making that change.

• Shadow AI is treated as already present in every organization, not a hypothetical future risk (OWASP-STATE)
• The attribution gap, the lack of a distinct governed agent identity, is named as a structural problem across current architectures (OWASP-TOP10)
• Deployment-layer safety and deployment-layer security cannot be governed as separate functions for autonomous agents, though no source claims a proven organizational template for merging them (OWASP-STATE)

OpenCRE crosswalk: Threat Modeling, Access Control, Governance Risk and Compliance.

12. AI/ML Architectural Risk and the Limits of Security Metrics

The oldest material in this corpus predates the agentic wave and addresses ML security at the design level, before an agent or an MCP server was part of the picture. BIML-SE opens with a framing point worth stating directly, since the rest of the corpus mostly assumes it: machine learning is "sophisticated associative-learning technology," not magic, and its recent progress owes more to faster hardware and larger datasets than to a scientific breakthrough in how the underlying algorithms work, which matters because it argues against treating ML systems as unknowable black boxes exempt from ordinary security engineering. BIML-ARA and BIML-NOMETER both treat security as an emergent, system-wide property rather than a score: BIML-NOMETER states outright that no benchmark or leaderboard can certify a system as secure, because a benchmark only ever measures the absence of known badness, never the presence of security, and that published benchmarks carry their own risk of contamination or leakage into training data, which undermines the benchmark's validity over time even when nothing about the system itself has changed. BIML-ARA adds that a system is only as secure as its weakest of nine generic ML components, and that logical or pipeline boundaries are not automatically trust boundaries unless someone explicitly establishes them, meaning the mere existence of a module boundary in a system diagram doesn't imply any actual security enforcement happens at that line.

BIML-LLM24 and BIML-23RISKS extend this to foundation models specifically: a foundation model is an opaque black box, and complete verification or control through prompting alone is never achievable, so accountability for an LLM application's risk rests with whoever builds or fields it, regardless of what's hidden inside the model itself. BIML-23RISKS is specific about what that accountability actually requires in practice: training data must not be legally encumbered by copyright, CSAM, or GDPR right-to-be-forgotten obligations, randomness used for weights and thresholds must use cryptographic-grade generators rather than naive ones, and evaluation criteria and results must be real and scrutinizable rather than kept as trade secrets. BIML-NOMETER closes the set with a specific methodological recommendation: instead of scoring a model's output directly, security assurance should follow software security's own historical arc from ad hoc testing toward process-based assurance models like BSIMM, measuring the rigor of the process that produced the system rather than trying to measure the system's output as a proxy for its security.

• Architectural risk analysis, meaning design-level threat modeling, comes before operational bolt-on fixes, not after (BIML-SE, BIML-ARA, BIML-LLM24)
• Classic security design principles (fail securely, least privilege, compartmentalize, defense in depth, keep it simple, be reluctant to trust) apply directly to ML systems (BIML-ARA)
• Training data curation, provenance, and integrity are a foundational control, not an afterthought (BIML-LLM24, BIML-23RISKS)
• Red-teaming and anthropomorphizing a model are treated with explicit skepticism as sufficient validation on their own (BIML-LLM24, BIML-23RISKS, BIML-NOMETER)
• Recursive pollution, meaning a model trained on its own or another model's output, degrades integrity across generations and has to be guarded against directly (BIML-LLM24, BIML-23RISKS)
• Randomness used for model weights and thresholds relies on cryptographic-grade generators, never naive or predictable ones (BIML-23RISKS)
• Security assurance follows a process-based model, measuring the rigor of development rather than scoring model output as a proxy for security (BIML-NOMETER)

OpenCRE crosswalk: Threat Modeling, Secure Product Design, Data Protection, Supply Chain, Vulnerability Management, Training and Awareness.

13. Data and Model Provenance Across the AI Supply Chain

CoSAI's original workstream on supply chain security treats the AI supply chain as four interdependent dimensions, data, model, application, and infrastructure, where a vulnerability introduced at any one stage propagates through the rest, and explicitly rejects the assumption that an internally developed or internally stored model is inherently safer than a third-party one simply by virtue of being kept in-house (COSAI-SUPPLY). Its companion paper on artifact signing gets specific about what a fix looks like: every model artifact carries a signature tying a producer's identity to its exact contents, a single manifest has to cover the full collection of files so nothing drifts out of sync between what was signed and what actually ships, and a consumer authenticates the signer's identity against its own deployment policy rather than trusting a central authority to make that call on its behalf (COSAI-SIGN). COSAI-SIGN also describes a progressive maturity model running from basic integrity checks through signature chaining to fully structured attestations, which gives organizations a staged path rather than requiring the most rigorous form of verification on day one.

NIST-ADVML and the SANS guidelines converge on the same underlying concern from different angles, treating an AI Bill of Materials as a governance artifact on par with a traditional software bill of materials (SANS-CAISG12, SANS-BLUEPRINT), while CSA-AICM11 requires that model weights, training data, and inference pipelines stay protected against poisoning, manipulation, and unauthorized access at all times, not just at deployment, and frames this as an extension of existing cloud supply chain practice rather than a new discipline invented for AI. OWASP-DATASEC adds a rule that closes a specific gap the signing-focused papers leave implicit: classification labels attached to a dataset have to propagate to every derivative of that dataset, so a model trained on restricted data doesn't lose that restriction simply because the data passed through a transformation step first.

• Every model artifact carries a signature tying producer identity to its exact content, verified before use (COSAI-SIGN)
• Unsafe serialization formats, such as pickle, are never used for model persistence or exchange (COSAI-SUPPLY)
• Unsigned datasets, checkpoints, or pipeline artifacts are never loaded, executed, or promoted (OWASP-DATASEC)
• Model and data provenance stay tamper-proof, traceable end to end, and continuously monitored rather than vetted once at intake (COSAI-SUPPLY, NIST-GAI, CSA-AICM11)
• An internally developed or internally stored model is never assumed safer by default than a third-party one (COSAI-SUPPLY)
• Signature verification follows a staged maturity path, from basic integrity checks to full structured attestation, rather than requiring the strictest form immediately (COSAI-SIGN)
• Data classification labels propagate to every derivative of a dataset, surviving transformation steps rather than being lost along the way (OWASP-DATASEC)

OpenCRE crosswalk: Supply Chain, Cryptography, Data Protection, Access Control, Secure Product Design, Log Management.

14. Adversarial Machine Learning and Attack Taxonomies

NIST-ADVML gives this its most rigorous treatment, mapping every adversarial attack's objective to exactly one of three violations: an availability breakdown, an integrity violation, or a privacy compromise, and requiring that any attack classification specify the learning stage, the attacker's goals, capabilities, and knowledge together, rather than describing an attack only by the technique used. It insists that mitigations be evaluated against strong, adaptive, worst-case adversaries rather than weak or static ones, and is explicit that a robustness-accuracy trade-off is inherent to current mitigation techniques: no defense offers an absolute guarantee against a future, evolved attack, and a system tuned for maximum robustness against known attacks will typically sacrifice some accuracy on clean, non-adversarial input as the cost of that robustness. It also draws a distinction the rest of the corpus mostly treats as one problem: predictive AI (PredAI) and generative AI (GenAI) require related but distinct taxonomies, since the attack surface of a classifier making a discrete prediction differs meaningfully from that of a generative model producing open-ended output.

OWASP-REDTEAM makes a related point from the testing side rather than the taxonomy side: jailbreaks are only a small subset of the risk in tool-using or agentic systems, so a red-teaming vendor that tests jailbreaks alone is offering only superficial coverage of what NIST-ADVML's taxonomy actually describes, which spans availability, integrity, and privacy attacks across the full ML lifecycle rather than just the narrow slice of prompt-based jailbreaking that gets the most public attention.

• Every attack's objective maps to availability breakdown, integrity violation, or privacy compromise, with no fourth category (NIST-ADVML)
• Defenses are evaluated against adaptive, worst-case adversaries, never against a fixed or weak attacker model (NIST-ADVML)
• No mitigation offers an absolute guarantee; empirical defenses remain vulnerable to attacker techniques that haven't been invented yet (NIST-ADVML)
• A robustness-accuracy trade-off is treated as inherent to current mitigation techniques, not a solvable engineering gap (NIST-ADVML)
• Predictive AI and generative AI require related but distinct attack taxonomies rather than one taxonomy applied uniformly to both (NIST-ADVML)

OpenCRE crosswalk: Threat Modeling, Data Protection, Supply Chain, Vulnerability Management, Secure Product Design, Training and Awareness.

15. AI Risk Governance Frameworks

Where Shared Responsibility and Layered Accountability covers who is accountable for a given AI activity, this section covers the broader process frameworks that govern risk management generally. NIST-RMF requires that its Govern function run through Map, Measure, and Manage continuously, rather than sit beside them as a fourth, separate step, and it's explicit that risk equals likelihood times magnitude of impact, that residual risk always remains after mitigation and must be disclosed rather than hidden, and that a system presenting unacceptable or catastrophic risk has to stop, regardless of business pressure to ship it. It frames Valid & Reliable as the necessary base condition underlying every other trustworthiness characteristic in its model, meaning a system that isn't reliable in the first place can't meaningfully be called safe, secure, or fair no matter how well it scores on those other dimensions individually.

CSA-AICM11 exists to fill a gap it says NIST AI RMF and the EU AI Act leave open on purpose: both name risk categories without specifying the operational security controls that satisfy them, which is the specific hole a vendor-agnostic control matrix is built to fill, and CSA-AICM11 positions itself explicitly as a superset of the Cloud Controls Matrix rather than a parallel framework, on the premise that cloud security is the necessary foundation AI security has to build on rather than a separate concern. NIST-GAI extends the same RMF functions to generative AI specifically, adding that some GAI risks are empirically known while others remain speculative given how immature GAI measurement science still is, and requires content provenance tracking across the lifecycle using mechanisms like cryptographic watermarking, treating provenance as a control that belongs inside the risk management framework rather than as a separate technical add-on. NIST-PLAYBOOK operationalizes the RMF into practice, and is explicit about what it isn't: its suggestions are voluntary and non-exhaustive, never a mandatory checklist, and it pushes organizations to consider non-AI alternatives rather than assume an AI system is the right tool by default, a framing choice that sets it apart from most of the rest of the corpus, which generally assumes the AI system is already being built and asks how to secure it rather than whether to build it at all.

• The Govern function runs through Map, Measure, and Manage continuously; it is not a separate fourth step (NIST-RMF)
• A system presenting unacceptable or catastrophic risk stops, regardless of business pressure to proceed (NIST-RMF)
• Risk management frameworks and operational control catalogs serve different purposes and don't substitute for each other: a risk framework names what to manage, a control matrix specifies how (CSA-AICM11)
• Control ownership is assigned per stakeholder role, never left ambiguous, across every pillar of a governance framework (CSA-AICM1, CSA-AICM11)
• Valid & Reliable is treated as the necessary base condition underlying every other trustworthiness characteristic, not one criterion among equals (NIST-RMF)
• Governance guidance explicitly considers whether an AI system is the right tool at all, not only how to secure one already being built (NIST-PLAYBOOK)

OpenCRE crosswalk: Governance Risk and Compliance, Threat Modeling, Secure Product Design, Data Protection, Training and Awareness.

16. Data Security Within AI Environments

CSA-DATA applies the CIA triad across the full AI data lifecycle, meaning collection, annotation, storage, processing, training, deployment, and monitoring, and treats each stage as its own exposure point rather than assuming a single perimeter control covers all of them, which is a meaningfully different posture than traditional data security, where a smaller number of well-defined storage and transit points usually cover most of the exposure surface. OWASP-DATASEC identifies a genuinely new failure mode inside that lifecycle: the context window fuses multiple trust domains into one flat namespace with no internal access control, which is a risk traditional software security never had to account for, since a conventional application can enforce access boundaries between different data sources at the code level in a way an LLM's context window structurally cannot once everything has been concatenated into a single prompt. It also echoes a point BIML-LLM24 makes about foundation models generally: machine unlearning is technically limited, so data an organization believes it deleted can persist indefinitely inside model weights or embeddings, which means a data deletion request can be satisfied at the storage layer while remaining technically unsatisfied at the model layer, a distinction most data governance policies weren't written with in mind.

• Sensitive data stays encrypted at rest, in transit, and in use, without exception (CSA-DATA)
• Non-human identities interacting with data are rotated periodically, with no standing exemption (CSA-DATA)
• Classification labels propagate to every derivative of a dataset, not just the raw source (OWASP-DATASEC)
• Deleting source data does not guarantee removal from a trained model's weights or embeddings (OWASP-DATASEC, BIML-LLM24)
• Each stage of the AI data lifecycle, from collection through monitoring, is treated as its own exposure point rather than covered by a single perimeter control (CSA-DATA)
• The LLM context window is treated as a flat namespace with no internal access control between the trust domains it merges, a risk category traditional software security did not previously need to address (OWASP-DATASEC)

OpenCRE crosswalk: Access Control, Cryptography, Data Protection, Secrets Management, Log Management, Supply Chain, Secure Product Design.

17. AI Incident Response and Vulnerability Operations

COSAI-DEFEND makes the case for why this needed its own framework in the first place: defenses are only as strong as their weakest point, AI systems expand the attack surface well past traditional software, and securing them is described as "a team sport" requiring coordinated effort across roles rather than a single security function acting alone. It treats separation of code and data as a non-negotiable core principle, not a nice-to-have, and adds an accountability point specific to AI-assisted contributions: contributors remain personally responsible for content produced with AI assistance under their own signed contributor agreements, regardless of how much of the work the AI tool actually generated. COSAI-IR builds on that foundation with the actual response mechanics, splitting AI incidents into five domains, data, model, deployment, infrastructure, and user interaction, on the premise that general incident response is already well documented elsewhere and this framework only needs to cover the AI-specific gaps rather than restate the whole discipline from scratch. It requires raw prompts, system prompts, parameters, and completions to be logged and preserved for forensic reconstruction, and states containment actions must never destroy evidence in the process of stopping an incident, which is a real tension in practice: the fastest way to stop an active incident is often to kill the process or wipe the environment, and COSAI-IR is explicit that speed can't come at the cost of forensic soundness.

OWASP-IR adds a governance detail COSAI-IR doesn't specify: every critical AI system or model needs an assigned owner at all times, and non-human identities interacting with AI systems must be inventoried and controlled as part of the response plan, since an unaccounted-for agent identity is itself a blind spot during an incident, one that can make root-cause analysis effectively impossible if nobody can say with confidence which agent identities had access to what at the time of compromise. CSA-VULN adds urgency to the timeline: the discovery-to-weaponization window for AI-assisted exploit generation has collapsed from weeks to hours, which is why it argues a permanent Vulnerability Operations capability, not a periodic patch cycle, is now the baseline requirement rather than an aspiration, and it names blast-radius containment through segmentation as the primary control once discovery volume rises past what any patch cadence can keep pace with.

• Securing AI systems is treated as a coordinated, cross-role effort, not a task for the security team alone (COSAI-DEFEND)
• AI incidents are classified into five domains: data, model, deployment, infrastructure, user interaction (COSAI-IR)
• Raw prompts, parameters, and completions are logged and preserved for forensic reconstruction; containment never destroys evidence (COSAI-IR)
• Every critical AI system has an assigned owner, and non-human identities are inventoried and controlled as part of incident response (OWASP-IR)
• A permanent Vulnerability Operations capability replaces the periodic patch cycle, since the discovery-to-weaponization window has collapsed to hours (CSA-VULN)
• Post-incident reviews are always blameless, and remediation addresses the underlying vulnerability, not just its symptom (COSAI-IR)
• Contributors remain personally accountable for AI-assisted work product under their own signed agreements, regardless of how much the AI tool generated (COSAI-DEFEND)
• Blast-radius containment through segmentation is the primary control once vulnerability discovery volume outpaces any realistic patch cadence (CSA-VULN)

OpenCRE crosswalk: Log Management, Access Control, Data Protection, Vulnerability Management, Secrets Management, Threat Modeling.

18. Red Teaming, Testing, and Vendor Evaluation

OWASP-REDTEAM defines AI red teaming as adversarial testing across safety, security, misuse, robustness, ethics, and alignment failures together, not as a synonym for jailbreak testing, and separates its guidance by system maturity: most organizations currently run simple GenAI systems, with a smaller but fast-growing share running advanced, tool-using, or agentic ones, and both categories carry risks requiring specialized adversarial testing even though the sophistication of that testing has to differ between them. It states no vendor can legitimately claim full coverage or one-click red teaming, and that critical or emergent-behavior findings always require human verification rather than an LLM-judge scoring itself, on the reasoning that using an LLM to grade another LLM's safety failures inherits the same blind spots the test was designed to catch in the first place. It also requires that metrics be quantitative, reproducible, and tied to real business risk rather than qualitative "vibes"-based scoring, and that destructive tool testing happen in a sandboxed, dry-run environment rather than against production, since a red team exercising an agent's real tool-calling capability against live systems risks causing the exact damage the test is meant to evaluate the agent's resistance to.

OWASP-REDTEAM also requires that engagements be explicitly authorized, scoped, and bounded by defined rules of engagement, and that data handling during testing follow clear retention, isolation, and access-control policies regardless of which vendor is running the engagement, treating the red-teaming provider itself as a party that needs to be governed with the same rigor as any other third party with privileged access to the system under test.

• No vendor legitimately claims full coverage or one-click red teaming (OWASP-REDTEAM)
• Critical or emergent-behavior findings require human verification, not LLM-judge-only scoring (OWASP-REDTEAM)
• Tool calls, MCP outputs, and agent actions are never assumed inherently safe during testing (OWASP-REDTEAM)
• Testing guidance is calibrated to system maturity, since simple and advanced or agentic GenAI systems carry different risk profiles requiring different testing sophistication (OWASP-REDTEAM)
• Destructive tool testing happens in a sandboxed, dry-run environment rather than against production systems (OWASP-REDTEAM)
• Red-teaming vendors themselves are governed under explicit authorization, scope, and data-handling policy, the same as any other privileged third party (OWASP-REDTEAM)

OpenCRE crosswalk: Threat Modeling, Vulnerability Management, Access Control, Log Management, Data Protection, Supply Chain.

19. General LLM and GenAI Application Security

OWASP-LLMTOP10 restates the core untrusted-input problem in application terms: since an LLM cannot reliably distinguish trusted instructions from untrusted content, untrusted external content is always segregated and labeled apart from trusted instructions rather than trusted by default, and authorization decisions are always enforced downstream rather than left to the model to police itself. It also names the enabling condition behind most of the OWASP Top 10 risks directly: LLM-based systems are commonly granted agency, meaning function calls, extensions, and tools, by their developers, and it's this grant of agency, not the underlying language model itself, that turns a text-generation risk into an action-taking one. OWASP-AIEXCHANGE states the same access-control rule as a flat prohibition rather than a best practice: access control is never delegated to the GenAI model or agent itself, which it frames as a specific instance of a more general axiom: an AI model can always be wrong or manipulated, and that has to be treated as a constant condition to design around, not an edge case to handle separately when it comes up.

CIS-LLM requires a strict separation between system prompts, user input, and retrieved context, and treats prompt and guardrail changes as configuration items that go through version control and change approval like any other production configuration, which is a notable framing choice: it treats a prompt edit with the same operational seriousness as a firewall rule change, rather than as a lightweight content update a developer can push without review. OWASP-SOLUTIONS ties these individual rules back to a single organizing frame, mapping vendor tooling against the OWASP LLM Top 10 across an LLMOps/LLMSecOps lifecycle, and makes the dependency explicit: an organization cannot secure its agents without first securing the models and infrastructure those agents sit on top of, which is the same layering logic found throughout this document, that agent-specific controls in sections 1 through 11 only hold if the underlying model and infrastructure controls in this section are already in place. OWASP-AIEXCHANGE also names the "lethal trifecta," meaning private data exposure plus untrusted content plus an exfiltration channel together, as a systemic risk pattern; the same concept reappears almost unchanged in OWASP-STATE's agentic paper, covered in Untrusted Input and the Prompt Injection Problem, which is a sign it's a cross-cutting risk pattern rather than an agent-specific one that just happened to get independently rediscovered and renamed.

• Untrusted external content is segregated and labeled apart from trusted instructions, never trusted by default (OWASP-LLMTOP10)
• Access control is never delegated to the model or agent itself (OWASP-LLMTOP10, OWASP-AIEXCHANGE)
• Extension and tool permissions never exceed what the specific function requires (OWASP-LLMTOP10)
• A strict separation exists between system prompts, user input, and retrieved context, enforced as a configuration item under change control (CIS-LLM)
• An AI model being wrong or manipulated is treated as a constant design condition, not an edge case handled separately when it occurs (OWASP-AIEXCHANGE)
• Agent-level security controls are only meaningful once the underlying model and infrastructure security they depend on is already in place (OWASP-SOLUTIONS)

OpenCRE crosswalk: Access Control, Input Validation, Injection Prevention, Secure Product Design, Log Management, Supply Chain.

20. Enterprise AI Security Programs and Organizational Readiness

SANS-CAISG1 opens with a stance the rest of the corpus assumes but rarely states directly: the biggest risk of AI is not using it, so a security team's job is to secure adoption, not block it, and the guidance itself is explicitly point-in-time given how fast the landscape moves, which is a candid acknowledgment that a guidelines document in this space has a shorter useful shelf life than most security guidance historically has. It's also blunt that a model's guardrails are never a sufficient boundary on their own: a model must never have access to data or actions it isn't permitted to disclose or take, regardless of how strong its guardrails are, which restates the access-control-never-delegated-to-the-model rule from General LLM and GenAI Application Security as an architectural requirement rather than a policy statement, meaning the access simply shouldn't exist for the model to disclose in the first place, rather than existing and being suppressed by a guardrail.

SANS-BLUEPRINT treats model registries as non-negotiable for production AI governance and places ultimate accountability for AI risk outcomes on the board and executive team, not the security function alone, framing AI as the most transformative technology shift since the internet and organizing its guidance around a three-track accountability model: protect AI, utilize AI, and govern AI, run as distinct but coordinated tracks rather than folded into a single undifferentiated AI security effort. It also states a position phrased more aggressively than anywhere else in the corpus: security teams need to "fight fire with fire," using AI defensively to match the speed of AI-assisted attacks, on the premise that a purely human-paced defensive process cannot keep up with an AI-accelerated offensive one. CSA-STATE, looking at the broader cloud environment AI now runs inside of, finds a widening gap between how fast AI adoption is moving and how ready security programs actually are, and names identity, not infrastructure, as the primary attack surface for both cloud and AI workloads alike, adding that most current security programs remain reactive and incident-focused by default rather than preventive, even though the organizations surveyed generally already know that a preventive posture would serve them better.

• A model's guardrails are never treated as a sufficient security boundary on their own (SANS-CAISG1, SANS-CAISG11)
• Model registries are a non-negotiable governance requirement for production AI (SANS-BLUEPRINT)
• Ultimate accountability for AI risk outcomes sits with the board and executive team, not the security function alone (SANS-BLUEPRINT)
• Identity, not infrastructure, is the primary attack surface for both cloud and AI workloads (CSA-STATE)
• AI security guidance is treated as explicitly point-in-time given how fast the field moves, rather than written as a stable, long-lived standard (SANS-CAISG1)
• Governance is organized around three distinct, coordinated tracks: protecting AI, utilizing AI, and governing AI, rather than one undifferentiated program (SANS-BLUEPRINT)
• Current security programs remain reactive and incident-focused by default, despite general awareness that a preventive posture would be more effective (CSA-STATE)

OpenCRE crosswalk: Access Control, Data Protection, Log Management, Secure Product Design, Supply Chain, Training and Awareness, Governance Risk and Compliance.

Source Documents

Agentic security (Sections 1-11)

Supply chain and general AI security (Sections 12-20)