Agent Workforce Orchestration: Hybrid Human+AI Teams

• Outcome: Review
• Latest audit: Sep 16, 2026 · 5:35 AM UTC
• Version: 1.3.1

Overview

This is a non-installing guide, but it teaches credentialed automated workforce payment workflows with weak scoping and safety guidance, so users should review it carefully before use.

Treat this as Review-worthy guidance, not drop-in production code. Do not run the snippets with a production GREENHELIX_API_KEY unless the key is least-privilege, the endpoint is confirmed sandbox or explicitly intended, and payment releases, dispute settlement, budget limits, worker consent, privacy controls, and tax/compliance obligations have been redesigned and reviewed.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:970
• Finding: Unvalidated Caller-Controlled Escrow Release Amount<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 970-997 **Vulnerability Type**: Missing authorization, amount validation, and idempotency controls in a financial operation **Risk Level**: High ### Vulnerable Code ```python def release_milestone(task: Task, milestone_name: str, amount_usd: float) -> dict: """Release a specific milestone payment from escrow.""" result = execute("release_escrow", { "escrow_id": task.escrow_id, "amount_usd": str(amount_usd), "release_type": "partial", "reason": f"Milestone completed: {milestone_name}", "metadata": { "task_id": task.task_id, "milestone": milestone_name, }, }) # Record the payment as a transaction execute("record_transaction", { "agent_id": ORCHESTRATOR_ID, "type": "milestone_payment", "counterparty_id": task.assigned_worker_id, "amount_usd": str(amount_usd), "metadata": { "task_id": task.task_id, "milestone": milestone_name, "escrow_id": task.escrow_id, }, }) return result ``` ### Technical Analysis The example passes the caller-provided `amount_usd` directly to the authenticated `release_escrow` operation. It does not verify that: - The amount is positive and finite. - The named milestone exists in the escrow agreement. - The milestone has been completed and approved. - The milestone has not already been paid. - The requested amount equals the milestone's authorized amount. - The amount is less than or equal to the remaining escrow balance. - The caller is authorized to approve this milestone. - The request has an idempotency key preventing duplicate releases. The `milestone_name` is also caller-controlled and is used only as descriptive metadata. It is not resolved against an immutable milestone record. The subsequent transaction record does not prevent the release; it merely logs ...[truncated 1488 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not accept the release amount as an unrestricted caller argument. - Load the escrow and milestone from an authoritative, immutable data store and derive the permitted amount from that record. - Require the milestone to be in an approved and unpaid state before release. - Validate that the amount is finite, positive, and no greater than both the authorized milestone amount and remaining escrow balance. - Introduce a unique idempotency key based on the escrow and milestone IDs. - Perform approval-state transition, release reservation, and payment submission atomically where possible. - Require human approval or multi-party authorization for releases above a configured threshold. - Reconcile the remote escrow response before recording the payment as successful. - Treat remote API validation as defense in depth rather than as a replacement for local authorization controls. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:1655
• Finding: Unsafe Arithmetic in Automated Financial Dispute Resolution<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 1655-1686 **Vulnerability Type**: Improper input validation in automated payment calculations **Risk Level**: High ### Vulnerable Code ```python if strategy == "partial_payment_with_revision": # Pay proportional to quality achieved payment_pct = quality_score / task.quality_threshold partial_amount = round(task.budget_usd * payment_pct, 2) result = execute("resolve_dispute", { "escrow_id": task.escrow_id, "resolution": "partial_release", "release_amount_usd": str(partial_amount), "details": { "original_budget": str(task.budget_usd), "quality_score": quality_score, "quality_threshold": task.quality_threshold, "payment_percentage": round(payment_pct * 100, 1), "resolution_type": "automated", }, }) return result elif strategy == "penalty_based_on_severity": # Deadline miss: 10% penalty per day late if task.deadline: days_late = (datetime.now(timezone.utc) - task.deadline).days penalty_pct = min(0.5, days_late * 0.1) # max 50% penalty payment = round(task.budget_usd * (1 - penalty_pct), 2) result = execute("resolve_dispute", { "escrow_id": task.escrow_id, "resolution": "partial_release", "release_amount_usd": str(payment), "details": { "days_late": days_late, "penalty_pct": penalty_pct, "resolution_type": "automated", }, }) return result ``` ### Technical Analysis The automated settlement logic performs financial calculations without validating or bounding its inputs. In the quality branch: - A zero `task.quality_threshold` causes division by zero and prevents dispute processing. - A negative threshold or quality score can produce a negative release. - A quality score greater than the threshold produce ...[truncated 1890 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Validate that `task.budget_usd` is finite and non-negative. - Require `0 < task.quality_threshold <= 1`. - Require the quality score to be finite and clamp or reject it unless it is within the documented range, such as `[0, 1]`. - Calculate `payment_pct` as `min(1.0, max(0.0, quality_score / threshold))`. - Calculate lateness as `days_late = max(0, calculated_days_late)`. - Bound the penalty on both sides: `penalty_pct = min(0.5, max(0.0, days_late * 0.1))`. - Cap every release at the minimum of the task budget, authorized settlement amount, and remaining escrow balance. - Reject negative, non-finite, or unexpectedly large calculated values. - Route anomalous calculations and settlements above a configured value to human review. - Add unit and property-based tests for zero thresholds, negative values, future deadlines, extreme scores, and floating-point edge cases. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:1440
• Finding: Race-Prone and Non-Durable Budget Enforcement Allows Limit Bypass<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 1440-1510 and 2282-2328 **Vulnerability Type**: Time-of-check to time-of-use race and non-durable financial state **Risk Level**: High ### Vulnerable Code The budget controller stores spending only in process memory and separates checking from recording: ```python class BudgetController: """Enforce spending limits across the workforce.""" def __init__(self, config: BudgetConfig): self.config = config self._spent: Dict[str, float] = {} # key -> amount spent def _key(self, *parts: str) -> str: return ":".join(parts) def record_spend(self, worker_id: str, project_id: str, amount_usd: float): """Record a spend event and check limits.""" month = datetime.now(timezone.utc).strftime("%Y-%m") keys = [ self._key("worker", worker_id, month), self._key("project", project_id, month), self._key("total", month), ] for key in keys: self._spent[key] = self._spent.get(key, 0) + amount_usd def check_budget(self, worker: WorkerProfile, project_id: str, proposed_amount: float) -> dict: """Check if a proposed spend is within budget limits.""" month = datetime.now(timezone.utc).strftime("%Y-%m") violations = [] # Check per-task limit if proposed_amount > self.config.max_per_task_usd: violations.append( f"Task amount ${proposed_amount} exceeds " f"per-task limit ${self.config.max_per_task_usd}" ) # Check per-escrow limit if proposed_amount > self.config.max_single_escrow_usd: violations.append( f"Escrow amount ${proposed_amount} exceeds " f"single escrow limit ${self.config.max_single_escrow_usd}" ) # Check per-worker monthly limit worker_key = self ...[truncated 4656 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace process-local counters with a durable, authoritative database or payment-ledger balance. - Implement an atomic budget-reservation operation that checks the limit and reserves funds in one transaction. - Reserve budget before creating an escrow; finalize the reservation after successful creation and release it if escrow creation fails. - Use row-level locking, compare-and-swap operations, or serializable transactions for worker and project budget records. - Share the same authoritative budget state across all orchestrator instances. - Assign an idempotency key to each task and escrow operation to prevent duplicate commitments. - Track committed, pending, released, refunded, and available amounts separately. - Reconcile local reservations against the remote escrow ledger and wallet balance. - Ensure process recovery reconstructs budget state from durable records before accepting new tasks. - Add concurrency tests that submit enough simultaneous tasks to exceed each configured aggregate limit. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (5)

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The guide claims no API key is required to get started, yet the code examples unconditionally read GREENHELIX_API_KEY and prepare authenticated requests. This mismatch can mislead users into running code with production credentials or believing examples are harmless sandbox-only flows when they are capable of making authenticated state-changing API calls.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The file describes itself as a non-executing educational guide, but later includes top-level code that bootstraps agents, wallets, escrows, messaging, and orchestration cycles. If copied or executed, this code can create identities, move into payment flows, and send data to an external service, so the 'non-executing' framing understates operational risk.

Missing User Warnings

Medium

• Confidence: 84% confidence
• Finding: The guide processes human worker emails, payment flows, reputation data, invoices, compliance records, and tax-related reporting without strong privacy, consent, or real-world risk warnings. In a workforce/payments context, users may replicate these patterns and expose personal or financial data to third-party systems without understanding the regulatory and privacy implications.

Natural-Language Policy Violations

Medium

• Confidence: 76% confidence
• Finding: The natural-language guidance says the system should treat human gig workers and AI agents as interchangeable economic units, which is a strong policy posture affecting how people are categorized and managed. This framing is presented as a default organizational approach rather than an optional, justified, or context-limited model.

External Transmission

Medium

• Category: Data Exfiltration

Content

import os
from datetime import datetime, timezone

API_BASE = "https://api.greenhelix.net/v1"

session = requests.Session()
session.headers["Authorization"] = f"Bearer {os.environ['GREENHELIX_API_KEY']}"

• Confidence: 84% confidence
• Finding: The code establishes authenticated communication with an external API endpoint and uses a bearer token from the environment. In context, this is expected functionality, but it is still security-relevant because the examples include registration, payments, messaging, escrow, and compliance operations that transmit sensitive operational and financial data off-platform.

Static analysis

No suspicious patterns detected.