feat: Rust SDK crate (agentmesh-rust) for native governance integration

[imran-siddique]

Summary

Implements the �gentmesh Rust SDK crate as proposed in #556 — Phase 1 (P0) and Phase 2 (P1).

Phase 1 — Core governance (P0)

Module	Description
\policy.rs\	YAML-based policy evaluation with 4-way decisions (allow/deny/requires-approval/rate-limit), wildcard action patterns, condition matching
\ rust.rs\	Trust scoring (0–1000, 5 tiers), configurable reward/penalty, threshold checks, optional JSON persistence
\�udit.rs\	SHA-256 hash-chain audit log with tamper detection, integrity verification, filtered queries
\ ypes.rs\	Shared types: \PolicyDecision, \TrustTier, \TrustScore, \AuditEntry, \GovernanceResult\

Phase 2 — Identity (P1)

Module	Description
\identity.rs\	Ed25519 agent identity via \�d25519-dalek, DID generation (\did:agentmesh:{id}), sign/verify, JSON serialization

Unified client

\AgentMeshClient\ combines all modules with \�xecute_with_governance()\ pipeline (policy → audit → trust update), matching the Go SDK's \ExecuteWithGovernance\ pattern.

Tests

31 tests passing (30 unit tests + 1 doc-test) covering:

• Policy evaluation (allowlist, denylist, approval, rate-limiting, scoped rules)
• Trust scoring (reward, penalty, caps, tiers, persistence, threshold)
• Audit logging (hash chain, tamper detection, filtering)
• Identity (key generation, sign/verify, JSON roundtrip)
• Client integration (governance pipeline, audit chain integrity)

Dependencies

Minimal, well-known crates: \serde, \serde_yaml, \serde_json, \sha2, \�d25519-dalek,
and, \ hiserror.

Location

\packages/agent-mesh/sdks/rust/agentmesh/\ — alongside existing Go and TypeScript SDKs.

Closes #556

[github-actions]

🤖 AI Agent: security-scanner — Security Review for `feat: Rust SDK crate (agentmesh-rust) for native governance integration`

Security Review for feat: Rust SDK crate (agentmesh-rust) for native governance integration

Summary

The pull request introduces a new Rust SDK (agentmesh-rust) for the AgentMesh governance framework, implementing core governance features (policy evaluation, trust scoring, audit logging, and identity management). This is a critical addition to the repository, as it directly impacts the security and integrity of the governance framework. Below is a detailed security review based on the provided diff and description.

---

Findings

1. Prompt Injection Defense Bypass

Rating: 🔴 CRITICAL

Issue:
The policy.rs module implements YAML-based policy evaluation. However, there is no evidence of input sanitization or validation for the policy_yaml field in ClientOptions. This could allow an attacker to craft malicious YAML input that bypasses policy guards or injects unintended behavior.

Attack Vector:
An attacker could craft a YAML policy file with malicious content, such as overly permissive rules or invalid configurations, to bypass security policies. For example:

policies:
  - name: allow-all
    type: capability
    allowed_actions: ["*"]

Recommendation:

• Implement strict validation of the policy_yaml input. Ensure that only valid and expected policy configurations are allowed.
• Use a schema validation library (e.g., serde_yaml with a predefined schema) to enforce constraints on the structure and content of the YAML file.
• Add tests to verify that invalid or malicious policy configurations are rejected.

---

2. Policy Engine Circumvention

Rating: 🟠 HIGH

Issue:
The execute_with_governance method in AgentMeshClient processes actions through the governance pipeline (policy → audit → trust update). However, there is no indication of safeguards against bypassing the policy engine, such as directly invoking actions without governance checks.

Attack Vector:
An attacker could potentially bypass the governance pipeline by directly invoking actions without passing through execute_with_governance. This would allow them to perform unauthorized actions.

Recommendation:

• Ensure that all action invocations are routed through the execute_with_governance method.
• Add runtime assertions or compile-time guarantees to enforce this routing.
• Consider using a macro or procedural attribute to wrap all action invocations with governance checks.

---

3. Trust Chain Weaknesses

Rating: 🟠 HIGH

Issue:
The identity.rs module uses ed25519-dalek for Ed25519-based agent identity and signing. While ed25519-dalek is a well-regarded library, there is no mention of certificate pinning, SPIFFE/SVID validation, or other mechanisms to ensure the integrity of the trust chain.

Attack Vector:
An attacker could impersonate a legitimate agent by exploiting weaknesses in the trust chain, such as a lack of certificate validation or improper key management.

Recommendation:

• Implement SPIFFE/SVID validation or similar mechanisms to ensure the authenticity of agent identities.
• Consider adding support for certificate pinning to prevent man-in-the-middle attacks.
• Ensure that private keys are securely stored and never logged or exposed.

---

4. Credential Exposure

Rating: 🔴 CRITICAL

Issue:
The README.md file includes an example that logs the result of execute_with_governance directly to the console:

println!("Decision: {:?}, Allowed: {}", result.decision, result.allowed);

This could inadvertently expose sensitive information, such as policy decisions or action details, in logs.

Attack Vector:
If the logs are accessible to unauthorized users, they could gain insights into the system's policy decisions and use this information to craft targeted attacks.

Recommendation:

• Avoid logging sensitive information, such as policy decisions or action details, in plaintext.
• Use a secure logging framework that supports redaction or masking of sensitive data.
• Add a warning in the documentation to caution developers against logging sensitive information.

---

5. Sandbox Escape

Rating: 🔵 LOW

Issue:
There is no indication of sandboxing or process isolation in the Rust SDK. While this may not be directly relevant to the SDK itself, it is worth noting for downstream users.

Attack Vector:
If the SDK is used in an environment where untrusted code is executed (e.g., user-provided scripts), an attacker could exploit the lack of sandboxing to escape and compromise the host system.

Recommendation:

• Document the need for sandboxing or process isolation when using the SDK in untrusted environments.
• Consider integrating with existing sandboxing solutions (e.g., wasmtime for WebAssembly-based isolation).

---

6. Deserialization Attacks

Rating: 🟠 HIGH

Issue:
The SDK uses serde_yaml and serde_json for deserialization. While these libraries are generally safe, improper deserialization of untrusted input can lead to deserialization attacks.

Attack Vector:
An attacker could craft malicious YAML or JSON input to exploit vulnerabilities in the deserialization process, potentially leading to remote code execution or denial of service.

Recommendation:

• Use strict schemas to validate YAML and JSON input before deserialization.
• Avoid deserializing untrusted input directly into complex data structures.
• Add tests to verify the SDK's behavior with malformed or malicious input.

---

7. Race Conditions

Rating: 🟡 MEDIUM

Issue:
The audit.rs module implements a hash-chain audit log. However, there is no mention of concurrency controls or mechanisms to prevent race conditions during log updates.

Attack Vector:
In a multi-threaded environment, concurrent updates to the audit log could result in inconsistent or corrupted hash chains, undermining the integrity of the audit trail.

Recommendation:

• Use synchronization primitives (e.g., Mutex, RwLock) to ensure thread-safe updates to the audit log.
• Add tests to simulate concurrent updates and verify the integrity of the hash chain.

---

8. Supply Chain Risks

Rating: 🟡 MEDIUM

Issue:
The Cargo.toml file includes dependencies on several third-party crates, including serde_yaml, serde_json, ed25519-dalek, and others. While these are well-known crates, there is always a risk of dependency confusion or typosquatting attacks.

Attack Vector:
An attacker could publish a malicious crate with a similar name to one of the dependencies, tricking developers into using the malicious crate instead.

Recommendation:

• Use a dependency auditing tool like cargo-audit to identify known vulnerabilities in dependencies.
• Pin dependencies to specific versions to prevent unintentional upgrades to compromised versions.
• Consider using a private registry or vendorizing critical dependencies to mitigate supply chain risks.

---

Summary of Findings

Finding	Rating	Recommendation Summary
Prompt injection defense bypass	🔴 CRITICAL	Validate policy_yaml input using a strict schema.
Policy engine circumvention	🟠 HIGH	Enforce governance pipeline routing for all actions.
Trust chain weaknesses	🟠 HIGH	Implement SPIFFE/SVID validation and certificate pinning.
Credential exposure	🔴 CRITICAL	Avoid logging sensitive information; update documentation with warnings.
Sandbox escape	🔵 LOW	Document sandboxing requirements for untrusted environments.
Deserialization attacks	🟠 HIGH	Validate YAML/JSON input against schemas before deserialization.
Race conditions	🟡 MEDIUM	Use synchronization primitives for thread-safe audit log updates.
Supply chain risks	🟡 MEDIUM	Use cargo-audit, pin dependencies, and consider vendorizing critical crates.

---

Final Recommendation

This pull request introduces critical functionality to the microsoft/agent-governance-toolkit repository, but it has several security concerns that need to be addressed before merging. The most critical issues are related to prompt injection defense and credential exposure, as they could lead to significant security vulnerabilities. Addressing these issues is essential to ensure the integrity and security of the AgentMesh governance framework.

[github-actions]

🤖 AI Agent: code-reviewer

Review of PR: feat: Rust SDK crate (agentmesh-rust) for native governance integration

---

🔴 CRITICAL: Security Issues

1. Policy Evaluation Logic (policy.rs):

   • Issue: The policy evaluation logic in policy.rs is not provided in the PR. Without reviewing the implementation, it is impossible to verify the correctness of the 4-way decision-making process (allow/deny/requires-approval/rate-limit). Any flaws in this logic could lead to security bypass.
   • Action: Provide the full implementation of the policy evaluation logic for review. Ensure that all edge cases are covered, including:
     • Proper handling of wildcard action patterns.
     • Correct evaluation of conditions.
     • Prevention of bypasses due to malformed or unexpected inputs.
     • Handling of conflicting rules (e.g., when multiple rules match an action).

2. Trust Scoring (trust.rs):

   • Issue: The trust scoring mechanism relies on configurable reward/penalty values and thresholds. If these values are not properly validated or if there are logic errors, it could lead to trust escalation or denial of service.
   • Action: Ensure that the trust scoring logic is robust and includes safeguards against:
     • Arbitrary manipulation of trust scores.
     • Overflow/underflow in score calculations.
     • Inconsistent trust tier assignments.

3. Audit Logging (audit.rs):

   • Issue: The tamper-evident audit log implementation is not provided in the PR. Without reviewing the hash-chain implementation, it is unclear if it is resistant to tampering or replay attacks.
   • Action: Provide the implementation of the audit log for review. Ensure:
     • Proper use of cryptographic primitives (e.g., SHA-256) for hash chaining.
     • Prevention of hash collisions.
     • Verification of the integrity of the entire chain, not just individual entries.

4. Agent Identity (identity.rs):

   • Issue: The identity.rs module uses the ed25519-dalek crate for cryptographic operations. While this is a well-regarded library, the implementation details (e.g., key generation, signing, and verification) are not provided in the PR.
   • Action: Provide the implementation of identity.rs for review. Verify:
     • Proper key generation and storage practices.
     • Secure handling of private keys (e.g., avoiding memory leaks, using zeroization).
     • Correct implementation of signing and verification processes.

5. Sandbox Escape Vectors:

   • Issue: The PR does not provide any information about sandboxing or isolation mechanisms for the Rust SDK. This is critical for preventing malicious agents from escaping their execution environment.
   • Action: Clarify the sandboxing strategy for the Rust SDK. If no sandboxing is implemented, this is a significant security risk that must be addressed.

---

🟡 WARNING: Potential Breaking Changes

1. GovernanceService in registration.proto:

   • Issue: The addition of the GovernanceService and its associated RPCs (EvaluatePolicy, RecordAudit, GetTrustScore) in registration.proto is a breaking change for any clients consuming this protocol. Existing clients will need to update their implementations to handle these new RPCs.
   • Action: Clearly document this breaking change in the release notes and communicate it to downstream consumers. Consider versioning the protocol to avoid breaking existing clients.

2. Unified Client (AgentMeshClient):

   • Issue: The AgentMeshClient introduces a new governance pipeline (execute_with_governance). If this replaces an existing method or changes its behavior, it could break existing integrations.
   • Action: Ensure backward compatibility by maintaining the old method (if applicable) or providing a clear migration guide for users.

---

💡 Suggestions for Improvement

1. Test Coverage:

   • While the PR mentions 31 tests, it is unclear if they cover all edge cases, especially for security-critical components like policy evaluation, trust scoring, and audit logging.
   • Action: Provide a detailed breakdown of test cases and their coverage. Include tests for:
     • Invalid or malformed inputs.
     • Edge cases in policy evaluation (e.g., overlapping rules, conflicting conditions).
     • Tampering attempts on the audit log.
     • Replay attacks on the identity module.

2. Concurrency and Thread Safety:

   • Issue: The PR does not mention whether the Rust SDK is thread-safe. This is critical for concurrent agent execution.
   • Action: Ensure that all shared state (e.g., trust scores, audit logs) is properly synchronized. Use thread-safe data structures like Arc<Mutex<T>> or RwLock where necessary. Add tests for concurrent execution scenarios.

3. Error Handling:

   • Issue: The PR mentions the use of the thiserror crate for error handling but does not provide details on how errors are propagated or logged.
   • Action: Ensure that all errors are properly handled and logged. Avoid leaking sensitive information in error messages.

4. Documentation:

   • Issue: The PR lacks detailed documentation for the Rust SDK, especially for the AgentMeshClient and its governance pipeline.
   • Action: Add comprehensive documentation, including:
     • Examples of how to use the SDK.
     • Detailed explanations of the governance pipeline and its components.
     • Guidelines for configuring policies, trust scoring, and audit logging.

5. Dependency Audit:

   • Issue: The serde_yaml crate is marked as deprecated in the Cargo.lock file.
   • Action: Replace serde_yaml with a maintained alternative or verify that the deprecation does not pose a security risk.

6. Performance Considerations:

   • Issue: The PR does not mention any performance benchmarks for the Rust SDK, especially for critical operations like policy evaluation and audit logging.
   • Action: Conduct performance testing and provide benchmarks. Optimize any identified bottlenecks.

7. Cross-Language Consistency:

   • Issue: The Rust SDK is designed to match the Go SDK's ExecuteWithGovernance pattern. However, there is no mention of how consistency between the SDKs is ensured.
   • Action: Add tests or documentation to verify that the Rust SDK behaves identically to the Go SDK for the same inputs.

---

Summary of Actionable Feedback

🔴 CRITICAL

1. Provide the full implementation of policy.rs for review to ensure correctness and prevent security bypass.
2. Ensure the trust scoring mechanism in trust.rs is robust and resistant to manipulation.
3. Provide the implementation of audit.rs for review to verify the integrity of the tamper-evident audit log.
4. Provide the implementation of identity.rs for review to ensure secure cryptographic operations.
5. Clarify and implement sandboxing or isolation mechanisms to prevent sandbox escape.

🟡 WARNING

1. Document the breaking changes introduced by the new GovernanceService in registration.proto.
2. Ensure backward compatibility for the AgentMeshClient and provide a migration guide if necessary.

💡 SUGGESTION

1. Provide a detailed breakdown of test coverage and add tests for edge cases and security scenarios.
2. Ensure thread safety for concurrent agent execution.
3. Improve error handling and logging to avoid leaking sensitive information.
4. Replace the deprecated serde_yaml crate or verify its security implications.
5. Conduct performance testing and provide benchmarks for critical operations.
6. Ensure cross-language consistency between the Rust SDK and the Go SDK.

---

Please address the critical issues and warnings before merging this PR. Let me know if you need further clarification or assistance!

[github-actions]

🤖 AI Agent: code-reviewer

Pull Request Review: Rust SDK Crate for AgentMesh Governance Framework

---

🔴 CRITICAL: Security Issues

1. Policy Engine Correctness (False Negatives):

   • The policy engine in policy.rs supports YAML-based configurations with wildcard action patterns and condition matching. However, there is no mention of how invalid or malformed YAML configurations are handled. If the YAML parser fails silently or defaults to permissive behavior, it could lead to false negatives, allowing unauthorized actions.
     • Action: Add strict validation for YAML configurations and ensure that invalid configurations result in a hard failure with clear error messages.

2. Trust Scoring Logic:

   • The trust scoring mechanism in trust.rs is critical for enforcing governance. However, there is no mention of safeguards against integer overflow when calculating trust scores (e.g., adding rewards or penalties). This could lead to incorrect trust evaluations.
     • Action: Use Rust's checked_add, checked_sub, or similar methods to prevent overflow in trust score calculations.

3. Audit Log Integrity:

   • The audit log uses a SHA-256 hash chain for tamper detection. However, there is no mention of how the initial hash (genesis hash) is securely established or how the chain is protected against rollback attacks.
     • Action: Document and implement a mechanism to securely establish and verify the genesis hash. Consider using a trusted timestamping service or cryptographic signatures to prevent rollback attacks.

4. Ed25519 Key Management:

   • The identity.rs module uses ed25519-dalek for key generation and signing. However, there is no mention of how private keys are securely stored or managed. If private keys are exposed, the entire identity system is compromised.
     • Action: Implement secure key storage mechanisms (e.g., hardware security modules, encrypted files) and document best practices for key management.

5. Sandbox Escape Vectors:

   • The execute_with_governance method in AgentMeshClient processes actions, including potentially dangerous ones like shell:*. There is no mention of how these actions are executed or whether they are sandboxed. If shell commands are executed directly, this could lead to sandbox escapes or remote code execution.
     • Action: Ensure that all actions, especially shell commands, are executed in a secure sandboxed environment. Validate and sanitize all inputs to prevent command injection.

---

🟡 WARNING: Potential Breaking Changes

1. Public API Stability:

   • The README.md mentions that the SDK is in "Public Preview" and that APIs may change before version 1.0. This could lead to breaking changes for early adopters.
     • Action: Clearly document any planned breaking changes in the release notes and provide migration guides for users.

2. Dependency on Deprecated Crates:

   • The serde_yaml crate is marked as 0.9.34+deprecated. Using deprecated crates could lead to compatibility issues in the future.
     • Action: Replace serde_yaml with a maintained alternative or confirm that the deprecation does not impact the SDK's functionality.

---

💡 Suggestions for Improvement

1. Thread Safety:

   • The SDK does not explicitly mention whether AgentMeshClient or its components are thread-safe. Since concurrent agent execution is a focus area, this should be clarified.
     • Action: Use Rust's Send and Sync traits to enforce thread safety where applicable. Add tests to verify thread-safe behavior under concurrent usage.

2. Type Safety and Validation:

   • The shared types in types.rs (e.g., PolicyDecision, TrustScore) should enforce stricter validation. For example, TrustScore should ensure that values are within the valid range (0–1000).
     • Action: Use Rust's newtype pattern or custom constructors to enforce invariants at compile time.

3. Backward Compatibility Tests:

   • There is no mention of tests to ensure backward compatibility with existing Go and TypeScript SDKs.
     • Action: Add integration tests to verify that the Rust SDK produces the same results as the Go and TypeScript SDKs for identical inputs.

4. Documentation Improvements:

   • The README.md provides a good overview, but it lacks detailed examples for advanced use cases (e.g., rate-limiting policies, multi-agent scenarios).
     • Action: Expand the documentation with more examples and edge cases to help users understand the full capabilities of the SDK.

5. Minimal Dependencies:

   • While the SDK uses well-known crates, some dependencies (e.g., rand, serde_yaml) could be replaced with lighter alternatives to reduce the attack surface and improve performance.
     • Action: Audit dependencies and replace heavy or unnecessary ones with lighter alternatives.

---

General Observations

• The implementation appears to follow Rust best practices, such as using thiserror for error handling and serde for serialization.
• The use of ed25519-dalek is appropriate for cryptographic operations, but care must be taken to ensure secure key management.
• The inclusion of 31 tests is a good start, but additional tests for edge cases, thread safety, and backward compatibility are recommended.

---

Summary of Actions

1. Critical Security Fixes:

   • Validate YAML configurations to prevent false negatives.
   • Prevent integer overflow in trust scoring.
   • Secure the audit log's genesis hash and prevent rollback attacks.
   • Implement secure key storage for Ed25519 private keys.
   • Ensure sandboxing and input validation for action execution.

2. Warnings:

   • Document potential breaking changes and provide migration guides.
   • Replace deprecated dependencies like serde_yaml.

3. Suggestions:

   • Ensure thread safety with Send and Sync traits.
   • Enforce stricter type safety with newtype patterns.
   • Add backward compatibility tests with Go and TypeScript SDKs.
   • Expand documentation with advanced examples.
   • Audit and optimize dependencies.

By addressing these issues, the Rust SDK can become a robust and secure addition to the AgentMesh governance framework.