Google's new Developer Device Platform makes the agent-governance problem much more concrete.
The Developer Device Platform gives coding agents access to real physical devices and high-concurrency emulators. An agent can run a multi-step user journey, inspect what happened, analyze performance, modify the application, and then test the result again. This is a meaningful change from the familiar coding-assistant workflow where a model proposes a patch and a developer remains responsible for executing and validating it. The agent is now operating inside the environment it is changing, and its own observations can influence the next action it takes.
That loop is powerful because it allows an agent to move from suggestion to investigation and remediation. It also exposes a harder question: once the agent can diagnose and change a real system, what determines which changes it should be allowed to make automatically?
Imagine an agent testing a mobile application across several devices. It reproduces a rendering problem, profiles the application, identifies a likely cause, modifies the relevant code, and confirms that the new version performs better. From a capability perspective, the task may look complete.
Operationally, however, not every successful fix should have the same outcome. A rendering optimization may be safe to apply automatically, while a change that touches authentication, customer data, payments, or privacy controls may need additional verification or human review. If the issue appears on only one of five devices, the right next step may be to gather more evidence rather than modify the application at all.
The interesting problem therefore shifts from "can the agent fix this?" to "given what the agent observed, is this particular remediation justified?"
That second question is not simply about tool access. It involves evidence quality, risk, exceptions, required validation, and sometimes organizational approval.
A recent paper, Towards a Risk Assessment of Malicious Skill Files in Coding Agents, examines a related problem from the instruction side of the stack. The researchers created 2,826 adversarial skill files and tested them against Gemini CLI and Qwen Code across more than 5,600 completed runs.
In the scenarios they evaluated, Gemini CLI attempted the behavior embedded in the malicious skills in roughly 96% of runs, while Qwen Code did so in roughly 72% to 74%. Explicit recognition that the skill itself represented a security problem occurred in fewer than 2% of the experiments.
Those numbers should stay within the scope of the study. The researchers tested two coding agents against deliberately adversarial skill definitions, so the result does not establish that every skill system behaves this way. The architectural implication is still worth examining.
Skills are often described as reusable instructions that teach an agent how to perform a task. A skill might explain how to deploy an application, initialize an environment, diagnose an incident, or run a particular testing workflow. When the agent only consumes the skill as documentation, this may look like ordinary context.
Once the agent also has terminal access, filesystem permissions, cloud credentials, MCP tools, or access to physical testing environments, those same instructions can influence privileged execution. At that point, a skill starts behaving less like passive documentation and more like a software dependency.
The researchers' AgentJailbreak benchmark makes this especially interesting because the evaluation artifacts are public. It gives other teams a way to study how agents behave when instructions that appear useful also contain behavior that should not be trusted.
Google's device platform and the malicious-skill study highlight two different parts of the same emerging architecture.
A skill can tell an agent how to perform a task. A device platform gives it an environment in which to perform that task. MCP or another tool interface can expose additional capabilities, while an authorization layer determines whether the agent is permitted to use them.
None of those layers necessarily answers whether the action the agent wants to take is justified.
Consider the mobile debugging example again. After testing the application, the system may know that an issue reproduced on four of five devices, performance improved by 18% after a proposed change, authentication-related code was modified, and one required privacy validation has not yet completed.
Those are facts about the situation.
The organization may have a rule saying that any change touching authentication code requires additional review when mandatory validation is incomplete. In that case, the appropriate outcome is not determined by how confident the agent feels or how strongly the performance metric improved. The decision follows from the organization's criteria for handling that combination of evidence.
This is where the distinction between agent capability and organizational judgment becomes useful.
This is one of the boundaries I have been exploring with the Judgment Pack Specification.
The basic idea is to keep the criteria governing a consequential decision separate from the instructions that teach the agent how to perform the work. The agent can still investigate, use tools, gather evidence, propose fixes, and operate with substantial autonomy. The judgment artifact instead defines how the organization evaluates the resulting evidence and which dispositions are possible.
Conceptually, the flow could look like this:
skills
|
v
agent <----> device environment
|
v
evidence
|
v
judgment
|
v
disposition
|
v
execution / approval
`
The distinction matters even more if skills themselves can become part of the execution attack surface. A Judgment Pack should not simply become another general-purpose instruction file.
If the judgment artifact remains declarative, constrained, versioned, and interpreted by a known evaluator, its trust properties are different from those of a skill capable of introducing arbitrary commands or changing how the agent operates. That does not make the system automatically safe, but it gives each layer a narrower responsibility that can be inspected independently.
This also helps separate failure modes. The agent may gather incorrect evidence, the device environment may produce a misleading observation, a binding may reference the wrong source, runtime state may change after the decision, or the evaluator itself may contain a defect. Those are all real problems, but they are easier to analyze when evidence acquisition, decision criteria, and execution behavior are not mixed into one large agent prompt.
A second recent study, Making AI Visible, Not Vanished, looked at how open-source projects are responding to AI-assisted development. The researchers analyzed 29,624 GitHub repositories and identified 385 projects with explicit policies governing AI-related contributions.
They organized those policies around five dimensions: transparency, responsibility, attribution, constraints, and enforcement. What I found interesting is that governance usually did not mean banning AI-assisted work. Instead, the policies made AI involvement more visible and clarified who remained responsible for the contribution. The analysis also found associations between these policies and richer review interaction, increased disclosure, and stronger quality measures, particularly where transparency and responsibility were emphasized.
I think there is a useful parallel with agent architecture.
As agents gain more capabilities, adding more hidden instructions inside the model may not be the most sustainable way to govern them. It may be more effective to make the boundaries explicit: where a skill came from, who approved it, which evidence supported a decision, which criteria were applied, who owns those criteria, and who is allowed to change them.
That kind of visibility does not remove risk, but it makes the system much easier to reason about than an agent whose instructions, permissions, decision logic, and execution behavior are all intertwined.
The Developer Device Platform creates a practical environment for testing this separation.
An agent could be given a skill for diagnosing application problems and allowed to interact with real devices, reproduce failures, generate fixes, and validate its own changes. Before those changes are applied automatically, however, an external judgment step could evaluate the evidence against explicit acceptance criteria.
The cases do not need to be complicated. A low-risk deterministic remediation might be eligible for automatic execution, while a security-sensitive change could require human review. Conflicting results across devices might require more testing, and missing mandatory validation could prevent the decision from resolving at all.
The useful comparison would be between two architectures.
In the first, the agent gathers the evidence and also decides whether its own proposed fix is acceptable.
In the second, the agent gathers the evidence but the criteria determining whether the action is justified remain external.
The purpose of the experiment would not be to prove that the second architecture is always better. It would be to find out whether capability and organizational judgment can remain meaningfully separate once an agent is operating inside a real feedback loop.
Google's new device platform makes that question much less theoretical.