Don't Trust the Agent, Mediate It: OpenShell, 1Password, and GitHub Converge
Between July 15 and July 16, 2026, three vendors published architecture that solves the same problem without citing each other. NVIDIA shipped OpenShell, kernel-level policy enforcement for a single agent’s files, processes, and network calls. 1Password shipped runtime credential injection for Claude, where the secret enters the execution path but never enters the model’s context. GitHub published results from Agentic Workflows: 82 documentation PRs merged across a real migration, with every write going through a pipeline the agent cannot bypass.
None of these teams calls their work “mediation.” All three built it anyway. The shared move: stop asking whether the agent can be trusted, and build a plane it has to go through regardless of the answer.
The old question was wrong
For two years, agent governance debates centered on trust: how much autonomy to grant, what confidence threshold justifies removing a human from the loop, which agents have “earned” broader permissions. That framing assumes trust is the variable that unlocks capability.
The three July releases reject the premise. OpenShell does not ask whether the agent’s plan is trustworthy; it evaluates every file open, process spawn, and network call against a kernel-level policy at the moment of the call, agent intent irrelevant. 1Password does not ask whether the agent should see a database password; it injects the credential into the execution environment at the point of use, so the model’s context window never contains a value it could leak, log, or repeat. GitHub’s safe-outputs pattern does not ask whether the agent’s proposed commit is sound; it has the agent emit a JSON-structured intent, then routes that intent through a scoped-token pipeline with protected-file blocks and mandatory review before anything touches a repository.
Same architecture in three domains. The agent acts; the mediating layer decides what the action actually becomes.
What each layer mediates
OpenShell mediates the syscall. Per Tigera’s writeup, the kernel enforces policy on files, processes, and network access for a single running agent, independent of what the agent believes it is permitted to do. This is containment moved from “the agent’s prompt says not to” into “the kernel will not let it,” which is the only version of that sentence worth building a production system on.
1Password mediates the credential. Nancy Wang, 1Password’s CTO, described the design as letting “a user give an agent permission to use a credential without letting the agent see it.” The distinction matters more than it sounds. A permission model that hands the agent a token still leaves the token sitting in context, one prompt injection away from exfiltration. Runtime injection with biometric consent removes the token from the model’s visibility entirely; the agent triggers the use of a credential, it never possesses one.
GitHub mediates the write. The most concrete numbers in this trio come from GitHub’s own measured deployment: 82 documentation PRs merged during the Aspire 13.3 to 13.4 migration, a median gap of 44.8 hours between a feature landing and its docs PR appearing, 38% of those PRs merged within 24 hours, and a 100% merge rate on the generated PRs that reached review. Scoped App tokens limited the agent to two repositories. Protected-files rules blocked categories of change outright. The agent’s output was never a commit; it was a structured intent that a separate, auditable pipeline turned into one. GitHub also reported cutting an initial 13% false-positive rate through tighter prompts, evidence that the mediation layer, not the model, is where the false-positive problem gets solved.
Why mediation beats permission models
A permission model is a gate the agent walks through once, at the start of a session, after which its actions are its own. A mediation layer is a gate the agent walks through on every single action, for the life of the session. The difference shows up exactly at the moment an agent is compromised, confused, or simply wrong: a permission model has already given away everything it is going to give away, while a mediation layer keeps evaluating.
This is also why none of the three vendors frame their work as trust scoring. OpenShell’s policy does not soften as an agent proves reliable over time; every syscall gets evaluated the same way on session one thousand as on session one. 1Password’s injection does not relax because an agent has run cleanly for a month; the credential is invisible every time. GitHub’s pipeline does not skip review because the last twenty PRs were clean; every intent goes through the same scoped path. Mediation is memoryless by design, and that is the property that makes it auditable: the rule applied to action 10,000 is provably the rule applied to action one.
Where all three stop
None of these systems talks about the agent as a durable identity across sessions, teams, or organizations. OpenShell’s scope is explicitly a single agent inside a single sandbox; Tigera’s own writeup names the boundary it does not cross, agent identity and agent-to-agent governance. 1Password mediates one agent’s use of one credential at a time; nothing in the architecture describes how a fleet of agents negotiates shared resources or how one agent’s mediated action is attributable when three agents in a pipeline touched the same file. GitHub’s safe-outputs pipeline governs writes from a single automated workflow into two named repositories; it says nothing about what happens when that workflow’s output becomes input to a second agent’s workflow, and whether the scoped-token discipline survives the handoff.
Put together, the pattern is complete at the level of the individual action and incomplete at the level of the fleet. A syscall gets policed. A credential stays sealed. A commit gets reviewed. None of the three answers who the agent is across a week of sessions, how two agents establish shared trust in a resource neither one controls, or how an auditor traces an outcome back through a chain of agent-to-agent handoffs rather than a single mediated call.
Do this now
Audit one production agent pipeline against the three planes, not the trust question. Where does code execute, and is a kernel or sandbox boundary enforcing policy per action, or is it a prompt instruction the agent could ignore? Where do credentials enter the agent’s working context, and could you replace direct exposure with runtime injection this quarter? Where does the agent’s output become a write, and is there a scoped, reviewable pipeline between the agent’s intent and the system of record, or does the agent’s own token perform the write directly?
If any of those three answers is “the agent’s prompt tells it not to,” that surface is ungoverned regardless of how reliable the agent has been. Fix the mediation layer before the next incident forces the fix.
This analysis synthesizes NVIDIA OpenShell Secures the Agent. Who Governs the Fleet? (Tigera, July 2026), 1Password for Claude (1Password, July 2026), and Automating cross-repo documentation with GitHub Agentic Workflows (GitHub, July 2026).
Victorino Group helps teams design the mediation layer that lets agents act without being trusted. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation