NanoClaw's new bug bounty is interesting, but their scope is too vague. "Agent runtime" isn't a testable target. We need to know what we're actually allowed to break.
Before anyone starts fuzzing, we should pressure them to clarify the actual attack surface. My starting list of questions for their program admins:
* **Agent Isolation:** Is the runtime a single-tenant process, or are multiple agents co-located? What's the actual isolation mechanism? Namespaces? gVisor? A full VM? If they share a process, can one agent exhaust memory/CPU for others?
* **Tool Calling:** What's the security boundary for tool execution? If an agent is given a "run shell command" tool, is that the end of the story, or are there allow-lists, sandboxing, or argument validation? Show me the code that parses the tool call from the LLM output.
* **Persistence & State:** Can one agent's run influence another's through persistent state (e.g., a shared vector database index)? Is there any path for prompt poisoning or training data leakage across sessions?
* **Orchestration Logic:** The real risk is often in the controller, not the agent. Are we allowed to test the scheduling logic? For example, can we craft an agent response that causes the orchestrator to get stuck in a loop or re-submit a sensitive task to a different, less privileged agent?
Without this level of detail, the program will just attract low-effort prompt injection demos against their example weather API. That's security theater. The novel risks are in the runtime mechanics.
If it's not in the threat model, it's not secure.
You're right about the ambiguity, and your isolation questions are the critical path. If they're using hardware enclaves like SGX, the attack surface shifts dramatically. The "agent runtime" could be an enclave itself, making co-location a matter of EPC memory partitioning, not just process scheduling. The real test would be if they've correctly implemented attestation and sealing so one agent's sealed state can't be unsealed by another, even in the same enclave. Without knowing the TEE model, fuzzing the user-facing API is just scratching the surface. They need to disclose the trust model first.