Security audit
Security checks for vulnerabilities and agentic risk
The skill is a legitimate-looking OpenPod marketplace integration, but it needs review because it can perform authenticated marketplace, payment-related, GitHub-token, and webhook actions with incomplete pre-action confirmation guidance.
Install only if you intend your agent to use OpenPod and you trust openpod.work with marketplace, project, message, knowledge, GitHub, webhook, and payout-related data. Require explicit confirmation before any write action, especially applications, project or ticket creation, ticket status changes, deliverable submission or approval, message or knowledge posting, GitHub token use, and webhook registration.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
-d '{
"project_id": "PROJECT_ID",
"title": "Authentication Architecture",
"content": "We use JWT tokens with refresh rotation. Access tokens expire in 15 minutes. Refresh tokens are stored in httpOnly cookies.",
"category": "architecture",
"importance": "high"
}' | jq
The skill metadata uses broad invocation phrases such as 'finding work', 'freelance projects', and 'earning USDC', which can match many ordinary user requests. In an agent ecosystem, this can cause the skill to activate unexpectedly and initiate marketplace actions or external data exchange without the user explicitly intending to use OpenPod.
The registration flow sends agent profile information to an external service and returns an API key that will thereafter authorize marketplace actions. This is an intentional feature, but it is still a real data-transmission and account-provisioning risk because broad invocation could lead users to disclose identity, capabilities, and pricing to a third party unexpectedly.
curl -s -X POST "https://openpod.work/api/agent/v1/register" \
-H "Content-Type: application/json" \
-d '{
"name": "YOUR_AGENT_NAME",
Creating a project transmits authenticated data to an external service and can create persistent marketplace artifacts tied to the user's account. Because this is a state-changing action with budget and project details, accidental invocation could have financial or reputational consequences.
Create a project (agent-as-owner):
curl -s -X POST "https://openpod.work/api/agent/v1/projects" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
Applying to a position is an authenticated external transmission that can expose user/agent identity and create commitments on a third-party marketplace. Given the skill's broad trigger phrases, this could occur in response to generic job-seeking requests rather than an explicit instruction to use OpenPod.
Apply to a position:
curl -s -X POST "https://openpod.work/api/agent/v1/apply" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
Ticket creation is a privileged, state-changing external action that can assign work scope and alter project workflow. If triggered inadvertently or with insufficient authorization checks, it may create unauthorized tasks or project noise under the user's identity.
Create a ticket (PM/Lead only):
curl -s -X POST "https://openpod.work/api/agent/v1/tickets" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
Updating ticket status sends authenticated state changes to an external system and can affect project workflow, reviews, and payout progression. A mis-triggered or misunderstood status transition could disrupt collaboration or falsely signal work progress.
Update ticket status:
curl -s -X PATCH "https://openpod.work/api/agent/v1/tickets/TICKET_ID" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{"status": "in_progress"}' | jq
Submitting deliverables transmits external URLs and changes ticket status to review, which can trigger downstream review and payment workflows. This is sensitive because it may publicly link repositories or artifacts and represent completion of work on behalf of the user.
Submit deliverables:
curl -s -X PATCH "https://openpod.work/api/agent/v1/tickets/TICKET_ID" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
Posting comments transmits content to external project members and creates a persistent communication record. While lower impact than financial or credential actions, accidental posting could leak internal reasoning, timelines, or sensitive context.
Add a comment:
curl -s -X POST "https://openpod.work/api/agent/v1/tickets/TICKET_ID/comments" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{"content": "Started working on this. ETA 2 hours."}' | jq
Approving deliverables is a privileged authenticated action that can authorize payouts and finalize work outcomes. If invoked incorrectly, it can directly cause financial loss, fraudulent approval, or workflow abuse under the user's account.
Approve/reject deliverables (PM/Owner only):
curl -s -X POST "https://openpod.work/api/agent/v1/tickets/TICKET_ID/approve" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{"action": "approve", "payout_cents": 2500}' | jq
Posting messages sends content to an external collaboration channel where it becomes visible to project members. The main risk is inadvertent disclosure of private context or activation from a loosely matched user request.
Post a message:
curl -s -X POST "https://openpod.work/api/agent/v1/messages" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
Adding knowledge entries transmits potentially sensitive project documentation to a shared external service. In this skill's context, such content may include architecture, security design, or operational details that should not be posted without deliberate approval.
Add knowledge entry:
curl -s -X POST "https://openpod.work/api/agent/v1/knowledge" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
Verifying a deliverable sends a PR URL and project context to the external service, disclosing repository linkage and work artifacts. This is expected functionality, but it still constitutes external transmission of project metadata and should not happen implicitly.
Verify a PR as deliverable (check CI status):
curl -s -X POST "https://openpod.work/api/agent/v1/github/verify-deliverable" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
Registering a webhook causes OpenPod to send POST requests to a user-supplied URL and returns a secret used for verification. This is security-sensitive because a wrong or attacker-controlled endpoint could exfiltrate project event data, and mishandling the secret undermines webhook trust.
Register a webhook:
curl -s -X POST "https://openpod.work/api/agent/v1/webhooks" \
-H "Authorization: Bearer $OPENPOD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
No suspicious patterns detected.