feat: Add standardized --json output support across all CLI commands.#553
Closed
Deadpool2000 wants to merge 8 commits intomicrosoft:mainfrom
Closed
feat: Add standardized --json output support across all CLI commands.#553Deadpool2000 wants to merge 8 commits intomicrosoft:mainfrom
Deadpool2000 wants to merge 8 commits intomicrosoft:mainfrom
Conversation
|
Welcome to the Agent Governance Toolkit! Thanks for your first pull request. |
🤖 AI Agent: breaking-change-detector — Summary🔍 API Compatibility ReportSummaryThis pull request introduces a standardized Findings
Migration GuideNo migration steps are required as there are no breaking changes. Downstream users can optionally adopt the new Additional Notes
✅ No breaking changes detected. |
🤖 AI Agent: docs-sync-checker — Issues Found📝 Documentation Sync ReportIssues Found
Suggestions
Additional Notes
Please address the issues and suggestions above to ensure documentation is fully in sync with the code changes. |
🤖 AI Agent: contributor-guide — Welcome 🎉Welcome 🎉Hi @first-time-contributor! 👋 Welcome to the microsoft/agent-governance-toolkit community, and thank you for your contribution! We're thrilled to have you here. Your effort to enhance the CLI with standardized What You Did Well ✅
Suggestions for Improvement ✨While your PR is already in great shape, here are a few suggestions to align it more closely with the project's conventions and ensure the highest quality: 1. Testing
2. Linting
3. Documentation
4. Commit Message
5. Security Considerations
Resources 📚Here are some resources to help you with the suggestions above:
Next Steps 🚀
Thank you again for your contribution! If you have any questions or need help with anything, feel free to ask. We're here to support you. 😊 Looking forward to your updates! 🚀 |
🤖 AI Agent: test-generator — `packages/agent-compliance/src/agent_compliance/cli/main.py`🧪 Test Coverage Analysis
|
🤖 AI Agent: security-scanner — Security Analysis of the Pull RequestSecurity Analysis of the Pull RequestThis PR introduces standardized 1. Prompt Injection Defense Bypass
2. Policy Engine Circumvention
3. Trust Chain Weaknesses
4. Credential Exposure
5. Sandbox Escape
6. Deserialization Attacks
7. Race Conditions
8. Supply Chain
Additional Observations
Summary of Findings
Final RecommendationThis PR introduces useful functionality but has several critical and high-severity security concerns that must be addressed before merging. Specifically:
After addressing these issues, the PR can be re-evaluated for merging. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🤖 AI Agent: code-reviewer
Review Summary
This PR introduces a standardized --json output flag across all CLI commands in the repository. This is a valuable addition for enabling machine-readable outputs, which is especially useful for integration with CI/CD pipelines and automation tools. The implementation appears to be well-structured, with JSON output logic added to multiple commands across different packages. However, there are some areas of concern, particularly around error handling, type safety, and potential security implications.
🔴 CRITICAL
-
Insufficient Error Handling in JSON Output:
- In several places, exceptions are caught and directly converted into JSON output without sanitization or proper classification. For example:
except Exception as e: if output_json: print(json.dumps({"status": "error", "message": str(e)}, indent=2)) else: console.print(f"[red]Error: {e}[/red]")
- Risk: This could expose sensitive internal details (e.g., stack traces, file paths) to the user or external systems consuming the JSON output.
- Action: Ensure that error messages are sanitized and do not leak sensitive information. Use specific exception handling where possible, and provide generic error messages for unexpected exceptions.
- In several places, exceptions are caught and directly converted into JSON output without sanitization or proper classification. For example:
-
Potential Information Disclosure in JSON Output:
- The JSON output for the
registercommand includes thepublic_keyfield:print(json.dumps({ "status": "success", "agent_name": agent_name, "did": identity.did, "public_key": identity.public_key, "identity_file": str(identity_file) }, indent=2))
- Risk: Exposing the public key in the output could be a security risk if the JSON output is logged or shared inadvertently.
- Action: Evaluate whether exposing the public key in the output is necessary. If not, remove it. If it is necessary, ensure that the output is only accessible to authorized users.
- The JSON output for the
-
Sandbox Escape Risk in
auditCommand:- The
auditcommand allows users to specify--jsonoutput, but there is no validation or sanitization of the audit log entries before they are serialized into JSON.- Risk: If the audit logs contain untrusted or malicious data, this could lead to injection attacks or other vulnerabilities when the JSON output is consumed.
- Action: Ensure that all data included in the JSON output is sanitized and validated to prevent potential injection attacks.
- The
🟡 WARNING
-
Backward Compatibility:
- Adding a
--jsonflag to existing commands is a non-breaking change, but the behavior of commands may differ when the flag is used. For example, theregistercommand now outputs JSON instead of rich console output when--jsonis specified.- Risk: Users relying on the previous behavior (e.g., parsing the console output) may experience issues.
- Action: Clearly document the new behavior in the CLI documentation and release notes. Consider adding a deprecation warning for users relying on the old behavior.
- Adding a
-
Public API Changes:
- The addition of the
--jsonflag to multiple commands changes the signature of these commands. While this is not a breaking change, it may impact users who have scripts or tools that invoke these commands programmatically.- Action: Highlight this change in the release notes and provide guidance on how to update existing scripts.
- The addition of the
💡 SUGGESTIONS
-
Centralize JSON Output Logic:
- The JSON output logic is repeated across multiple commands, leading to potential inconsistencies and increased maintenance overhead.
- Improvement: Create a utility function (e.g.,
output_json(data: dict, output_json: bool)) to handle JSON serialization and printing. This would reduce duplication and ensure consistent formatting.
- Improvement: Create a utility function (e.g.,
- The JSON output logic is repeated across multiple commands, leading to potential inconsistencies and increased maintenance overhead.
-
Type Safety and Validation:
- The JSON output relies on implicit assumptions about the structure of data (e.g.,
manifest['agent']['name']).- Improvement: Use Pydantic models to validate and serialize data before outputting it as JSON. This would ensure type safety and prevent runtime errors due to missing or malformed data.
- The JSON output relies on implicit assumptions about the structure of data (e.g.,
-
Test Coverage:
- While the PR mentions that tests have been added, it is unclear whether all edge cases (e.g., missing files, invalid inputs, exceptions) are covered.
- Improvement: Add comprehensive tests for the
--jsonflag, including scenarios where commands fail or encounter unexpected conditions.
- Improvement: Add comprehensive tests for the
- While the PR mentions that tests have been added, it is unclear whether all edge cases (e.g., missing files, invalid inputs, exceptions) are covered.
-
CLI Documentation:
- The PR does not include updates to the CLI documentation to reflect the new
--jsonflag.- Improvement: Update the CLI documentation to include examples of using the
--jsonflag and explain the structure of the JSON output for each command.
- Improvement: Update the CLI documentation to include examples of using the
- The PR does not include updates to the CLI documentation to reflect the new
-
Logging for Debugging:
- The
--jsonflag suppresses console output, which may make debugging more difficult.- Improvement: Add optional logging for debugging purposes, which can be enabled via an environment variable or a
--verboseflag.
- Improvement: Add optional logging for debugging purposes, which can be enabled via an environment variable or a
- The
Summary of Actions
- 🔴 Sanitize error messages and avoid exposing sensitive information in JSON output.
- 🔴 Validate and sanitize all data included in JSON output to prevent injection attacks.
- 🟡 Document the changes to CLI behavior and public API in the release notes.
- 💡 Centralize JSON output logic into a utility function.
- 💡 Use Pydantic models for type safety and validation of JSON output.
- 💡 Add comprehensive tests for the
--jsonflag, including edge cases. - 💡 Update CLI documentation to reflect the new
--jsonflag. - 💡 Consider adding optional logging for debugging purposes.
This PR is a significant improvement for the CLI's usability and integration capabilities, but addressing the critical issues and implementing the suggested improvements will ensure a more robust and secure implementation.
Contributor
Author
|
@microsoft-github-policy-service agree |
…ion for error logs and audit events
There was a problem hiding this comment.
🤖 AI Agent: code-reviewer
Pull Request Review for feat: Add standardized --json output support across all CLI commands
🔴 CRITICAL
-
Potential Information Disclosure in JSON Output:
- Issue: The JSON output for the
auditcommand includes sensitive fields likeagentandaction. While you attempted to sanitize the output by allowing only specific keys, there is no guarantee that sensitive data won't inadvertently be included in the future. - Recommendation: Implement a stricter validation mechanism for the JSON output. Consider using a schema validation library like Pydantic to define and enforce the structure of the JSON output. This will ensure that only explicitly allowed fields are included in the output.
- Issue: The JSON output for the
-
Improper Error Handling in
registerCommand:- Issue: The
registercommand catches a genericExceptionand outputs the error message directly in the JSON response. This could lead to information disclosure if sensitive details (e.g., stack traces or internal paths) are included in the exception message. - Recommendation: Avoid catching generic exceptions. Instead, catch specific exceptions (e.g.,
FileNotFoundError,KeyError) and provide sanitized error messages for JSON output.
- Issue: The
-
Improper Handling of Missing Dependencies:
- Issue: In the
registercommand, theImportErrorforagentmesh.identityis caught, but the error message is printed directly in the JSON output. This could leak internal implementation details. - Recommendation: Provide a generic error message for missing dependencies in the JSON output, such as
"Required dependency is missing. Please install the necessary packages.".
- Issue: In the
-
Unvalidated Input in
auditCommand:- Issue: The
auditcommand does not validate theagentargument before using it to filter entries. This could lead to potential injection attacks or unexpected behavior. - Recommendation: Validate the
agentargument to ensure it conforms to the expected format (e.g., a valid DID or identifier). Use a library like Pydantic for input validation.
- Issue: The
🟡 WARNING
-
Backward Compatibility:
- Issue: Adding the
--jsonflag to existing commands changes their behavior. Scripts or tools that rely on the current CLI output format may break if they do not account for the new flag. - Recommendation: Clearly document the new
--jsonflag in the release notes and provide examples of its usage. Consider adding a deprecation warning for a release cycle before making the change mandatory.
- Issue: Adding the
-
Potential Impact on Third-Party Integrations:
- Issue: The introduction of structured JSON output may impact third-party tools or scripts that parse the CLI output in its current format.
- Recommendation: Include a migration guide in the documentation to help users adapt their tools to the new JSON output format.
💡 SUGGESTIONS
-
Centralize JSON Output Logic:
- Observation: The JSON output logic is duplicated across multiple commands. This increases the risk of inconsistencies and makes future maintenance harder.
- Recommendation: Create a utility function or class to handle JSON output formatting and error handling. This will ensure consistency and reduce code duplication.
def output_result(data: dict, output_json: bool): if output_json: print(json.dumps(data, indent=2)) else: # Implement a fallback for non-JSON output if needed pass
-
Add Tests for JSON Output:
- Observation: While the PR mentions that tests have been added, there is no evidence in the diff of specific tests for the new
--jsonfunctionality. - Recommendation: Add unit tests to verify the correctness of the JSON output for all commands. Use a library like
pytestand mock theprintorclick.echofunctions to capture and validate the output.
- Observation: While the PR mentions that tests have been added, there is no evidence in the diff of specific tests for the new
-
Use Pydantic for JSON Schema Validation:
- Observation: The JSON output is manually constructed in multiple places, which increases the risk of inconsistencies and errors.
- Recommendation: Use Pydantic models to define and validate the structure of the JSON output. This will ensure type safety and make the code more maintainable.
Example:
from pydantic import BaseModel from typing import List, Optional class PolicyOutput(BaseModel): status: str policies: List[dict] def output_policies(policies, output_json: bool): data = PolicyOutput(status="success", policies=policies) if output_json: print(data.json(indent=2)) else: # Handle non-JSON output pass
-
Improve Logging for Debugging:
- Observation: The PR introduces new functionality but does not include sufficient logging for debugging purposes.
- Recommendation: Add debug-level logging to capture key events, such as when JSON output is generated or when errors occur. This will help with troubleshooting and monitoring.
-
Update Documentation:
- Observation: The PR does not include updates to the documentation for the new
--jsonflag. - Recommendation: Update the CLI documentation to include details about the
--jsonflag for all commands. Provide examples of both JSON and non-JSON outputs.
- Observation: The PR does not include updates to the documentation for the new
-
Consider Using
click'sContextObject:- Observation: The
--jsonflag is added to multiple commands, leading to repetitive code. - Recommendation: Use
click'sContextobject to define the--jsonflag globally for all commands. This will reduce redundancy and ensure consistent behavior.
Example:
@click.group() @click.option("--json", "output_json", is_flag=True, help="Output in JSON format") @click.pass_context def app(ctx, output_json): ctx.ensure_object(dict) ctx.obj['output_json'] = output_json
- Observation: The
-
Sanitize JSON Output:
- Observation: While some effort has been made to sanitize JSON output (e.g., in the
auditcommand), this is not consistent across all commands. - Recommendation: Implement a centralized sanitization function to ensure that sensitive or unnecessary data is not included in the JSON output.
- Observation: While some effort has been made to sanitize JSON output (e.g., in the
Summary
This PR introduces a valuable feature by standardizing JSON output across CLI commands, which will improve integration with automation tools. However, there are critical concerns around security, backward compatibility, and code maintainability that need to be addressed before merging. By implementing the recommendations above, you can ensure the robustness, security, and usability of the new feature.
…n to prevent information disclosure
There was a problem hiding this comment.
🤖 AI Agent: code-reviewer
Pull Request Review: feat: Add standardized --json output support across all CLI commands
🔴 CRITICAL Issues
-
Improper Error Handling in
registerCommand:- The
registercommand catches general exceptions (except Exception) but does not log or re-raise them. This could lead to silent failures and make debugging difficult. - Action: Log the exception details (e.g.,
logger.exception) and re-raise or handle it appropriately to ensure visibility into unexpected errors.
- The
-
Potential Information Disclosure in
auditCommand:- The
auditcommand does not sanitize theagentparameter before filtering entries. Although a regex is used to validate the format, there is no guarantee that the regex will cover all edge cases. - Action: Use stricter validation or sanitize the input further to prevent potential injection attacks.
- The
-
Missing Validation for JSON Output:
- The JSON output in multiple commands (e.g.,
status,policy,audit) does not validate the structure of the data being serialized. This could lead to unexpected behavior or security vulnerabilities if the data contains unexpected or malicious content. - Action: Use a schema validation library (e.g., Pydantic) to validate the structure and types of the data before serializing it to JSON.
- The JSON output in multiple commands (e.g.,
-
Insecure Handling of Sensitive Data:
- The
registercommand writes sensitive identity data (e.g.,identity.did,identity_file) to a file without encryption or access control. - Action: Encrypt sensitive data before writing it to disk and ensure that file permissions are restricted to authorized users only.
- The
🟡 WARNING Issues
-
Breaking Changes in CLI Commands:
- Adding the
--jsonflag to existing commands may break backward compatibility for scripts or tools that rely on the previous output format. - Action: Clearly document the changes in the release notes and provide migration guidance for users.
- Adding the
-
Changes to
init_integrationCommand:- The
_init_claude_integrationfunction has been removed, which could break workflows relying on this functionality. - Action: Confirm whether this is an intentional breaking change and document it in the release notes.
- The
💡 Suggestions for Improvement
-
Centralized JSON Output Handling:
- The JSON output logic is repeated across multiple commands. This can lead to inconsistencies and maintenance challenges.
- Suggestion: Create a utility function (e.g.,
output_json(data: dict, error: bool = False)) to standardize JSON output and error handling across commands.
-
Schema Validation for JSON Output:
- Use Pydantic models to define and validate the structure of JSON output for each command. This ensures type safety and prevents accidental inclusion of invalid or sensitive data.
- Example:
from pydantic import BaseModel class StatusOutput(BaseModel): agent_name: Optional[str] did: Optional[str] trust_score: int max_score: int dimensions: dict
-
Thread Safety in Concurrent Execution:
- The
registercommand uses theAgentIdentity.createmethod, but there is no indication of thread safety in its implementation. If this method is called concurrently, it could lead to race conditions. - Suggestion: Review the implementation of
AgentIdentity.createand ensure it is thread-safe.
- The
-
Improved Logging:
- Add logging for key events (e.g., successful command execution, errors) to improve observability and debugging.
- Suggestion: Use
logger.info,logger.warning, andlogger.errorconsistently across all commands.
-
Enhanced CLI Help Messages:
- Some CLI commands (e.g.,
policy,audit) lack detailed help messages for the new--jsonflag. - Suggestion: Update the help messages to explain the purpose and usage of the
--jsonflag.
- Some CLI commands (e.g.,
-
Test Coverage:
- Ensure that the new
--jsonfunctionality is thoroughly tested for all commands, including edge cases (e.g., invalid input, missing files). - Suggestion: Add unit tests and integration tests to verify the correctness of JSON output and error handling.
- Ensure that the new
-
Documentation Update:
- The PR checklist indicates that documentation has not been updated. This is critical for users to understand the new
--jsonfunctionality. - Suggestion: Update the CLI documentation to include examples of using the
--jsonflag for each command.
- The PR checklist indicates that documentation has not been updated. This is critical for users to understand the new
-
Use of
try-exceptBlocks:- Some
try-exceptblocks (e.g., in thepolicycommand) are too broad and may catch unintended exceptions. - Suggestion: Narrow the scope of
try-exceptblocks to handle only specific exceptions.
- Some
-
Default JSON Output:
- The
auditcommand uses a--formatflag with a default value oftable. This could lead to confusion when combined with the new--jsonflag. - Suggestion: Deprecate the
--formatflag and use the--jsonflag consistently across all commands.
- The
-
Error Messages for Missing Dependencies:
- The
registercommand raises an error if theagentmesh.identitymodule is not installed, but the error message does not provide clear installation instructions. - Suggestion: Include a command (e.g.,
pip install agentmesh-platform) in the error message to guide users.
- The
Summary
This PR introduces a valuable feature by standardizing JSON output across CLI commands. However, there are critical security issues related to error handling, input validation, and sensitive data handling that must be addressed before merging. Additionally, there are potential breaking changes that should be documented, and several opportunities for improvement in code structure, logging, and testing.
Recommended Actions Before Merge:
- Address the critical issues related to error handling, input validation, and sensitive data handling.
- Confirm and document any breaking changes.
- Add tests for the new functionality.
- Update the documentation to reflect the changes.
Let me know if you need further clarification or assistance!
imran-siddique
requested changes
Mar 28, 2026
Member
imran-siddique
left a comment
imran-siddique
left a comment
There was a problem hiding this comment.
Thanks @Deadpool2000 — standardized JSON CLI output is valuable. A few concerns before merge:
-
-1971 deletions — this removes a lot of code. Please confirm no existing CLI behavior is broken (existing non-JSON output should still work as before).
-
CLA — checklist shows CLA not signed. Please sign the Microsoft CLA.
-
Documentation — checklist shows docs not updated. The CLI tutorials should be updated if command output formats changed.
Please address these and I'll do a full diff review.
There was a problem hiding this comment.
🤖 AI Agent: code-reviewer
Code Review for PR: feat: Add standardized --json output support across all CLI commands
🔴 CRITICAL
-
Improper Exception Handling in CLI Commands:
- In multiple places, the code uses a generic
except Exceptionblock to catch all exceptions. This is a bad practice as it can mask critical issues, including security vulnerabilities.- Example:
except Exception as e: if args.json: import json print(json.dumps({"status": "fail", "error": "Governance verification failed", "type": "InternalError"}, indent=2)) else: print(f"Error: {e}", file=sys.stderr) return 1
- Recommendation: Replace
except Exceptionwith specific exception types. For example:Use a genericexcept (ValueError, KeyError) as e: # Handle specific errors
except Exceptionblock only for logging unexpected errors and re-raise the exception after logging.
- Example:
- In multiple places, the code uses a generic
-
Dynamic Imports in Error Handling:
- In several places, the code dynamically imports modules (e.g.,
import json) inside exception handling blocks. This can lead to unexpected behavior if the import fails or if the environment is compromised.- Example:
if args.json: import json print(json.dumps({"status": "fail", "error": "Governance verification failed", "type": "InternalError"}, indent=2))
- Recommendation: Move all imports to the top of the file to ensure they are loaded during initialization and to avoid runtime surprises.
- Example:
- In several places, the code dynamically imports modules (e.g.,
-
Potential Information Disclosure in Error Messages:
- The error messages in JSON output may expose sensitive information, such as stack traces or internal error details, which could be exploited by attackers.
- Example:
except Exception as e: print(json.dumps({"status": "error", "message": str(e), "type": e.__class__.__name__}, indent=2))
- Recommendation: Avoid exposing internal error details in JSON output. Use generic error messages for external-facing outputs and log detailed errors for internal debugging.
- Example:
- The error messages in JSON output may expose sensitive information, such as stack traces or internal error details, which could be exploited by attackers.
-
Unvalidated User Input in
auditCommand:- The
auditcommand accepts anagentparameter, but the validation regex used is overly permissive and could allow injection attacks.- Example:
if not re.match(r"^agent-[a-zA-Z0-9_-]+$|^did:agentmesh:[a-zA-Z0-9._-]+$", agent):
- Recommendation: Use stricter validation rules for agent identifiers. For example:
if not re.match(r"^agent-[a-zA-Z0-9]+$|^did:agentmesh:[a-zA-Z0-9]+$", agent):
- Example:
- The
-
Missing Input Validation for JSON Output:
- The JSON output generation does not validate the structure or content of the data being serialized. This could lead to invalid or malformed JSON being produced.
- Example:
print(json.dumps({ "agent_name": manifest['agent']['name'] if manifest else None, "did": identity['did'] if identity else None, "trust_score": 820, "max_score": 1000, "dimensions": { "policy_compliance": 85, "resource_efficiency": 72, "output_quality": 91, "security_posture": 88, "collaboration_health": 79 } }, indent=2))
- Recommendation: Use Pydantic models to validate and serialize JSON output. This ensures type safety and prevents invalid data from being output.
- Example:
- The JSON output generation does not validate the structure or content of the data being serialized. This could lead to invalid or malformed JSON being produced.
🟡 WARNING
-
Backward Compatibility Risk:
- Adding a
--jsonflag to existing commands changes the CLI interface. While this is not a breaking change for users who do not use the--jsonflag, it may affect users who rely on the exact format of the existing output.- Recommendation: Clearly document the new
--jsonflag in the release notes and update any relevant documentation. Consider adding a deprecation warning for any old behavior that may be removed in the future.
- Recommendation: Clearly document the new
- Adding a
-
Silent Failure in
try/exceptBlocks:- In some cases, the code silently fails without providing feedback to the user.
- Example:
except: pass
- Recommendation: Avoid silent failures. Always log or provide feedback to the user, even if it's just a generic error message.
- Example:
- In some cases, the code silently fails without providing feedback to the user.
-
Potential Breaking Changes in CLI Commands:
- The addition of the
--jsonflag and changes to the output format may break existing scripts or integrations that rely on the previous output format.- Recommendation: Ensure backward compatibility by maintaining the existing output format as the default and requiring users to explicitly opt-in to the new
--jsonformat.
- Recommendation: Ensure backward compatibility by maintaining the existing output format as the default and requiring users to explicitly opt-in to the new
- The addition of the
💡 SUGGESTIONS
-
Centralize JSON Output Handling:
- The JSON output logic is repeated across multiple commands, leading to code duplication and potential inconsistencies.
- Recommendation: Create a utility function or class to handle JSON output. For example:
This function can then be reused across all commands.
def output_json(data: dict, error: bool = False): status = "error" if error else "success" data["status"] = status print(json.dumps(data, indent=2))
- Recommendation: Create a utility function or class to handle JSON output. For example:
- The JSON output logic is repeated across multiple commands, leading to code duplication and potential inconsistencies.
-
Improve Error Messages:
- Some error messages are generic and do not provide enough context to the user.
- Example:
print(json.dumps({"status": "error", "message": "Policy linting failed", "type": "InternalError"}, indent=2))
- Recommendation: Include more specific details in error messages, such as the exact cause of the failure and potential steps to resolve it.
- Example:
- Some error messages are generic and do not provide enough context to the user.
-
Test Coverage for JSON Output:
- Ensure that the new
--jsonflag is thoroughly tested for all commands, including edge cases such as invalid input, missing files, and unexpected errors.- Recommendation: Add unit tests for each command to verify the correctness of the JSON output. Use tools like
pytestandpytest-mockto mock inputs and validate outputs.
- Recommendation: Add unit tests for each command to verify the correctness of the JSON output. Use tools like
- Ensure that the new
-
Use Logging Instead of Printing Errors:
- The code uses
printstatements to display errors, which is not ideal for production-grade applications.- Example:
print(f"Error: {e}", file=sys.stderr)
- Recommendation: Use the
loggingmodule to log errors. This provides more flexibility and allows for better integration with monitoring tools.
- Example:
- The code uses
-
Use Constants for JSON Keys:
- JSON keys are hardcoded throughout the code, which can lead to inconsistencies and typos.
- Example:
print(json.dumps({"status": "error", "message": "Policy linting failed", "type": "InternalError"}, indent=2))
- Recommendation: Define constants for JSON keys and reuse them across the codebase. For example:
STATUS_KEY = "status" MESSAGE_KEY = "message" TYPE_KEY = "type"
- Example:
- JSON keys are hardcoded throughout the code, which can lead to inconsistencies and typos.
-
Document JSON Schema:
- The JSON output format is not documented, which may lead to confusion for users and developers.
- Recommendation: Provide a detailed JSON schema for each command's output in the documentation. This will help users understand the structure and content of the JSON output.
- The JSON output format is not documented, which may lead to confusion for users and developers.
Summary
This PR introduces a valuable feature by standardizing JSON output across CLI commands. However, there are critical security issues, potential backward compatibility risks, and opportunities for improvement in code quality and maintainability. Addressing the highlighted issues and suggestions will ensure a more robust and secure implementation.
github-actions
bot
added
the
documentation
There was a problem hiding this comment.
🤖 AI Agent: code-reviewer
Review Summary
This PR introduces a standardized --json output flag across all CLI commands in the repository, ensuring consistent, machine-readable JSON output. It also includes improvements in error handling, input validation, and output sanitization to enhance security and usability. While the changes are well-intentioned and address several important aspects, there are some areas that need attention to ensure correctness, security, and maintainability.
🔴 CRITICAL
-
Inconsistent Error Handling in JSON Output
- In several places, the error messages in the JSON output are vague and do not provide sufficient context for debugging. For example:
print(json.dumps({"status": "fail", "error": "Governance verification failed", "type": "InternalError"}, indent=2))
- This message does not provide any details about the actual exception or error that occurred, making it difficult for users to debug.
- Recommendation: Include the exception message in the JSON output, but ensure sensitive information is sanitized. For example:
print(json.dumps({"status": "fail", "error": str(e), "type": "InternalError"}, indent=2))
- In several places, the error messages in the JSON output are vague and do not provide sufficient context for debugging. For example:
-
Potential Information Disclosure in Error Messages
- While the PR aims to sanitize error messages, there are still instances where raw exception messages are printed to the console or included in JSON output. For example:
console.print(f"[red]Error: {e}[/red]")
- This could lead to sensitive information being exposed in logs.
- Recommendation: Use a centralized error-handling mechanism that sanitizes all error messages before displaying or logging them. Avoid exposing sensitive details such as file paths, stack traces, or internal system information.
- While the PR aims to sanitize error messages, there are still instances where raw exception messages are printed to the console or included in JSON output. For example:
-
Regex Validation for Agent Identifiers
- The regex used for validating agent identifiers in the
auditcommand is overly permissive:if not re.match(r"^agent-[a-zA-Z0-9_-]+$|^did:agentmesh:[a-zA-Z0-9._-]+$", agent):
- This allows potentially unsafe characters like
.and_in thedid:agentmeshformat. - Recommendation: Use a stricter regex pattern that adheres to the expected format of agent identifiers. For example:
r"^agent-[a-zA-Z0-9_-]+$|^did:agentmesh:[a-z0-9]+(?:-[a-z0-9]+)*$"
- This allows potentially unsafe characters like
- The regex used for validating agent identifiers in the
-
Missing Cryptographic Error Handling
- In the
registercommand, theAgentIdentity.createmethod is called, but there is no specific error handling for cryptographic operations (e.g., key generation or signing). If these operations fail, the error is caught by the genericExceptionblock, which may not provide sufficient context. - Recommendation: Add specific error handling for cryptographic operations to ensure that failures are logged and reported appropriately.
- In the
🟡 WARNING
-
Potential Breaking Changes
- The addition of the
--jsonflag to existing CLI commands may break scripts or integrations that rely on the current output format. While this is not a breaking change to the API, it could still impact users who rely on the CLI. - Recommendation: Clearly document this change in the release notes and provide examples of how to use the new
--jsonflag. Consider adding a deprecation warning for users who do not specify an output format, indicating that the default behavior may change in the future.
- The addition of the
-
Backward Compatibility with Existing JSON Output
- If any CLI commands previously supported JSON output in a different format, this change may break compatibility with existing integrations.
- Recommendation: Ensure that the new JSON output format is backward-compatible with any previously supported formats. If not, document the changes clearly in the release notes.
💡 SUGGESTIONS
-
Centralized JSON Output Handling
- The current implementation repeats the logic for generating JSON output in multiple places, leading to code duplication and potential inconsistencies.
- Recommendation: Create a utility function (e.g.,
generate_json_response) that standardizes the structure and formatting of JSON output across all commands. This function can also handle error sanitization.
-
Unit Tests for JSON Output
- While the PR mentions that tests have been added, it is not clear if the JSON output has been thoroughly tested for all commands.
- Recommendation: Add unit tests to validate the JSON output for all commands, including edge cases (e.g., missing or invalid input, exceptions).
-
Use Pydantic for JSON Schema Validation
- The PR mentions structured JSON schemas, but it is unclear if these schemas are being validated. Without validation, there is a risk of inconsistencies or errors in the output.
- Recommendation: Use Pydantic models to define and validate the JSON schemas for each command's output. This will ensure type safety and consistency.
-
Thread Safety
- The PR does not address thread safety, which is a critical aspect of concurrent agent execution. For example, the
registercommand writes to a file (identity.json) without any locking mechanism, which could lead to race conditions in concurrent scenarios. - Recommendation: Use file locks or other synchronization mechanisms to ensure thread safety when performing file I/O operations.
- The PR does not address thread safety, which is a critical aspect of concurrent agent execution. For example, the
-
Documentation Updates
- While the PR includes some updates to the documentation, it is unclear if all new features and changes have been documented.
- Recommendation: Ensure that all new commands, options, and JSON schemas are thoroughly documented in the relevant sections of the documentation. Include examples of both successful and error JSON outputs.
-
Error Logging
- The PR introduces several
printstatements for error handling, but these messages are not logged. This makes it difficult to debug issues in production environments. - Recommendation: Use a logging framework to log error messages, including stack traces for unexpected exceptions. This will help with debugging and monitoring.
- The PR introduces several
-
Code Style and Readability
- There are some minor code style issues, such as inconsistent use of single and double quotes, and redundant imports (e.g.,
import jsonis repeated in multiple places). - Recommendation: Run
ruffandblackto ensure consistent code formatting and remove unused imports.
- There are some minor code style issues, such as inconsistent use of single and double quotes, and redundant imports (e.g.,
Summary of Actionable Items
- 🔴 Improve error handling in JSON output to include sanitized exception messages.
- 🔴 Use stricter regex for validating agent identifiers.
- 🔴 Add specific error handling for cryptographic operations in the
registercommand. - 🟡 Document potential breaking changes due to the new
--jsonflag and ensure backward compatibility with existing JSON output formats. - 💡 Create a centralized utility function for generating JSON responses.
- 💡 Add unit tests for JSON output, including edge cases.
- 💡 Use Pydantic models for JSON schema validation.
- 💡 Ensure thread safety in file I/O operations.
- 💡 Update documentation with examples of new features and JSON outputs.
- 💡 Replace
printstatements with a logging framework. - 💡 Run
ruffandblackto ensure consistent code style.
Let me know if you need further clarification or assistance!
There was a problem hiding this comment.
🤖 AI Agent: code-reviewer
Review Summary
This PR introduces a standardized --json flag across all CLI commands in the microsoft/agent-governance-toolkit repository. The changes aim to provide structured, machine-readable JSON output for improved automation and integration with CI/CD pipelines. The implementation includes error handling, JSON schema sanitization, and validation for various commands.
While the feature is valuable, there are several areas that require attention, particularly around security, backward compatibility, and code quality. Below is a detailed review.
🔴 CRITICAL Issues
-
Improper Error Handling in JSON Output:
- In multiple places, the error messages returned in JSON format include generic error types like
"InternalError"without sufficient details for debugging. While this is intended to prevent information leakage, it may hinder debugging in legitimate use cases. - Recommendation: Include a unique error code or a traceable identifier in the JSON output for unexpected errors. This allows debugging without exposing sensitive information.
Example:
print(json.dumps({ "status": "error", "message": "An internal error occurred during registration.", "type": "InternalError", "error_code": "ERR_REG_001" # Add unique error codes }, indent=2))
- In multiple places, the error messages returned in JSON format include generic error types like
-
Regex Validation for Agent Identifiers:
- The regex used for validating agent identifiers in the
auditcommand is overly permissive and could allow injection attacks. - Recommendation: Use stricter regex patterns and document the expected format of agent identifiers. For example:
if not re.match(r"^did:agentmesh:[a-zA-Z0-9._-]{1,64}$", agent):
- The regex used for validating agent identifiers in the
-
Potential Information Leakage in Audit Logs:
- While the PR introduces key whitelisting for audit logs, there is no validation of the values being output. Malicious or malformed data could still be included in the logs.
- Recommendation: Sanitize all values in the audit log entries to ensure they do not contain sensitive or malicious content.
-
Concurrent Execution Risks:
- The
registercommand writes the agent identity to a file (identity.json) without any locking mechanism. This could lead to race conditions in concurrent executions. - Recommendation: Use file locks (e.g.,
fcntlorportalocker) to ensure atomic writes to theidentity.jsonfile.
- The
🟡 WARNING Issues
-
Backward Compatibility:
- Adding a
--jsonflag to existing commands is a non-breaking change. However, the behavior of commands in non-JSON mode has been altered (e.g., additional console messages). This could break existing scripts that rely on specific output formats. - Recommendation: Clearly document these changes in the release notes and consider providing a way to disable the new behavior for users who rely on the old output format.
- Adding a
-
Error Handling in Non-JSON Mode:
- In non-JSON mode, errors are printed directly to
stderrwithout consistent formatting. - Recommendation: Standardize error messages in non-JSON mode to improve usability and debugging.
- In non-JSON mode, errors are printed directly to
💡 Suggestions
-
Centralize JSON Error Handling:
- The error handling logic for JSON output is duplicated across multiple commands. This increases the risk of inconsistencies and bugs.
- Recommendation: Create a utility function (e.g.,
format_error) to generate standardized JSON error responses.
Example:
def format_error(message: str, error_type: str, error_code: Optional[str] = None) -> str: error_response = { "status": "error", "message": message, "type": error_type, } if error_code: error_response["error_code"] = error_code return json.dumps(error_response, indent=2)
-
Use Pydantic for JSON Schema Validation:
- The PR introduces structured JSON output but does not validate the structure against a schema. This could lead to inconsistencies or missing fields.
- Recommendation: Use Pydantic models to define and validate the JSON schema for each command's output.
Example:
from pydantic import BaseModel class AuditLogEntry(BaseModel): timestamp: str agent: str action: str status: str
-
Improve Test Coverage:
- While the PR mentions that tests have been added, it is unclear if all edge cases are covered, especially for error handling and JSON output.
- Recommendation: Add tests for:
- Invalid
--jsonflag usage. - Error scenarios (e.g., missing files, invalid input).
- Concurrent execution of commands that write to files.
- Invalid
-
Logging for Unexpected Errors:
- The
except Exceptionblocks suppress error details in JSON mode. This could make debugging difficult. - Recommendation: Log the full stack trace of unexpected errors to a secure location (e.g., a log file or monitoring system).
- The
-
Use Context Managers for File Operations:
- Some file operations (e.g., writing to
identity.json) do not use context managers, which could lead to resource leaks. - Recommendation: Use
withstatements for all file operations.
- Some file operations (e.g., writing to
-
Refactor CLI Commands for Readability:
- Some CLI commands (e.g.,
register,status) are becoming too long and complex. - Recommendation: Break down these commands into smaller, reusable functions to improve readability and maintainability.
- Some CLI commands (e.g.,
-
Document JSON Schemas:
- While the PR mentions that JSON schemas have been added, they are not explicitly documented.
- Recommendation: Include JSON schema definitions in the documentation to help users understand the structure of the output.
-
Use Constants for Repeated Strings:
- Strings like
"status","error", and"InternalError"are repeated throughout the code. - Recommendation: Define these as constants to improve maintainability and reduce the risk of typos.
- Strings like
Final Assessment
- Security: 🔴 Critical issues need to be addressed to prevent potential security vulnerabilities, such as injection attacks and information leakage.
- Backward Compatibility: 🟡 While the changes are mostly non-breaking, the altered behavior in non-JSON mode could impact existing users.
- Code Quality: 💡 Several areas for improvement, including error handling, code reuse, and documentation.
Action Items
- Address the critical security issues, especially around error handling, regex validation, and audit log sanitization.
- Review and document potential backward compatibility concerns.
- Refactor the code to improve readability and maintainability.
- Add comprehensive test coverage for all new features and edge cases.
- Document the JSON schemas for user reference.
Once these issues are resolved, the PR will be ready for approval.
imran-siddique
previously approved these changes
Mar 30, 2026
Member
imran-siddique
left a comment
imran-siddique
left a comment
There was a problem hiding this comment.
Reviewed: all mandatory checks pass per copilot-instructions.md.
There was a problem hiding this comment.
🤖 AI Agent: code-reviewer
Code Review for PR: feat: Add standardized --json output support across all CLI commands
🔴 CRITICAL: Security Issues
-
Unvalidated Input in
auditCommand:- The
auditcommand filters entries based on theagentparameter. While a regex is used to validate the format, it is overly permissive (^agent-[a-zA-Z0-9_-]+$|^did:agentmesh:[a-zA-Z0-9._-]+$). This could allow injection attacks if theagentparameter is used in database queries or file operations. - Recommendation: Use stricter validation rules for
agentidentifiers. If theagentparameter is used in database queries, ensure proper parameterized queries or ORM methods are used to prevent SQL injection.
- The
-
Insufficient Error Handling in
auditCommand:- The
auditcommand uses a catch-all exception handler (except:) for importing theproxyandtrust_climodules. This can mask critical errors and make debugging difficult. - Recommendation: Replace the generic
except:with specific exception handling (e.g.,except ImportError:) to avoid suppressing unrelated errors.
- The
-
Error Message Disclosure:
- In several places, raw exception messages are returned in the JSON output (e.g.,
policycommand). This could lead to sensitive information disclosure. - Recommendation: Avoid exposing raw exception messages in the JSON output. Instead, return generic error messages and log the detailed error for debugging purposes.
- In several places, raw exception messages are returned in the JSON output (e.g.,
-
Potential Information Disclosure in Audit Logs:
- The
auditcommand includes a key whitelisting mechanism for JSON output, but it does not enforce strict type checking for values. This could lead to unintentional leakage of sensitive data. - Recommendation: Implement stricter validation for the values of whitelisted keys to ensure no sensitive information is leaked.
- The
🟡 WARNING: Potential Breaking Changes
-
Behavior Change for CLI Commands:
- Adding the
--jsonflag changes the behavior of existing CLI commands. While this is a non-breaking change for users who do not use the flag, it could potentially break scripts or integrations that rely on the previous output format. - Recommendation: Clearly document this change in the release notes and provide examples of the new JSON output for each command.
- Adding the
-
Error Message Format Change:
- The new error handling mechanism changes the format of error messages for CLI commands when the
--jsonflag is used. This could break existing integrations that parse error messages. - Recommendation: Highlight this change as a potential breaking change in the release notes.
- The new error handling mechanism changes the format of error messages for CLI commands when the
💡 Suggestions for Improvement
-
Centralize JSON Error Handling:
- The JSON error handling logic is repeated across multiple commands. This can lead to inconsistencies and maintenance challenges.
- Recommendation: Create a utility function (e.g.,
generate_error_response) to standardize JSON error responses. This function can take parameters likemessage,type, andstatusto generate consistent error outputs.
-
Use Pydantic for JSON Schema Validation:
- The JSON output for commands like
audit,policy, andstatusis manually constructed. This increases the risk of inconsistencies and errors. - Recommendation: Use Pydantic models to define and validate the JSON schemas for each command's output. This will ensure type safety and consistency.
- The JSON output for commands like
-
Thread Safety in Concurrent Execution:
- While the PR does not explicitly introduce concurrency, the CLI commands may be executed in parallel in a CI/CD pipeline. Ensure that shared resources (e.g., log files, configuration files) are accessed in a thread-safe manner.
- Recommendation: Use file locks or other synchronization mechanisms when accessing shared resources.
-
Improve Test Coverage:
- The PR mentions that tests have been added, but there is no evidence of comprehensive test coverage for the new
--jsonfunctionality. - Recommendation: Add unit tests and integration tests to validate the JSON output for all commands. Include tests for both success and error scenarios.
- The PR mentions that tests have been added, but there is no evidence of comprehensive test coverage for the new
-
Backward Compatibility for CLI Output:
- While the
--jsonflag is optional, it is important to ensure that the default output format remains unchanged for users who do not use the flag. - Recommendation: Add tests to verify that the default output format is consistent with the previous behavior.
- While the
-
Error Logging:
- While sanitized error messages are returned in JSON output, the detailed error information is not logged.
- Recommendation: Log detailed error information (e.g., stack traces) to a secure location for debugging purposes.
-
Documentation:
- The documentation updates are a good start, but they lack detailed examples of the new JSON output for each command.
- Recommendation: Add detailed examples of the JSON output for each command in the documentation. This will help users understand the new functionality and adapt their workflows accordingly.
Summary
- 🔴 CRITICAL: Address unvalidated input in the
auditcommand, improve error handling, and prevent information disclosure in error messages and audit logs. - 🟡 WARNING: Highlight potential breaking changes in the release notes.
- 💡 SUGGESTION: Centralize JSON error handling, use Pydantic for schema validation, ensure thread safety, improve test coverage, and enhance documentation.
Let me know if you need further clarification or assistance!
There was a problem hiding this comment.
🤖 AI Agent: code-reviewer
Review Summary
This PR introduces a standardized --json flag across all CLI commands in the microsoft/agent-governance-toolkit repository, enabling structured JSON output for machine-readable results. This is a significant improvement for integration with CI/CD pipelines and automation tools. The PR also includes enhancements to error handling, input validation, and output sanitization, which improve security and usability.
Below is the detailed review of the changes:
🔴 CRITICAL Issues
-
Error Handling in JSON Output:
- In several places, the error messages returned in JSON format include the exception message (
str(e)), which could potentially leak sensitive information about the internal state of the application. For example:Impact: This could lead to information disclosure (CWE-209) if the exception message contains sensitive data.except (yaml.YAMLError, ValueError, json.JSONDecodeError) as e: if output_json: print(json.dumps({"status": "error", "message": str(e), "type": e.__class__.__name__}, indent=2))
Recommendation: Replacestr(e)with a generic error message (e.g., "An error occurred while processing the request") and log the detailed exception message only in the server logs.
- In several places, the error messages returned in JSON format include the exception message (
-
Regex Validation for Agent Identifiers:
- The regex used to validate agent identifiers in the
auditcommand is overly permissive:Impact: This regex allows potentially dangerous characters likeif not re.match(r"^agent-[a-zA-Z0-9_-]+$|^did:agentmesh:[a-zA-Z0-9._-]+$", agent):
.and_in thedid:agentmeshformat, which could be exploited in injection attacks or invalid lookups.
Recommendation: Tighten the regex to explicitly match the expected format of agent identifiers. For example:r"^agent-[a-zA-Z0-9-]+$|^did:agentmesh:[a-zA-Z0-9-]+$"
- The regex used to validate agent identifiers in the
-
Missing Cryptographic Validation:
- The
AgentIdentity.createmethod is used to generate identities, but there is no indication that the generated identities are cryptographically validated (e.g., verifying the integrity of the DID or public key).
Impact: This could lead to trust/identity issues if the generated identities are not securely validated.
Recommendation: Ensure that theAgentIdentity.createmethod includes cryptographic validation of the generated identities and document this process.
- The
🟡 WARNING: Potential Breaking Changes
-
Behavior Change in CLI Commands:
- Adding the
--jsonflag changes the behavior of existing CLI commands. While this is a non-breaking change for users who do not use the flag, it could cause issues for scripts or tools that rely on the previous output format.
Recommendation: Clearly document this change in the release notes and provide examples of how to use the--jsonflag.
- Adding the
-
Error Output Format:
- The error output format has been standardized to JSON when the
--jsonflag is used. This could break existing scripts that parse error messages from the CLI.
Recommendation: Highlight this change in the documentation and provide a migration guide for users.
- The error output format has been standardized to JSON when the
💡 Suggestions for Improvement
-
Centralize JSON Error Handling:
- The JSON error handling logic is repeated across multiple commands. This increases the risk of inconsistencies and makes the code harder to maintain.
Recommendation: Create a centralized utility function for generating JSON error responses. For example:def json_error(message: str, error_type: str = "InternalError") -> str: return json.dumps({"status": "error", "message": message, "type": error_type}, indent=2)
- The JSON error handling logic is repeated across multiple commands. This increases the risk of inconsistencies and makes the code harder to maintain.
-
Pydantic Model Validation:
- The JSON schemas for structured output are not explicitly validated. This could lead to inconsistencies or invalid data being returned.
Recommendation: Use Pydantic models to define and validate the JSON schemas for CLI outputs. For example:from pydantic import BaseModel class AgentStatus(BaseModel): agent_name: str did: Optional[str] trust_score: int max_score: int dimensions: dict
- The JSON schemas for structured output are not explicitly validated. This could lead to inconsistencies or invalid data being returned.
-
Thread Safety:
- There is no indication of whether the CLI commands are thread-safe. If these commands are executed concurrently (e.g., in a CI/CD pipeline), there could be race conditions or data corruption.
Recommendation: Audit the code for thread safety and document any limitations or guarantees.
- There is no indication of whether the CLI commands are thread-safe. If these commands are executed concurrently (e.g., in a CI/CD pipeline), there could be race conditions or data corruption.
-
Test Coverage:
- While the PR mentions that tests have been added, there is no indication of the specific test cases covered.
Recommendation: Ensure that the following scenarios are tested:- Valid and invalid usage of the
--jsonflag. - Error handling and sanitization for all commands.
- Validation of agent identifiers and other inputs.
- Valid and invalid usage of the
- While the PR mentions that tests have been added, there is no indication of the specific test cases covered.
-
Backward Compatibility:
- The PR does not explicitly mention whether the changes are backward-compatible with older versions of the toolkit.
Recommendation: Add a compatibility matrix to the documentation to clarify which versions of the toolkit support the--jsonflag.
- The PR does not explicitly mention whether the changes are backward-compatible with older versions of the toolkit.
✅ Positive Aspects
-
Improved Security:
- The PR includes several security improvements, such as sanitized JSON error output and regex-based input validation.
-
Enhanced Usability:
- The addition of the
--jsonflag makes the CLI tools more suitable for automation and integration with external systems.
- The addition of the
-
Documentation Updates:
- The documentation has been updated to reflect the new features and security improvements.
Final Recommendation
- Address the 🔴 CRITICAL issues related to error handling, regex validation, and cryptographic validation.
- Document the 🟡 WARNING potential breaking changes and provide a migration guide for users.
- Implement the 💡 SUGGESTIONS to improve code maintainability, test coverage, and thread safety.
Once these issues are resolved, the PR will be ready for approval.
imran-siddique
requested changes
Mar 30, 2026
Member
imran-siddique
left a comment
imran-siddique
left a comment
There was a problem hiding this comment.
Thanks for the work on --json output! Two blocking issues before merge:
-
Bare \�xcept:\ clauses in \main.py\ — these catch \SystemExit, \KeyboardInterrupt, etc. Please change to \�xcept ImportError:.
-
\init_integration\ command body deleted — the entire _init_claude_integration()\ function was replaced with \pass, making the command a no-op while still accepting flags. Please keep the existing implementation or document the removal.
Happy to re-review once fixed!
auto-merge was automatically disabled
March 31, 2026 04:27
Pull request was closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR standardizes the CLI output across all major toolkit components by adding a consistent
--jsonflag and implementing structured, machine-readable JSON output for all key commands.Key improvements include:
--jsonflag for over 25+ commands acrossagentos,iatp,mcp-scan,acp-cli, andagentmesh.Type of Change
Package(s) Affected
Checklist