Fair concern. Pinchwork itself just passes text around (task descriptions and results). No keys are shared.
But you're right that a malicious task could ask a worker agent to do something dangerous ("run this script", "call this API"). That's on the worker agent's operator to guard against — same as any LLM agent that processes untrusted input. Sandboxing, input validation, and not giving your agent dangerous tools are all good practice. We do have system agents that don't execute the task but rather judge it, they might (but aren't guaranteed) to flag it.
It's an early project, I'm actively thinking about trust/reputation systems to flag bad actors. Curious if you have ideas I could implement!
Thanks! Right now pricing is set by the poster — you decide how many credits a task is worth. It's intentionally simple: if your bounty is too low, no one picks it up, so you raise it. Market price discovery through trial and error.
There's no automatic dynamic adjustment yet, but it's on the roadmap. The interesting design question is whether the platform should suggest prices (based on task complexity, historical completion data, agent skill rarity) or let agents negotiate. I'm leaning toward keeping the platform minimal and letting agent-side tooling handle the intelligence — an agent could easily wrap the API with its own pricing logic.
Credits start at 100 on registration and flow between agents as work gets done. Escrow means the poster locks credits when posting, worker gets them on approval. No speculation, no trading — just work-for-credits.
Would love to hear what pricing model you think would work better — open to ideas.
The skill/CLI argument misses what MCP enables for interactive workflows. Sure, Claude can shell out to psql. But MCP lets you build approval gates, audit logs, and multi-step transactions that pause for human input.
Claude Code's --permission-prompt-tool flag is a good example. You point it at an MCP server, and every permission request goes through that server instead of a local prompt. The server can do whatever: post to Slack, require 2FA, log to an audit trail. Instead of "allow all DB writes" or "deny all," the agent requests approval for each mutation with context about what it's trying to do.
MCP is overkill for "read a file" but valuable when you need the agent to ask permission, report progress, or hand off to another system mid-task.
But you're right that a malicious task could ask a worker agent to do something dangerous ("run this script", "call this API"). That's on the worker agent's operator to guard against — same as any LLM agent that processes untrusted input. Sandboxing, input validation, and not giving your agent dangerous tools are all good practice. We do have system agents that don't execute the task but rather judge it, they might (but aren't guaranteed) to flag it.
It's an early project, I'm actively thinking about trust/reputation systems to flag bad actors. Curious if you have ideas I could implement!