fix(owasp): migrate OWASP catalogue from AT to ASI 2026 taxonomy

[jackbatzner]

Description

Migrates the copilot-governance OWASP risk catalogue from the legacy AT (LLM Top 10) identifiers to the canonical ASI (Agentic Security Initiatives) 2026 taxonomy. The AT and ASI taxonomies do not map 1:1 by number (e.g., AT07 was Insecure Plugin Design but ASI07 is Insecure Inter-Agent Communication), so this removes the numeric mapping entirely and updates all references semantically.

Changes

• owasp.ts: Replaced all 10 OWASP_AGENTIC_RISKS entries with correct ASI01-ASI10 titles and descriptions from the 2026 release
• reviewer.ts: Migrated all 14 governance rule tags from AT to ASI IDs using semantic mapping (no tag where mapping is unclear)
• types.ts: Updated JSDoc example from AT to ASI
• README.md: Updated example output and governance checks table to use ASI IDs
• tests: Updated assertions for ASI-only behavior; legacy ATxx inputs are silently skipped

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Package(s) Affected

• agent-governance

Checklist

• My code follows the project style guidelines (ruff check)
• I have added tests that prove my fix/feature works
• All new and existing tests pass (pytest)
• I have updated documentation as needed
• I have signed the Microsoft CLA

Related Issues

Relates to Discussion #814 (Agentic Standards Landscape - OWASP alignment)

[github-actions]

🤖 AI Agent: security-scanner — Security Review of PR: OWASP Taxonomy Migration

Security Review of PR: OWASP Taxonomy Migration

This PR migrates the OWASP risk catalog from the legacy AT identifiers to the ASI 2026 taxonomy. While the changes are primarily semantic and documentation-focused, they touch critical components of the agent-governance-toolkit, including the OWASP risk catalog (owasp.ts), governance rules (reviewer.ts), and associated documentation and tests. Below is a security analysis of the changes.

---

Findings

1. Prompt Injection Defense Bypass

• Severity: 🔴 CRITICAL
• Issue: The updated OWASP risk catalog (owasp.ts) introduces a new risk, ASI01: Agent Goal Hijack, which explicitly mentions indirect prompt injection. However, the reviewer.ts file does not include any new rules or updates to existing rules to detect or mitigate this risk. The existing rule for prompt injection (AT01) was removed, but no equivalent rule for ASI01 was added.
• Attack Vector: Without a rule to detect prompt injection vulnerabilities, agents using this library may remain vulnerable to crafted inputs that manipulate agent behavior, bypassing policy checks.
• Recommendation: Add a new rule in reviewer.ts to detect prompt injection vulnerabilities, specifically targeting ASI01. For example:

  {
    ruleId: "prompt-injection",
    title: "Potential prompt injection vulnerability",
    severity: "high",
    owaspRisks: ["ASI01"],
    detect(source) {
      const hasUnfilteredInput = /userInput|req\.body|request\.data/.test(source) &&
                                 !/sanitizeInput|validateInput/.test(source);
      if (hasUnfilteredInput) {
        return {
          description: "Unfiltered user input is passed to the agent, making it vulnerable to prompt injection.",
          suggestion: "Sanitize or validate user input before passing it to the agent. For example:\n\n" +
                      "```ts\nconst sanitizedInput = sanitizeInput(userInput);\nagent.process(sanitizedInput);\n```",
        };
      }
      return null;
    },
  }

2. Policy Engine Circumvention

• Severity: 🟠 HIGH
• Issue: The migration removes numeric mappings between old AT identifiers and new ASI identifiers, but the reviewer.ts file does not include fallback handling for legacy identifiers. This could lead to scenarios where older policies or configurations referencing AT identifiers are silently ignored.
• Attack Vector: If a user has policies or configurations using AT identifiers (e.g., AT07), these may no longer trigger governance checks, effectively bypassing security policies.
• Recommendation: Add backward compatibility for legacy AT identifiers in reviewer.ts. For example:

  const LEGACY_TO_ASI_MAP = {
    AT01: "ASI01",
    AT07: "ASI02",
    AT08: "ASI03",
    // Add other mappings as needed
  };
  
  function mapLegacyRisks(ids: string[]): string[] {
    return ids.map(id => LEGACY_TO_ASI_MAP[id] || id);
  }

3. Trust Chain Weaknesses

• Severity: 🔵 LOW
• Issue: The OWASP risk catalog now includes ASI07: Insecure Inter-Agent Communication, which highlights risks related to authentication, encryption, and schema validation in agent communication. However, the reviewer.ts file does not include any rules to detect such vulnerabilities.
• Attack Vector: Agents may communicate insecurely with other agents or components, exposing sensitive data or enabling man-in-the-middle attacks.
• Recommendation: Add a rule to detect insecure inter-agent communication patterns, such as missing authentication or encryption mechanisms.

4. Credential Exposure

• Severity: 🟡 MEDIUM
• Issue: The updated OWASP catalog includes ASI03: Identity & Privilege Abuse, which mentions credential mishandling. However, no new rules were added to detect hardcoded credentials or insecure credential storage.
• Attack Vector: Hardcoded credentials or insecure storage could lead to unauthorized access or privilege escalation.
• Recommendation: Add a rule to detect hardcoded credentials in source code. For example:

  {
    ruleId: "hardcoded-credentials",
    title: "Hardcoded credentials detected",
    severity: "medium",
    owaspRisks: ["ASI03"],
    detect(source) {
      const hasHardcodedCredentials = /['"](?:password|apiKey|secret)['"]\s*:\s*['"].+['"]/.test(source);
      if (hasHardcodedCredentials) {
        return {
          description: "Hardcoded credentials were found in the source code.",
          suggestion: "Store credentials securely using environment variables or a secret management service.",
        };
      }
      return null;
    },
  }

5. Supply Chain Vulnerabilities

• Severity: 🟠 HIGH
• Issue: The new risk ASI04: Agentic Supply Chain Vulnerabilities highlights risks related to compromised or malicious dependencies. However, there is no evidence of dependency validation or monitoring in the changes.
• Attack Vector: Dependency confusion or typosquatting attacks could compromise the agent's supply chain.
• Recommendation: Integrate a dependency validation tool (e.g., npm audit, snyk) into the CI/CD pipeline and document this in the README.

---

Summary of Findings

Category	Severity	Issue	Recommendation
Prompt Injection Defense Bypass	🔴 CRITICAL	No rule for ASI01: Agent Goal Hijack (indirect prompt injection).	Add a new rule to detect prompt injection vulnerabilities.
Policy Engine Circumvention	🟠 HIGH	Legacy AT identifiers are not mapped to ASI identifiers, risking policy bypass.	Add backward compatibility for legacy AT identifiers.
Trust Chain Weaknesses	🔵 LOW	No rule for ASI07: Insecure Inter-Agent Communication.	Add a rule to detect insecure inter-agent communication patterns.
Credential Exposure	🟡 MEDIUM	No rule to detect hardcoded credentials or insecure credential storage.	Add a rule to detect hardcoded credentials.
Supply Chain Vulnerabilities	🟠 HIGH	No validation or monitoring of dependencies for ASI04: Agentic Supply Chain Vulnerabilities.	Integrate a dependency validation tool into the CI/CD pipeline.

---

Additional Notes

1. Documentation Updates: The README and other documentation were updated to reflect the new ASI taxonomy. These changes are accurate and align with the OWASP 2026 guidelines.
2. Test Coverage: The PR mentions updated tests for ASI-only behavior. Ensure these tests cover all new rules and edge cases.

By addressing the above findings, this PR can ensure a robust migration to the ASI 2026 taxonomy without introducing new security vulnerabilities.

[github-actions]

🤖 AI Agent: code-reviewer

Review Summary

This pull request migrates the OWASP risk catalog from the legacy AT (LLM Top 10) identifiers to the new ASI (Agentic Security Initiatives) 2026 taxonomy. The changes include updating all references to OWASP risks across the codebase, documentation, and tests. The migration is semantically correct and aligns with the updated OWASP taxonomy.

Below is a detailed review of the changes, focusing on the specified areas of concern.

---

Key Findings and Feedback

🔴 CRITICAL: Policy Engine Correctness

1. Semantic Mapping of OWASP Risks

   • The migration from AT to ASI taxonomy involves semantic mapping of risks. However, some mappings (e.g., AT07 → ASI02, ASI03) are not 1:1 and may lead to gaps in policy enforcement.
   • Actionable Fix: Add a fallback mechanism or explicit logging for unmapped or ambiguous cases. For example, if a rule previously mapped to AT07 but now maps to multiple ASI risks, ensure all relevant risks are flagged.

2. Silent Skipping of Legacy AT Identifiers

   • The updated getOwaspRisks function silently skips unknown IDs. This could lead to undetected risks if legacy identifiers are still referenced in older policies or tests.
   • Actionable Fix: Log a warning or error when an unknown ID is encountered to prevent silent failures.

---

🔴 CRITICAL: Trust/Identity

1. Identity & Privilege Abuse (ASI03)

   • The new taxonomy introduces ASI03 for identity and privilege abuse. However, the rules for detecting credential mishandling or privilege escalation are not updated in reviewer.ts.
   • Actionable Fix: Add explicit checks for credential leakage, improper token handling, and privilege escalation in the static analysis rules.

2. Insecure Inter-Agent Communication (ASI07)

   • The new taxonomy highlights inter-agent communication risks. The current implementation does not include checks for authentication, encryption, or schema validation in inter-agent communication.
   • Actionable Fix: Introduce rules to detect insecure communication patterns, such as unencrypted HTTP or lack of authentication in inter-agent API calls.

---

🔴 CRITICAL: Sandbox Escape Vectors

1. Unexpected Code Execution (ASI05)
   • The new taxonomy includes ASI05 for remote code execution (RCE). The current rules do not explicitly address this risk.
   • Actionable Fix: Add rules to detect unsafe code execution patterns, such as eval, exec, or subprocess calls without proper validation.

---

🟡 WARNING: Backward Compatibility

1. Breaking Changes in OWASP Risk Identifiers
   • The removal of AT identifiers and the introduction of ASI identifiers is a breaking change for any consumers relying on the old identifiers.
   • Actionable Fix: Provide a migration guide or a compatibility layer that maps old AT identifiers to their corresponding ASI identifiers.

---

💡 SUGGESTION: Type Safety and Validation

1. TypeScript Definitions

   • The OwaspRisk interface is well-defined, but the OWASP_AGENTIC_RISKS object could benefit from stricter typing to ensure all keys are valid ASI identifiers.
   • Actionable Fix: Use a TypeScript enum for ASI identifiers and enforce its usage in the OWASP_AGENTIC_RISKS object.

2. Validation of OWASP Risk References

   • The formatOwaspRisks function does not validate the input ids array. This could lead to runtime errors if invalid IDs are passed.
   • Actionable Fix: Add input validation to ensure all IDs in the ids array are valid ASI identifiers.

---

💡 SUGGESTION: Documentation

1. Updated OWASP Taxonomy

   • The documentation updates are thorough, but it would be helpful to include a section explaining the migration from AT to ASI taxonomy, especially for users familiar with the legacy identifiers.
   • Actionable Fix: Add a "Migration Guide" section in the README to explain the changes and provide examples of how to update existing policies.

2. Example Outputs

   • The example outputs in the README have been updated to use ASI identifiers. However, it would be helpful to include a note that legacy identifiers are no longer supported.
   • Actionable Fix: Add a note in the "Example Outputs" section to clarify that legacy AT identifiers are deprecated.

---

💡 SUGGESTION: Test Coverage

1. Backward Compatibility Tests

   • The PR mentions that legacy AT inputs are silently skipped in tests. This could lead to undetected regressions.
   • Actionable Fix: Add tests to explicitly verify that legacy AT identifiers are either correctly mapped or produce appropriate warnings.

2. New ASI Risks

   • The new ASI risks (e.g., ASI07, ASI10) are not explicitly tested in the updated test suite.
   • Actionable Fix: Add test cases for each new ASI risk to ensure they are correctly detected and reported.

---

Summary of Flags

• 🔴 CRITICAL:
  • Ensure semantic correctness in OWASP risk mapping.
  • Add rules for identity abuse (ASI03) and inter-agent communication (ASI07).
  • Detect sandbox escape vectors (ASI05).
• 🟡 WARNING:
  • Address breaking changes due to the removal of AT identifiers.
• 💡 SUGGESTION:
  • Improve type safety and validation.
  • Enhance documentation with a migration guide.
  • Expand test coverage for backward compatibility and new ASI risks.

---

Suggested Next Steps

1. Address the critical issues related to policy correctness, trust/identity, and sandbox escape vectors.
2. Provide a migration guide or compatibility layer for users transitioning from AT to ASI taxonomy.
3. Enhance the test suite to cover new ASI risks and backward compatibility scenarios.
4. Update documentation to include detailed explanations of the taxonomy migration.

Let me know if you need further clarification or assistance!

[imran-siddique]

OWASP taxonomy migration looks good. One blocker: link-check CI is failing — please fix the broken/changed OWASP URLs in the README, then this is ready to merge.

[github-actions]

🤖 AI Agent: code-reviewer

Review Summary

The pull request effectively migrates the OWASP risk catalogue from the legacy AT identifiers to the ASI 2026 taxonomy. This change is significant as it aligns the project with updated security standards. However, there are several areas that require attention regarding potential breaking changes, documentation, and security implications.

Actionable Feedback

🔴 CRITICAL Issues

1. Silent Skipping of Legacy AT Inputs: The change to silently skip legacy AT inputs in tests could lead to undetected vulnerabilities if users are still using the old identifiers. It is critical to ensure that all legacy identifiers are either deprecated with clear warnings or handled explicitly to avoid security bypasses. Consider logging a warning or error when legacy identifiers are encountered.

🟡 WARNING Issues

1. Breaking Changes in API: The migration from AT to ASI identifiers means that any existing integrations relying on the old identifiers will break. This is a significant change that should be documented clearly in the release notes. Consider providing a migration guide for users to transition from AT to ASI identifiers.

2. Changes in Governance Checks: The removal of certain mappings (e.g., AT09) and the introduction of new checks could lead to discrepancies in governance assessments. Ensure that the implications of these changes are well communicated to users, as they may affect compliance with existing policies.

💡 SUGGESTION Improvements

1. Documentation Updates: While the README and other documentation have been updated, consider adding a dedicated section that explains the rationale behind the migration to ASI identifiers. This will help users understand the importance of the change and how it impacts their usage.

2. Unit Tests for New Identifiers: Ensure that there are comprehensive unit tests covering all new ASI identifiers. This will help in validating that the new mappings are functioning as intended and that no regressions have been introduced.

3. Versioning Strategy: Given the significant changes, consider adopting a versioning strategy (e.g., semantic versioning) that clearly indicates breaking changes. This will help users manage dependencies more effectively.

4. Enhanced Error Handling: Instead of silently skipping unknown IDs, consider implementing a more robust error handling mechanism that provides feedback to users about deprecated or unknown identifiers. This could include logging warnings or throwing exceptions.

5. Backward Compatibility Layer: If feasible, consider implementing a backward compatibility layer that allows users to still use the AT identifiers while transitioning to ASI. This could ease the migration process for users with existing implementations.

Conclusion

The migration to the ASI 2026 taxonomy is a positive step towards enhancing the security posture of the agent-governance toolkit. However, it is essential to address the critical issues raised to prevent potential security vulnerabilities and ensure a smooth transition for users.

[github-actions]

🤖 AI Agent: code-reviewer

Pull Request Review: Migration to OWASP ASI 2026 Taxonomy

---

Summary of Changes

This PR migrates the OWASP risk catalog from the legacy AT taxonomy to the ASI 2026 taxonomy. It updates all references in the codebase, documentation, and tests to align with the new taxonomy. The numeric mapping between AT and ASI is removed due to the lack of a 1:1 correspondence, and semantic mapping is applied where possible.

---

🔍 Review Feedback

🔴 CRITICAL: Security Issues

1. Incomplete Mapping of OWASP Risks in Rules

   • In reviewer.ts, some rules (e.g., "No audit logging" and "No PII redaction") have no associated OWASP risks (owaspRisks: []).
   • Impact: This could lead to incomplete or inaccurate reporting of security risks, as findings are not mapped to the appropriate OWASP ASI risks.
   • Action: Ensure all rules are mapped to the most relevant ASI risks. For example:
     • "No audit logging" could map to ASI09 (Human-Agent Trust Exploitation).
     • "No PII redaction" could map to ASI06 (Memory & Context Poisoning) or ASI03 (Identity & Privilege Abuse).

2. Hardcoded URLs for OWASP Risks

   • The OWASP_AGENTIC_TOP_10_2026_URL_BASE is hardcoded in owasp.ts. If the OWASP website structure changes, this could lead to broken links.
   • Action: Implement a mechanism to validate or update these URLs dynamically or provide a fallback mechanism to handle broken links gracefully.

3. Potential for Silent Skipping of Unknown IDs

   • The getOwaspRisks function in owasp.ts silently skips unknown IDs. While this behavior is intentional, it could lead to missed risks if IDs are mistyped or missing.
   • Action: Log a warning or error when an unknown ID is encountered to aid debugging and ensure no risks are unintentionally omitted.

---

🟡 WARNING: Potential Breaking Changes

1. Removal of Numeric Mapping

   • The removal of numeric mapping between AT and ASI risks may break integrations or scripts that rely on the old identifiers.
   • Action: Clearly document this breaking change in the release notes and provide a migration guide for users to update their integrations.

2. Silent Skipping of Legacy AT Identifiers

   • The updated tests indicate that legacy AT identifiers are now silently skipped. This could lead to unexpected behavior for users who still rely on the old taxonomy.
   • Action: Consider logging a deprecation warning when legacy AT identifiers are encountered, to inform users of the change.

---

💡 Suggestions for Improvement

1. Enhanced Documentation

   • The updated README.md is comprehensive, but it would be helpful to include a section explaining the rationale for the migration to ASI 2026 and how it improves security and governance.

2. Backward Compatibility Layer

   • To ease the transition for users, consider implementing a backward compatibility layer that maps AT identifiers to their closest ASI equivalents. This mapping could be logged as a warning to encourage users to update their configurations.

3. Test Coverage

   • Ensure that the updated tests cover edge cases, such as:
     • Mixed usage of AT and ASI identifiers.
     • Invalid or unknown risk identifiers.
   • Add tests to verify that the getOwaspRisks function logs warnings for unknown IDs.

4. Dynamic URL Generation

   • Instead of hardcoding the OWASP URL base, consider generating URLs dynamically based on a configuration file or environment variable. This would make it easier to update URLs in the future.

5. TypeScript Enhancements

   • The OwaspRisk interface could benefit from stricter typing for the id field. For example, use a union type ("ASI01" | "ASI02" | ...) to ensure only valid ASI identifiers are used.

---

✅ Conclusion

This PR is a significant step forward in aligning the project with the OWASP ASI 2026 taxonomy, improving its relevance and accuracy in identifying agentic security risks. However, the issues flagged above, particularly the incomplete mapping of OWASP risks and the potential for silent failures, must be addressed before merging.

Priority Actions:

1. Map all rules to relevant ASI risks.
2. Implement logging for unknown or skipped risk identifiers.
3. Document the breaking changes and provide a migration guide.

Once these issues are resolved, the PR will be ready for approval.

[imran-siddique]

Closing in favor of #910 which implements the AT→ASI 2026 migration with these improvements:

• Backward-compatible LEGACY_AT_TO_ASI mapping so existing AT IDs still resolve (your version silently dropped them)
• All 14 reviewer rules migrated
• 46/46 tests pass with new backward-compat test coverage
• No unnecessary reformatting — only the changes that matter

Thank you for identifying this migration need — it directly informed the approach in #910.