Common Weakness Enumeration (CWE) for AI

Why enterprises need CWE for AI systems

Enterprise security teams already use CWE as a shared dictionary of software and hardware weakness types to identify, classify, and prioritize flaws. AI applications and agents do not replace that need. They expand it. Agents combine model outputs with tool calls, retrieved context, workload identities, and permission grants. Those paths create classic implementation weaknesses in orchestration code, APIs, secret handling, adapters, and telemetry, alongside risks that conventional SDLC checklists only partially cover.

OWASP’s Top 10 for LLM Applications names risks that show up repeatedly in production agents: prompt injection, insecure output handling, sensitive information disclosure, excessive agency, and insufficient logging and monitoring. Several of those issues map cleanly to established CWE families when the root cause is weak authorization, injection at a trust boundary, credential mismanagement, or missing audit evidence. MITRE ATLAS complements CWE by cataloging AI-specific adversary tactics and techniques. NIST’s AI RMF frames how organizations govern, map, measure, and manage risk across the AI lifecycle, including deployed human–AI configurations. CWE remains the practical taxonomy for weakness management inside AppSec and vulnerability programs; ATLAS and AI RMF supply the broader attack and risk context.

A CWE lens across the agent runtime

Use four connected practices when you apply CWE to agents. Map findings to established classes where code, config, or integration flaws apply. Separate fixable implementation weaknesses from residual model or behavioral risk. Control identity, permissions, tool policy, and audit trails before side effects occur. Operate remediation through standard AppSec weakness workflows with runtime telemetry.

• MapTie agent findings to established CWE classes where code, config, or integration flaws apply.
• SeparateDistinguish fixable implementation weaknesses from residual model or behavioral risk.
• ControlEnforce identity, permissions, tool policy, and audit trails before side effects occur.
• OperatePrioritize and remediate through standard AppSec weakness workflows with runtime telemetry.

Which CWE categories apply to AI apps and agents

Most CWE-addressable AI issues live in runtime and integration layers, not in model weights. Authorization and authentication gaps appear when agents inherit broad tokens, skip per-tool permission checks, or conflate user identity with agent or tool identity. Injection and unsafe external interaction weaknesses resurface when natural language, retrieved documents, or tool results are turned into arguments, queries, commands, or egress without validation. Credential and secret exposure shows up when long-lived keys are embedded in prompts, contexts, environment defaults, or logs. Information exposure and insufficient logging weaken detection when agent decisions, context sources, policy outcomes, and tool effects cannot be reconstructed.

AI Common Weakness Enumeration practice therefore reuses familiar classes: broken or missing authorization, OS/command/code injection patterns, credential management failures, sensitive data in logs, and trust-boundary failures with external services. Model Context Protocol (MCP) and similar tool/context buses make these surfaces more explicit. Hosts, servers, tools, and upstream data each introduce authentication, scope, input handling, and data exfiltration assumptions. Excessive agency is often an authorization and policy design failure: the model can request actions the runtime should never allow under the user’s or task’s actual authority.

CWE-addressable weakness versus AI-specific behavioral risk

Keep implementation defects and model-driven residual risk on different remediation tracks. CWE is most useful when a concrete flaw in code, configuration, identity binding, input handling, or telemetry can be owned, scored, and verified fixed. Probabilistic model behavior and adversarial ML patterns still need compensating controls, even when the surrounding software is implemented correctly.

Map weaknesses across the agent runtime lifecycle

A durable AI security weakness taxonomy follows the agent path rather than a single prompt checkbox. Security engineers should assess each stage for CWE-relevant defects and for places where model output must be treated as untrusted input.

1. Identity and session binding: Confirm user, agent/workload, and tool/service identities are explicit and not interchangeable.
2. Context intake: Treat prompts, retrieved documents, and memory as untrusted input at every boundary.
3. Planning and tool selection: Constrain which tools exist for the task and under what policy.
4. Argument construction: Canonicalize and schema-validate parameters before invocation.
5. Execution and side effects: Enforce allow/deny, rate limits, and blast-radius caps before tools run.
6. Result handling: Treat tool outputs as untrusted data that can reintroduce injection or confused-deputy patterns.
7. Telemetry and review: Retain correlated evidence of context, policy, tool use, and downstream effects.

Evidence, telemetry, and remediation that make CWE usable

Identifying CWE mapping for AI systems requires evidence that connects an observed behavior to a concrete weakness in the runtime path. Inventory every tool and data connector with required scopes, data classifications, and assumed failure modes (injection, authz bypass, secret leakage, incomplete audit). Treat model output and retrieved context as untrusted at every boundary. Prefer short-lived, audience-scoped credentials from secret stores; never rely on secrets embedded in prompts, long-lived environment defaults shared across agents, or verbose logs.

Telemetry should be structured enough to support prioritization and incident response: context identifiers with redaction, tool names and redacted parameters, policy allow/deny decisions, caller identities, and execution outcomes. When a finding maps to a CWE class, route it through standard weakness management with an owner, severity, and SLA. When correct implementation still leaves residual model-driven risk, pair the backlog item with runtime guardrails rather than hoping model tuning alone will bound tool misuse. CISA secure-by-design guidance reinforces the same outcome focus: reduce exploitability with least privilege and measurable product security controls, including for AI-enabled services.

Governance alignment without a separate weakness silo

There is no single universal replacement catalog called “CWE for AI.” Effective programs combine CWE for implementation weakness management, OWASP LLM risk categories for application threat framing, MITRE ATLAS for adversary techniques against AI/ML, and NIST AI RMF for organizational risk functions. Mappings from an LLM risk name to a specific CWE ID depend on architecture: the same OWASP item may land on different weakness types in different agent designs.

Operationally, keep AI agent findings in the same backlog hygiene model used for other software where CWE applies, and assign RMF-style ownership for map, measure, and manage activities across first-party and third-party models and tools. Require auditable proof of tool-use policy and access reviews when agents can take automated actions. Vendor security claims are not substitutes for verifying runtime identity, permission, tool governance, and logging controls in your environment.

Trussed AI focuses on runtime governance and security for enterprise AI agents, including policy enforcement, agent identity and permissions, tool approval workflows, MCP-oriented control points, monitoring, and audit logging. Use that class of runtime capability to make CWE-aligned fixes enforceable on the path where agents actually act.