An untrusted project is no longer just source code waiting to be reviewed. Inside an agentic developer tool, repository configuration, hooks, permissions, MCP servers, and editor integration can all influence execution. Hermes should treat a project directory as an execution surface until trust is established outside the model.
Configuration is active input
Anthropic's Claude Code security documentation describes explicit permission checks, write boundaries, and careful handling of tool execution, and its configuration docs cover permission modes and project configuration. The intended control model is clear enough: an assistant should not gain broad authority just because a repository contains configuration files.
The RAXE advisory on CVE-2026-33068 shows the same risk from the other side. Loading repository settings before a workspace trust decision weakens the consent boundary. That specific vulnerability is Claude Code's, but the pattern applies to any agent that reads project-local configuration before the operator has classified the workspace.
Separate inspection from execution
A first pass over a new repository should run in a constrained mode: no shell execution, no networked tools, no credential access, and no automatic trust of project-provided agent settings.
That scan can still inventory risky files, summarize dependencies, and ask the operator before anything richer is enabled.
The answer is not to ban agentic tools
The productivity gain is real, and OtherU depends on agents for complex systems work.
The workable pattern is layered control: external sandboxing, allowlisted commands, repository trust state, secrets isolation, telemetry, and explicit approval before high-impact actions. A model can recommend actions. The runtime has to enforce boundaries.
Make trust a visible state machine
A new repository can start in read-only review, move to limited command execution after approval, and gain deployment or credential access only through a separate operator decision.
Hermes should persist that trust state and surface it in logs. If a project changes its local agent settings, that is a security-relevant event, not a detail.
Why this bites internal teams too
A repository from a partner, a customer, a benchmark, or a support ticket can look routine and still carry configuration that changes agent behavior.
The standard is simple: no project-provided setting expands authority before an external policy layer has accepted the workspace. That keeps the safety decision in the runtime and with the operator, rather than inside files supplied by the project under review.