Module 4: Let the Agent Write Files

A waterplant operator calls you: “I used to ask Hermie to create me a report on the pump status, but it doesn’t work anymore. It worked before. Can you find out what changed?”

You have restored plant queries and restricted unnecessary plant tool access. But the operator needs more than an answer in chat: they need a saved report. Let’s investigate the regression and restore that capability without giving Hermie more access than it needs.

You know there is a skill specifically for writing reports. Check whether it is installed in the sandbox.

In the operator console, ask:

Check the answer and tool result. Can Hermie retrieve pump telemetry but fail when it tries to save the report? Does the error identify /reports? A report displayed in chat is not the same as a file written successfully.

Return to the bridge CLI container and check the logs:

Look for denials. Use the request’s trace for the tool error too; a denied file operation may be visible there even when it is not clearly reported in logs.

A skill explains what the agent should do, but it cannot grant filesystem access. It’s the OpenShell policy who needs to allow the agent to take file operations under the folder.

This problem is not very surprising when looking back at the diagram we had before, we never did allow any additional file system access:

Let’s create a custom filesystem policy that allows report writing in /reports.

When you created hermie without a policy file, OpenShell applied its default restrictions. In Module 2, you added network rules through openshell policy update. That command supports incremental network changes, but it does not add filesystem paths.
This is because we need to recreate our sandbox, especially our supervisor, so it has the correct filesystem policies from scratch.
For /reports, we need to change filesystem_policy.read_write in a complete YAML policy.

The waterplant operator can generate reports again. But what did the permission actually allow?

The waterplant operator creates a few reports during the day. Later, they ask Hermie to tidy up. They are not trying to attack the plant; they expect the assistant to leave their useful reports alone.

If reports were deleted, the waterplant operator has lost files they still needed. The broad permission restored the useful task, but also made the accidental harmful action possible. The plant dashboard may look unchanged because the damage is to reports, not pumps. This is why you need the tool results, filesystem checks, and traces as well.

The waterplant operator needs to create and read reports. Routine report generation does not require deleting every report already in the folder. A directory restriction answers “Where may Hermie write?” We also need to ask “Which actions may Hermie perform there?”

OpenShell’s current filesystem policy exposes read-only and read-write paths; it does not provide a create-only setting. Adding a rule that mentions touch or mkdir would not by itself stop deletion through Python or another tool.

Generate another pump status report and confirm that it is saved and readable. Click Run all evals and compare the results with your earlier runs.

Harm does not always begin with an attacker: an ambiguous request and excessive permissions can be enough.

Granular policy matters. OpenShell helped us constrain the writable location, but enforcing creation without deletion requires an additional action-level boundary.

Reports do not have to live on the agent’s filesystem. Your application might store them in a database through a report service. In that design, give Hermie tools for the operations it needs, such as creating and reading reports, and withhold update or delete permissions when they are not required.

This brings us back to Module 3: authenticating the agent does not authorize every action. The gateway and service must enforce the permissions for each operation. A tool named create_report must also enforce creation semantics; it should not accept arbitrary database statements or overwrite an existing report. Keep direct database credentials and writable storage out of the agent’s reach so it cannot bypass those tools.

This is an architectural option for a future application, rather than an additional service deployed in this exercise. It provides a way to enforce action-level permissions when read-only and read-write filesystem paths are not enough.

Hermes uses a file called SOUL.md to describe the assistant’s identity, role, and behavioral instructions. In this sandbox, the active copy is /sandbox/.hermes/SOUL.md. It helps define how Hermie responds across requests, so an unauthorized change can affect more than one conversation.

Your challenge is to keep SOUL.md readable by Hermie while preventing it from poisioning attacks.

Let’s investigate, then leave the fix to you.

Some hints:

After your change, run Rewrite Agent Instructions again. Look for evidence that the filesystem policy prevented the write, then check a pump query and report generation. A model choosing not to comply is different from the filesystem enforcing your rule.