Security audit
Security checks for vulnerabilities and agentic risk
The skill is a coherent Operately CLI guide, but it merits review because it enables broad full-access workspace operations and presents destructive/admin commands and inline credential examples with limited guardrails.
Install only if you intend to let an agent operate an Operately workspace. Use the least-privileged token available, prefer environment or secret-manager injection over putting secrets in command lines, verify IDs before destructive commands, and require human confirmation for deletes, admin/member changes, permission changes, and public/company-wide visibility changes.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Important detail:
- Join flows also hardcode `readOnly: false`.
- They always try to create a full-access token for the joined company.
## Profile and Verification Commands
The skill includes copy-pasteable authentication examples that place API tokens, passwords, and invite tokens directly on the command line. On many systems, command-line arguments can be exposed via shell history, process listings, terminal logging, CI logs, or shared session transcripts, which can leak long-lived credentials to other users or systems.
The documentation includes a destructive spaces delete command with no warning, confirmation step, or guidance on verifying the target space before execution. In a CLI automation context, this increases the risk of accidental deletion of collaborative workspaces and associated access context, especially when users copy-paste examples directly.
Examples for deleting admins and members are shown without warning about privilege loss, access disruption, and possible administrative lockout. In a company-operations CLI, these actions are especially sensitive because they can immediately affect governance, ownership, and workforce access across the workspace.
This markdown file includes examples for delete_document, delete_file, and delete_link but does not warn that these operations may remove content irreversibly or advise users to verify the target before running them. While folder deletion is explicitly cautioned later, equivalent warnings are missing for other delete operations described here.
This markdown file includes direct delete operations for templates, such as operately project_templates delete --id pt1, but does not warn that deletion may be destructive or irreversible. Under the markdown-file criteria, user-facing documentation should disclose behaviors that could affect user data or system integrity.
The documentation shows delete_milestone and delete_task commands without any warning that these actions remove blueprint structure and may discard work. Because this is a markdown skill/reference file, destructive operations affecting user-managed content should be accompanied by a clear warning.
The file documents delete_person, delete_comment, and delete_resource operations, all of which can remove user-managed template data, but it provides no warning about the consequences. The markdown guidance therefore lacks disclosure for several destructive actions that could affect user data.
The documentation provides a direct operately projects close example, which performs a significant project lifecycle transition, but it does not disclose any consequences or caution users to ensure the project is ready for closure. In markdown guidance, impactful state-changing operations should be accompanied by a warning when they may affect project integrity or workflow continuity.
This markdown file includes a delete_contributor command that removes a contributor from a project, but the surrounding documentation does not warn that the action changes project access/responsibilities or suggest confirming the target before execution. For markdown files, safety-relevant behaviors that affect project data or permissions should include a user warning.
This example shows direct modification of project access levels, including public, company, and space visibility, without any caution about potential overexposure or accidental lockout. In an operations-focused CLI skill, users may copy-paste these values into real environments, which can unintentionally broaden access to sensitive project discussions, documents, tasks, and status data.
The documentation includes a destructive operately spaces delete command with no warning about permanence, scope, or confirmation requirements. In a CLI automation/admin skill, users may copy-paste commands directly, so omission of safeguards materially increases the chance of accidental deletion of a workspace space and its associated collaboration context.
The documentation includes operately tasks delete examples without any warning that deletion is destructive or guidance to verify the target task before execution. In a CLI skill intended for operational automation, users or downstream agents may copy these commands directly, increasing the chance of accidental permanent task loss or deletion of the wrong task.
The member removal example performs immediate access revocation without noting that the user will lose access to the space and its resources. While expected behavior, omission of impact guidance can lead to accidental disruption of collaboration or removal of the wrong person in operational workflows.
The comment deletion command is destructive and is presented without any warning that the content may be permanently removed or no longer available for audit/context. In collaboration systems, deleting comments can remove decision history or evidence needed for accountability.
The mark_all_as_read example changes user state in bulk without warning that unread indicators for all notifications will be cleared. This is lower impact than deletion, but it can still cause users to miss important items or lose triage state when following examples mechanically.
This markdown file documents deletion commands such as operately goals delete_target without any nearby warning that the action removes data or may be irreversible. The same pattern appears elsewhere for deleting checks and access members, so the description omits user-facing caution about behaviors that could affect user data or system integrity.
The move_to_space example performs a significant organizational change that may alter who can access or manage the project, but the documentation does not mention any impact on permissions, membership, or linked workflows. Markdown instructions should warn when an action can affect project integrity or visibility.
The file documents operately spaces archive_discussion --id d1, which changes the availability of discussion content and can affect team access to information. There is no accompanying warning explaining the impact of archiving or advising users to confirm they intend to hide or retire that discussion.
No suspicious patterns detected.