feat(mcp-proxy): add OWASP mitigates field to policy rules and audit

[jackbatzner]

Description

Adds OWASP risk traceability to MCP proxy policy decisions. Each policy rule can now declare which OWASP ASI risks it mitigates, and that information flows through policy evaluation into CloudEvents audit logs.

Changes

• policy.ts: Added mitigates?: string[] to PolicyRule interface and mitigatedRisks?: string[] to PolicyDecision
• proxy.ts: Threads mitigatedRisks from matched policy rules into audit calls
• audit.ts: Added mitigates to AuditEvent interface and CloudEvent data payload
• standard.yaml / strict.yaml / enterprise.yaml: Annotated rules with mitigates: [ASI01] etc. referencing the 2026 OWASP Agentic Top 10
• tests: Added policy evaluation tests for mitigates propagation

Why

Discussion #814 identifies "contribute back implementation patterns as reference architectures" for OWASP. This makes AGT's MCP proxy one of the first implementations to carry explicit OWASP risk mapping in policy enforcement and audit trails.

Type of Change

• New feature (non-breaking change that adds functionality)

Package(s) Affected

• agent-mesh

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 - MCP governance depth)

[github-actions]

🤖 AI Agent: security-scanner — Security Review: Pull Request Analysis

Security Review: Pull Request Analysis

This pull request introduces a new feature to the mcp-proxy component of the agent-mesh package, adding OWASP risk traceability to policy rules and audit logs. While this is a valuable addition for improving transparency and aligning with OWASP standards, the changes must be carefully reviewed for potential security vulnerabilities.

---

Findings

1. Prompt Injection Defense Bypass

• Risk: No direct evidence of prompt injection vulnerabilities was found in the changes. However, the inclusion of user-provided data in audit logs (mitigates field) could potentially expose the system to injection attacks if the data is not properly sanitized.
• Rating: 🟡 MEDIUM
• Attack Vector: If an attacker can manipulate the mitigates field in policy rules (e.g., through a misconfigured or compromised policy file), they could inject malicious content into audit logs. This could lead to log poisoning or other downstream issues.
• Recommendation: Ensure that all user-provided data (e.g., mitigates field) is sanitized before being logged or processed. Use a library or utility to escape special characters in log entries.

---

2. Policy Engine Circumvention

• Risk: The changes to the evaluatePolicy function appear to correctly propagate the mitigates field from policy rules to decisions. However, there is no validation to ensure that the mitigates field contains valid OWASP ASI identifiers.
• Rating: 🟠 HIGH
• Attack Vector: An attacker with access to modify policy files could inject arbitrary or invalid mitigates values, potentially misleading audit logs or causing incorrect assumptions about risk coverage.
• Recommendation: Implement validation for the mitigates field to ensure it only contains valid OWASP ASI identifiers. This could be done by maintaining a whitelist of valid identifiers and verifying the field against it during policy loading.

---

3. Trust Chain Weaknesses

• Risk: No changes in this PR directly affect SPIFFE/SVID validation or certificate pinning mechanisms.
• Rating: 🔵 LOW
• Recommendation: No action required for this PR. However, ensure that any future changes to the trust chain are thoroughly reviewed.

---

4. Credential Exposure

• Risk: The audit logging functionality now includes the mitigates field in CloudEvents data. While this field does not appear to contain sensitive information, there is a risk of inadvertently logging sensitive data if the field is misused.
• Rating: 🟡 MEDIUM
• Attack Vector: If sensitive information is mistakenly added to the mitigates field in policy rules, it could be logged and exposed in audit logs.
• Recommendation: Add a safeguard to prevent sensitive data from being included in the mitigates field. For example, enforce strict validation and logging policies to ensure sensitive information is not logged.

---

5. Sandbox Escape

• Risk: No evidence of sandbox escape vulnerabilities was found in the changes.
• Rating: 🔵 LOW
• Recommendation: No action required for this PR.

---

6. Deserialization Attacks

• Risk: No evidence of unsafe deserialization was found in the changes.
• Rating: 🔵 LOW
• Recommendation: No action required for this PR.

---

7. Race Conditions

• Risk: The evaluatePolicy function appears to be thread-safe, and there are no indications of race conditions in the changes.
• Rating: 🔵 LOW
• Recommendation: No action required for this PR.

---

8. Supply Chain

• Risk: No new dependencies were introduced in this PR. Existing dependencies should be regularly audited for vulnerabilities.
• Rating: 🔵 LOW
• Recommendation: Continue to monitor and update dependencies to mitigate supply chain risks.

---

Summary of Findings

Category	Rating	Details
Prompt Injection Defense Bypass	🟡 MEDIUM	Potential log poisoning if mitigates field is not sanitized.
Policy Engine Circumvention	🟠 HIGH	Lack of validation for mitigates field could lead to misleading or incorrect audit logs.
Trust Chain Weaknesses	🔵 LOW	No changes affecting trust chain mechanisms.
Credential Exposure	🟡 MEDIUM	Risk of sensitive data being logged if mitigates field is misused.
Sandbox Escape	🔵 LOW	No evidence of sandbox escape vulnerabilities.
Deserialization Attacks	🔵 LOW	No evidence of unsafe deserialization.
Race Conditions	🔵 LOW	No evidence of race conditions.
Supply Chain	🔵 LOW	No new dependencies; existing dependencies should be monitored.

---

Recommendations

1. Sanitize User-Provided Data: Ensure that the mitigates field is sanitized before being logged or processed to prevent potential log poisoning or injection attacks.
2. Validate mitigates Field: Implement validation to ensure that the mitigates field only contains valid OWASP ASI identifiers. This could be done by maintaining a whitelist of valid identifiers.
3. Audit Logging Policy: Review and enforce a strict policy to prevent sensitive data from being included in audit logs.
4. Regular Dependency Audits: Continue to monitor and update dependencies to address any potential supply chain vulnerabilities.

---

Final Assessment

The changes in this PR introduce a valuable feature for OWASP risk traceability but also introduce potential risks related to data validation and logging. Addressing the identified issues will ensure the robustness and security of the MCP proxy's policy engine and audit logging functionality.

[github-actions]

🤖 AI Agent: code-reviewer

Review of Pull Request: feat(mcp-proxy): add OWASP mitigates field to policy rules and audit

Summary

This pull request introduces a new feature that allows policy rules in the MCP proxy to declare which OWASP ASI risks they mitigate. This information is propagated through policy evaluations and included in CloudEvents audit logs. The changes are well-structured, and tests have been added to ensure functionality.

Feedback

🔴 CRITICAL Issues

1. Policy Rule Validation: Ensure that the mitigates field is validated against a predefined set of OWASP ASI risks. If an invalid risk is provided, it could lead to incorrect policy enforcement. Consider implementing a validation mechanism to check that all entries in the mitigates array are valid OWASP ASI identifiers.

🟡 WARNING Issues

1. Backward Compatibility: The addition of the mitigates field to the PolicyRule and PolicyDecision interfaces introduces a change in the public API. While this is a non-breaking change in terms of functionality, existing consumers of the API that do not expect this field may not handle it correctly. Ensure that this change is documented and consider versioning the API if necessary.

2. Potential for Misconfiguration: The introduction of the mitigates field could lead to misconfigurations if users mistakenly annotate rules with incorrect or irrelevant OWASP ASI identifiers. Provide clear documentation and examples to guide users on how to use this feature correctly.

💡 SUGGESTION Improvements

1. Documentation: Update the documentation to include details about the new mitigates field, including its purpose, how to use it, and examples of valid OWASP ASI identifiers. This will help users understand the feature and its implications better.

2. Type Safety: Consider using a more structured approach for the mitigates field, such as defining a TypeScript enum for OWASP ASI identifiers. This would enhance type safety and reduce the risk of invalid entries.

3. Testing: While tests have been added for the new feature, consider adding edge cases, such as:

   • What happens if an empty array is provided for mitigates?
   • How does the system behave if a policy rule has multiple mitigates, including duplicates?
   • Test for invalid OWASP ASI identifiers to ensure they are handled gracefully.

4. Audit Log Clarity: In the audit logs, consider including more context around the mitigates field, such as a description of each risk being mitigated. This could enhance the clarity of the logs and make it easier for users to understand the implications of policy decisions.

5. Performance Considerations: If the mitigates field is expected to grow in complexity or size, consider evaluating the performance impact on policy evaluation and audit logging. Ensure that the added complexity does not introduce significant overhead.

Conclusion

Overall, this pull request is a valuable enhancement to the MCP proxy's policy enforcement capabilities, aligning with OWASP standards. Addressing the critical issue regarding validation and considering the warnings and suggestions will help ensure the robustness and usability of the new feature.

[imran-siddique]

Thanks @jackbatzner — the MCP governance initiative across all SDKs is a significant contribution. We've merged #774, #837, #840, #841, #842, #796 so far. For the remaining PRs (#839, #843, #844), just fix the CI issues noted in reviews and they're ready. For the stacked feature PRs (#775, #791, #832 + standalone packages), please rebase on latest main to resolve conflicts.