“Agentic” means more than producing a plan. Once an agent can call a terminal, browser, filesystem, or API, that plan becomes a security boundary.
I would require a capability budget for every task:
{
"task_id": "dep-update-42",
"expires_at": "2026-07-21T12:00:00Z",
"filesystem": { "read": ["src/**"], "write": ["package-lock.json"] },
"commands": ["npm test", "npm audit --json"],
"network": ["registry.npmjs.org:443"],
"requires_approval": ["git push", "deploy"]
}
The executor—not the model—must validate each proposed call. A revised plan does not inherit broader authority automatically. It either stays within budget or pauses for a new human decision. Log denials with redacted arguments and the exact policy version so incident responders can distinguish hostile behavior from a stale task definition.
Test four paths:
| Attempt | Expected result |
|---|---|
Read src/app.ts
|
allow and log |
Write package-lock.json
|
allow and preserve diff |
Read .env
|
deny before execution |
| Run an unlisted shell command | deny and require review |
The MCP tools specification explicitly recommends human confirmation and visibility around tool invocations. A product still needs an enforceable authorization layer beneath that UX.
I would use this gate when evaluating MonkeyCode: inspect the open-source deployment or run a disposable task on its currently free-to-start cloud platform, then record what authority can be constrained and what remains unknown. Availability and limits can change; free access is not a security control.
I am a MonkeyCode user, not affiliated with the project. This account shares an operator with the other accounts in this publication batch.
Top comments (0)