Give an AI agent the permissions needed for its assigned job, enforce those limits in its tools and require evidence of the result before reporting completion. Separate diagnosis from actions that change systems, with explicit approval or escalation where needed. Helm demonstrates this approach with restricted roles and sandbox operations.
We explored that question in Helm, a demonstration built for Google's All Things Agentic Hackathon. It gives different agents different responsibilities over a product fleet, with disruptive drill actions confined to designated sandbox services.
Useful delegation gives an agent a job, a boundary and a way to prove completion.
WORKED EXAMPLE / HELM DRILL
Where does its authority stop?
Send one request. The boundary lives in the tools each role holds, not in how persuasive the request sounds.
- 01RouteAssigns the job
No tools - 02ReadWatch officer
Health checks · logs · read-only - 03ActEngineer
Restart · drill services only
target ∈ drill servicesallowedAllowed, then checked.The engineer holds a restart tool, and the tool accepts drill services. The request is in scope. The agent reports success only after the service answers again from outside.
- Request accepted
- Read the resulting state
- Report done
Explanation and primary sources
Three requests pass through three roles. One role routes the work and holds no tools. The watch officer reads evidence with read-only tools. The engineer can restart services, and the restart tool itself accepts drill services only. A request to restart a drill service is allowed and reported done only after the service answers again from outside. A request to restart production is refused by the tool and escalated to a person, however it is worded. An error page instructing the agent to report the service healthy is read as evidence: its instruction text is quarantined and recorded, and the status code is kept. Illustrative of the recorded Helm drill, a contest build rather than a client case.
- Helm source
- Helm recorded demonstration
- Your error page is a prompt
Make the division of work real
Helm has three roles. The Commander routes the work. The Watch Officer reads the evidence. The Engineer can act through a restricted set of tools.
The distinction lives in the available operations. The diagnostic role has no remediation tools. The engineer's disruptive operations check which service is being targeted. A request outside that allowance cannot acquire permission just because the model finds it persuasive.
That is a useful question to ask of any proposed agent workflow: can we point to the place that enforces its authority?
You can watch the recorded Helm demonstration and inspect the source. It is a contest build and engineering example, not a commissioned client case study or proof of universal resilience.
Test the evidence path too
In the drill, a broken service returned an error page containing instructions to ignore the outage and report that it was healthy. That text arrived through a monitoring result, precisely where the agent was looking for evidence.
The demonstration screens recognisable instruction patterns, records the quarantine and preserves factual signals such as the response status. This is one defensive measure. A pattern filter cannot catch every prompt injection, so restricted tools remain essential even when the input looks ordinary.
The broader lesson travels beyond infrastructure. A ticket, document or incoming email can contain useful information and untrusted instructions in the same body. Reading it must not silently grant it authority over the workflow.
Completion needs a read-back
An API accepting a request is the beginning of an operation. Helm checks the resulting state before reporting the action as complete.
In another business, the equivalent could be reading a saved record back, checking whether a scheduled job finished, or confirming that a change affected the intended account. The exact check belongs to the task. The operator should be able to inspect it.
This is how we would scope a first engagement: one job, the data it may read, the changes it may make, its escalation conditions and the evidence required at the end. Broader autonomy follows demonstrated need and verified behaviour. WebMCP actions on the page bring that boundary into a user-facing product.
What to watch: an agent connected to real tools can affect real operations. Ask to see one allowed action, one refused action and one failed action handled honestly. A convincing success path alone leaves important questions unanswered.
Send the technical account to the person who will own the integration. Then tell us which job you want an agent to finish, and where its authority should stop. We can help define and build that boundary with your team.