feat: add AgentMesh component container images and GHCR publishing

[imran-siddique]

Summary

Add FastAPI server entrypoints, Dockerfiles, and GHCR publishing workflow for all four AgentMesh components that were referenced in the Helm chart but never had actual container images.

Components

Component	Port	Description
trust-engine	8443	Agent identity verification, IATP handshakes
policy-server	8444	Governance policy evaluation from YAML/JSON
audit-collector	8445	Merkle-chained audit logging with FileAuditSink persistence
api-gateway	8446	Reverse proxy with per-agent rate limiting

What's Included

• 6 new Python modules in \packages/agent-mesh/src/agentmesh/server/\
• Single Dockerfile with \COMPONENT\ build arg (non-root user, tini, health checks)
• GitHub Actions workflow (.github/workflows/publish-containers.yml) for GHCR publishing with multi-arch (amd64/arm64), provenance attestation
• Helm chart updated — image repos now point to \ghcr.io/microsoft/agentmesh/*\
• 28 integration tests covering all server endpoints

Motivation

These images were referenced in the Helm chart (\�alues.yaml) but had no Dockerfiles, no published images, and no server entrypoints. Users trying to deploy the full AgentMesh cluster (not just sidecar mode) couldn't proceed. This unblocks full cluster deployment.

[github-actions]

🤖 AI Agent: docs-sync-checker — Issues Found

📝 Documentation Sync Report

Issues Found

1. ❌ New public APIs without docstrings:

   • packages/agent-mesh/src/agentmesh/server/ — The 6 new Python modules added in this PR do not appear to have any docstrings for their public functions, classes, or methods. These should include explanations of purpose, parameters, return values, and exceptions.

2. ⚠️ README sections out of date:

   • packages/agent-mesh/README.md — The README does not mention the new container images, FastAPI server entrypoints, or the updated Helm chart configuration. These updates should be documented to reflect the new functionality.

3. ⚠️ CHANGELOG missing entries:

   • CHANGELOG.md — There is no entry for the addition of the AgentMesh container images, FastAPI server entrypoints, or the GitHub Actions workflow for GHCR publishing. These are significant changes and should be documented in the changelog.

4. ⚠️ Example code outdated:

   • The example code in packages/agent-governance-dotnet/src/AgentGovernance/ has been updated to use the new did:agentmesh:* format for decentralized identifiers (DIDs). However, there is no indication that corresponding updates have been made to example code in other SDKs or in the examples/ directory. This should be verified and updated for consistency.

5. ⚠️ Type hints:

   • The new Python modules in packages/agent-mesh/src/agentmesh/server/ do not appear to have complete type annotations for their public APIs. Type hints should be added to ensure clarity and maintainability.

Suggestions

• 💡 Add docstrings for all public functions, classes, and methods in the new Python modules under packages/agent-mesh/src/agentmesh/server/.
• 💡 Update packages/agent-mesh/README.md to include:
  • Details about the new container images and their purposes.
  • Instructions for using the FastAPI server entrypoints.
  • Information on the updated Helm chart configuration.
• 💡 Add an entry to CHANGELOG.md summarizing:
  • The addition of AgentMesh container images.
  • The new FastAPI server entrypoints.
  • The GitHub Actions workflow for GHCR publishing.
• 💡 Verify and update example code in the examples/ directory and other SDKs to reflect the new did:agentmesh:* format for DIDs.
• 💡 Add type hints to all public APIs in the new Python modules.

Additional Notes

• The updates to the docs/FAQ.md, docs/LIMITATIONS.md, and docs/THREAT_MODEL.md files are thorough and align with the changes introduced in this PR.
• The version bump in AgentGovernance.csproj from 3.1.0 to 3.2.0 is appropriate given the changes to the .NET SDK.

Conclusion

The PR introduces significant new functionality and updates to the repository. However, there are several documentation and type hinting issues that need to be addressed before the documentation can be considered fully in sync.

Please address the issues and suggestions listed above to ensure the repository remains well-documented and maintainable.

[github-actions]

🤖 AI Agent: breaking-change-detector — Summary

🔍 API Compatibility Report

Summary

This pull request primarily introduces new components, container images, and publishing workflows for the AgentMesh system. While the changes are extensive, they do not appear to introduce breaking changes to the existing Python APIs. The modifications to the .NET SDK involve updates to the DID format (did:mesh:* → did:agentmesh:*), which may impact downstream users relying on the old format. However, this change is not directly related to the Python packages published to PyPI.

Findings

Severity	Package	Change	Impact
🔵	agent-mesh	Addition of FastAPI server entrypoints	New functionality, no breaking changes
🔵	agent-mesh	Addition of Dockerfiles and GHCR publishing workflow	Infrastructure addition, no API impact
🔵	agent-compliance	Minor formatting fixes (e.g., newline removal)	No functional impact
🔵	agent-governance-dotnet	DID format changed from did:mesh:* to did:agentmesh:*	Potential impact on .NET SDK users, unrelated to Python APIs

Migration Guide

For .NET SDK Users:

• Update any code or configurations that rely on the old DID format (did:mesh:*) to use the new format (did:agentmesh:*).
• Ensure any cross-SDK integrations account for the DID format change.

Conclusion

✅ No breaking changes detected for Python packages published to PyPI.

[github-actions]

🤖 AI Agent: test-generator — `packages/agent-compliance/src/agent_compliance/cli/agt.py`

🧪 Test Coverage Analysis

packages/agent-compliance/src/agent_compliance/cli/agt.py

• ✅ Existing coverage: Basic CLI functionality and argument parsing are likely covered by existing tests in tests/agent_compliance/cli/test_agt.py.
• ❌ Missing coverage: No specific changes were made to this file in the diff, but the lack of a newline at the end of the file suggests no functional changes. However, if there are any untested CLI commands or edge cases, they may remain uncovered.
• 💡 Suggested test cases:
  1. test_main_no_arguments — Ensure the CLI handles cases where no arguments are provided gracefully.
  2. test_main_invalid_arguments — Test the behavior when invalid or unexpected arguments are passed to the CLI.

---

packages/agent-compliance/src/agent_compliance/verify.py

• ✅ Existing coverage: Core verification logic and _check_control method are likely covered by tests in tests/agent_compliance/test_verify.py.
• ❌ Missing coverage: No functional changes were made to this file in the diff, but edge cases for _check_control may not be fully tested.
• 💡 Suggested test cases:
  1. test_check_control_missing_module — Simulate a missing module scenario and verify the error handling logic.
  2. test_check_control_invalid_spec — Test _check_control with malformed or incomplete spec dictionaries.

---

packages/agent-mesh/src/agentmesh/server/__init__.py

• ✅ Existing coverage: This file likely serves as a package initializer and may not contain significant logic to test.
• ❌ Missing coverage: No functional changes were made, so no new coverage gaps are introduced.
• 💡 Suggested test cases: None specific to this file.

---

packages/agent-mesh/src/agentmesh/server/__main__.py

• ✅ Existing coverage: Entry point logic for starting the server may be covered by integration tests.
• ❌ Missing coverage: Edge cases for server startup (e.g., invalid configurations, missing environment variables) may not be fully tested.
• 💡 Suggested test cases:
  1. test_main_invalid_config — Simulate invalid configuration scenarios and verify error handling.
  2. test_main_missing_env_vars — Test behavior when required environment variables are not set.

---

packages/agent-mesh/src/agentmesh/server/api_gateway.py

• ✅ Existing coverage: Core API gateway functionality, such as reverse proxying and rate limiting, is likely covered by tests in tests/agentmesh/server/test_api_gateway.py.
• ❌ Missing coverage: Edge cases for rate limiting and malformed requests may not be fully tested.
• 💡 Suggested test cases:
  1. test_rate_limit_exceeded — Verify behavior when an agent exceeds its rate limit.
  2. test_malformed_request — Test handling of malformed HTTP requests or payloads.

---

packages/agent-mesh/src/agentmesh/server/audit_collector.py

• ✅ Existing coverage: Core audit logging functionality is likely covered by tests in tests/agentmesh/server/test_audit_collector.py.
• ❌ Missing coverage: Edge cases for Merkle chain integrity and file persistence errors may not be fully tested.
• 💡 Suggested test cases:
  1. test_merkle_chain_integrity — Verify that the Merkle chain remains consistent after multiple log entries.
  2. test_file_persistence_error — Simulate file write errors and verify error handling.

---

packages/agent-mesh/src/agentmesh/server/policy_server.py

• ✅ Existing coverage: Core policy evaluation logic is likely covered by tests in tests/agentmesh/server/test_policy_server.py.
• ❌ Missing coverage: Boundary conditions, conflicting policies, and policy bypass attempts may not be fully tested.
• 💡 Suggested test cases:
  1. test_conflicting_policies — Test behavior when two policies conflict (e.g., one allows and one denies the same action).
  2. test_policy_bypass_attempt — Simulate an attempt to bypass a policy using unexpected input formats or edge cases.

---

packages/agent-mesh/src/agentmesh/server/trust_engine.py

• ✅ Existing coverage: Trust scoring logic and identity verification are likely covered by tests in tests/agentmesh/server/test_trust_engine.py.
• ❌ Missing coverage: Edge cases for trust scores (e.g., 0.0, 1.0), expired certificates, and revoked trust may not be fully tested.
• 💡 Suggested test cases:
  1. test_trust_score_zero — Verify behavior when an agent's trust score is 0.0.
  2. test_expired_certificate — Test behavior when an agent presents an expired certificate.
  3. test_revoked_trust — Simulate a scenario where an agent's trust is revoked and verify that actions are blocked.

---

General Recommendations

• Ensure that all new functionality introduced in the agent-mesh components (e.g., FastAPI server entry points) is covered by integration tests.
• Focus on domain-specific edge cases, such as policy conflicts, trust score boundaries, and error handling in distributed systems.
• Add chaos experiments to test timeout handling, partial failures, and cascading failures in the api_gateway, audit_collector, and policy_server components.
• Verify concurrency safety in shared state management, particularly in trust_engine and policy_server.

Let me know if you need further details or assistance!

[github-actions]

🤖 AI Agent: code-reviewer

Review Summary

This pull request introduces containerized FastAPI server entrypoints for the AgentMesh components, along with a GitHub Actions workflow for publishing these containers to GHCR. It also includes updates to the Helm chart, documentation, and minor code changes across multiple packages. While the changes are generally well-structured and address a critical gap in the project, there are several areas that require attention to ensure security, correctness, and backward compatibility.

---

🔴 CRITICAL: Security Issues

1. Insufficient Validation of User Input in FastAPI Endpoints

   • Issue: The PR does not include the implementation of the FastAPI server entrypoints, but it mentions that they are added. If these endpoints do not validate user input properly, it could lead to injection attacks, including SQL injection, command injection, or other vulnerabilities.
   • Action: Ensure that all input to the FastAPI endpoints is validated using Pydantic models with strict type definitions. Additionally, sanitize inputs to prevent injection attacks.

2. Lack of Explicit Non-Root User Enforcement in Dockerfile

   • Issue: While the PR mentions the use of a non-root user in the Dockerfile, the actual Dockerfile is not included in the diff. Running containers as root is a critical security risk.
   • Action: Verify that the Dockerfile explicitly switches to a non-root user using the USER directive. Ensure that the non-root user has the minimum required permissions.

3. Potential for Credential Leakage in GitHub Actions Workflow

   • Issue: The GitHub Actions workflow uses ${{ secrets.GITHUB_TOKEN }} for authentication with GHCR. If this token is not scoped correctly, it could lead to unauthorized access or credential leakage.
   • Action: Ensure that the GitHub token is scoped to the minimum permissions required for the workflow. Additionally, consider using OpenID Connect (OIDC) for authentication with GHCR to avoid long-lived tokens.

4. Provenance Attestation Failure Handling

   • Issue: The attest-build-provenance step in the GitHub Actions workflow uses continue-on-error: true. This could allow builds with failed provenance attestation to be published, which is a security risk.
   • Action: Remove continue-on-error: true and ensure that the workflow fails if provenance attestation does not succeed.

5. DID Method Inconsistency

   • Issue: The inconsistency between did:mesh:* and did:agentmesh:* across SDKs could lead to policy mismatches and security gaps.
   • Action: Expedite the standardization of the DID method to did:agentmesh:* across all SDKs. Until then, provide clear documentation and tooling to handle normalization.

---

🟡 WARNING: Potential Breaking Changes

1. DID Format Change in .NET SDK

   • Issue: The change from did:mesh:* to did:agentmesh:* in the .NET SDK is a breaking change for users who rely on the old format.
   • Action: Provide a migration guide and consider supporting both formats temporarily to ensure backward compatibility.

2. Helm Chart Updates

   • Issue: The Helm chart now points to new GHCR-hosted images. This change will break deployments for users relying on the old image locations.
   • Action: Clearly document this change in the release notes and provide a migration path for users to update their Helm chart configurations.

---

💡 Suggestions for Improvement

1. Add Unit Tests for FastAPI Endpoints

   • Rationale: While the PR includes 28 integration tests, unit tests for individual FastAPI endpoints are not mentioned. These tests are crucial for ensuring endpoint correctness and input validation.
   • Action: Add unit tests for all FastAPI endpoints, focusing on edge cases and invalid inputs.

2. Improve Documentation for New Components

   • Rationale: The PR adds significant functionality but does not include detailed documentation for the new FastAPI server entrypoints or the Dockerfiles.
   • Action: Update the documentation to include:
     • API specifications for each FastAPI endpoint.
     • Instructions for building and running the Docker containers locally.
     • Details on the health checks implemented in the Dockerfiles.

3. Enhance Logging and Monitoring

   • Rationale: The PR does not mention logging or monitoring for the new components. These are critical for debugging and security auditing.
   • Action: Ensure that the FastAPI server entrypoints include structured logging and integrate with OpenTelemetry for distributed tracing.

4. Concurrency and Thread Safety

   • Rationale: The PR does not address thread safety or concurrency concerns for the new FastAPI server components.
   • Action: Review the implementation of the FastAPI server entrypoints to ensure they are thread-safe, especially if they handle shared resources or state.

5. Sandboxing for Agent Execution

   • Rationale: The PR does not mention any sandboxing mechanisms for the new components. This could lead to potential sandbox escape vulnerabilities.
   • Action: Consider using container-level sandboxing (e.g., seccomp, AppArmor) and application-level sandboxing to isolate agent execution.

6. Backward Compatibility Testing

   • Rationale: The PR introduces changes to the .NET SDK and Helm chart that could break existing deployments.
   • Action: Add backward compatibility tests to ensure that existing users are not affected by these changes.

---

Final Assessment

• Security: 🔴 Critical issues identified, particularly around input validation, Dockerfile configuration, and GitHub Actions workflow.
• Backward Compatibility: 🟡 Breaking changes in the .NET SDK and Helm chart require mitigation.
• Code Quality: 💡 Suggestions provided for improving test coverage, documentation, and thread safety.

Action Items

1. Address the critical security issues, especially input validation and Dockerfile configuration.
2. Provide a migration guide for the DID format change and Helm chart updates.
3. Add unit tests for FastAPI endpoints and backward compatibility tests.
4. Enhance documentation and logging for the new components.
5. Review thread safety and sandboxing mechanisms for the new server components.

Please address these issues and resubmit the PR for further review.

[github-actions]

🤖 AI Agent: security-scanner — Security Review of Pull Request: feat: add AgentMesh component container images and GHCR publishing

Security Review of Pull Request: feat: add AgentMesh component container images and GHCR publishing

---

Findings

---

1. Prompt Injection Defense Bypass

Rating: 🔴 CRITICAL
Issue:
The FastAPI server entrypoints for the AgentMesh components (trust-engine, policy-server, audit-collector, api-gateway) do not appear to include explicit defenses against prompt injection attacks. These components are critical for governance, and any bypass here could allow malicious agents to circumvent policies or inject unauthorized commands.

Attack Vector:
An attacker could craft malicious input that exploits weaknesses in input validation or sanitization, potentially bypassing governance rules enforced by the policy-server or injecting unauthorized commands into the trust-engine.

Recommendation:

• Implement strict input validation and sanitization for all endpoints in the FastAPI server.
• Add a dedicated PromptInjectionDetector middleware to inspect incoming requests for known prompt injection patterns.
• Include unit tests to validate the effectiveness of the prompt injection defenses.

---

2. Policy Engine Circumvention

Rating: 🔴 CRITICAL
Issue:
The policy evaluation logic in the PolicyEngine class does not appear to include safeguards against policy circumvention via malformed or incomplete requests. Additionally, the DID format inconsistency (did:mesh:* vs. did:agentmesh:*) could lead to policy mismatches, allowing unauthorized actions to bypass governance.

Attack Vector:
An attacker could exploit the DID inconsistency to craft requests that bypass policy checks, especially in cross-SDK environments where policies rely on matching specific DID prefixes.

Recommendation:

• Standardize the DID format across all SDKs to did:agentmesh:*.
• Implement strict validation of DIDs in the PolicyEngine to ensure that malformed or inconsistent DIDs are rejected.
• Add tests to verify that policies are enforced correctly across all SDKs and DID formats.

---

3. Trust Chain Weaknesses

Rating: 🟠 HIGH
Issue:
The trust-engine component is responsible for agent identity verification and IATP handshakes. However, there is no mention of SPIFFE/SVID validation or certificate pinning in the FastAPI server entrypoints or Dockerfiles.

Attack Vector:
An attacker could exploit weak or missing trust chain validation to impersonate an agent or inject malicious certificates, compromising the entire governance layer.

Recommendation:

• Implement SPIFFE/SVID validation in the trust-engine to ensure that all agent identities are verified against a trusted certificate authority.
• Add certificate pinning to prevent man-in-the-middle attacks.
• Include integration tests to validate trust chain integrity.

---

4. Credential Exposure

Rating: 🟠 HIGH
Issue:
The GitHub Actions workflow (publish-containers.yml) uses the GITHUB_TOKEN secret for authentication but does not explicitly restrict its scope. Additionally, the workflow logs sensitive information such as image tags and metadata, which could inadvertently expose credentials or internal details.

Attack Vector:
An attacker with access to the CI/CD logs could extract sensitive information, such as image tags or metadata, to craft targeted attacks against the container registry or the published images.

Recommendation:

• Restrict the scope of the GITHUB_TOKEN to only the permissions required for publishing containers.
• Mask sensitive information in the workflow logs using echo ::add-mask:: for any potentially sensitive variables.
• Rotate the GITHUB_TOKEN regularly and monitor its usage for anomalies.

---

5. Sandbox Escape

Rating: 🔴 CRITICAL
Issue:
The Dockerfiles for the AgentMesh components do not include explicit measures to prevent sandbox escapes, such as seccomp profiles, AppArmor, or SELinux policies.

Attack Vector:
An attacker could exploit vulnerabilities in the container runtime or the application code to escape the container and gain access to the host system.

Recommendation:

• Add seccomp profiles, AppArmor, or SELinux policies to the Dockerfiles to restrict container capabilities.
• Run containers with the --security-opt=no-new-privileges flag to prevent privilege escalation.
• Use a non-root user for all containers (already partially implemented).

---

6. Deserialization Attacks

Rating: 🟠 HIGH
Issue:
The policy-server component processes governance policies from YAML/JSON files, but there is no mention of safe deserialization practices.

Attack Vector:
An attacker could craft malicious YAML/JSON payloads to exploit unsafe deserialization, potentially executing arbitrary code or injecting malicious data into the policy engine.

Recommendation:

• Use safe YAML/JSON parsers (e.g., PyYAML.safe_load for YAML).
• Validate the structure and content of deserialized data against a strict schema using libraries like pydantic.
• Add unit tests to ensure that only valid policies are accepted.

---

7. Race Conditions

Rating: 🟡 MEDIUM
Issue:
The policy-server and trust-engine components may be vulnerable to race conditions in concurrent policy evaluations or trust checks, especially under high load.

Attack Vector:
An attacker could exploit timing discrepancies in policy evaluation or trust checks to bypass governance rules, particularly in distributed environments.

Recommendation:

• Implement locking mechanisms or atomic operations for critical sections in the policy-server and trust-engine.
• Use thread-safe data structures for policy storage and evaluation.
• Conduct stress testing to identify and mitigate race conditions.

---

8. Supply Chain Risks

Rating: 🟠 HIGH
Issue:
The Dockerfiles and Python modules rely on external dependencies, but there is no mention of dependency pinning or verification against typosquatting or dependency confusion attacks.

Attack Vector:
An attacker could introduce malicious packages into the supply chain via typosquatting or dependency confusion, compromising the entire AgentMesh governance layer.

Recommendation:

• Pin all dependencies to specific versions in requirements.txt or pyproject.toml.
• Use tools like pip-audit or safety to scan for vulnerabilities in dependencies.
• Verify the integrity of all dependencies using checksums or signatures.

---

Summary of Findings

Category	Rating	Fix Priority
Prompt Injection Defense Bypass	🔴 CRITICAL	Immediate
Policy Engine Circumvention	🔴 CRITICAL	Immediate
Trust Chain Weaknesses	🟠 HIGH	High
Credential Exposure	🟠 HIGH	High
Sandbox Escape	🔴 CRITICAL	Immediate
Deserialization Attacks	🟠 HIGH	High
Race Conditions	🟡 MEDIUM	Medium
Supply Chain Risks	🟠 HIGH	High

---

Action Plan

1. Immediate Fixes: Address prompt injection defenses, policy engine circumvention, and sandbox escape vulnerabilities.
2. High Priority Fixes: Implement trust chain validation, safe deserialization, and supply chain protections.
3. Medium Priority Fixes: Investigate and mitigate potential race conditions.
4. Ongoing Improvements: Regularly audit dependencies and CI/CD workflows for security risks.