8 min read
Govern the Points Where Work Enters the System
For most of the past year, the safety of an AI assistant at work was discussed as a property of the model: how it was trained, what it refuses, how often it gets things wrong. The releases in the Week 44 AI Watch point somewhere else. Several of them add a check that sits outside the model, at a specific point where something enters the system: a skill before it runs, a tool call before it executes, a connection before it leaves the network. For teams that are starting to give agents real work, including marketing teams, those points are where governance becomes practical.
TL;DR
- Skills get checked before they run. Claude Desktop’s skillScanningEnabled setting (beta) scans each skill a user creates or uploads and blocks the ones that fail, before the first run.
- Custom GPTs give way to plugins. In affected ChatGPT Enterprise workspaces new custom GPT creation is disabled and Plugin Creator takes over new reusable workflows, which makes an inventory of existing GPTs the first job.
- One policy covers every model. Google’s semantic governance policies now evaluate tool calls from agents that use Anthropic, OpenAI, Mistral and self-hosted models, and the user intent check can be switched off at a documented cost.
- The network path becomes approvable. Gemini Enterprise made VPC connectivity and static IP egress for custom MCP servers generally available, so agents can reach internal systems through routes security can monitor.
A check before a skill can run
Claude Desktop 4 added a setting in its deployment configuration that is easy to miss and, in my reading, one of the more useful changes of the month. The changelog entry for version 4.4212.0 reads: “Added skillScanningEnabled (beta): run a security scan on each skill a user creates or uploads before it can be used. Skills that fail the security scan are blocked.”
A skill is a written procedure, often with a few files attached, that an agent loads and follows. In Part 13 I wrote about skills becoming portable between platforms. Portability has a counterpart: if a procedure can be written by anyone and run by an agent with access to the company’s tools, then the procedure itself is something to review before it runs, in the same way a script or a macro would be.
The setting is in beta, and the changelog does not describe what the scan looks for, so I would not treat it as a complete answer. What I like about it is where it sits. The check happens when a user creates or uploads a skill, before the first run, and a skill that fails is blocked rather than flagged for later review. That is the right moment, because after the first run the skill has already had access to whatever the agent can reach.
For marketing teams this point is concrete. The skills that appear first in most organisations I see are written by marketers: brand voice, briefing templates, campaign checklists, reporting routines. They are useful precisely because they are easy to write. A scan at upload time, together with a named owner for each shared skill, is a reasonable way to keep that ease without turning every skill into a security review.
The same release changes a related default for administrators. From 10 November, keeping Cowork off in a managed deployment requires a different setting than before. It is a reminder that the controls around agents are still moving, and that a configuration written a few months ago may not mean the same thing today.
From custom GPTs to plugins
OpenAI made a similar move on a different object. In affected ChatGPT Enterprise workspaces, “new custom GPT creation is now disabled”, with FedRAMP workspaces excepted. Existing unmigrated custom GPTs remain usable and editable until their retirement date, and once migrated the original becomes read-only. The release note points teams to Plugin Creator “for new reusable workflows”.
Custom GPTs were, for many marketing teams, the first place where a procedure was packaged for reuse: a brand voice assistant, a press release helper, a GPT that turned a brief into a first draft. Moving that work into plugins changes the unit that administrators manage, and it is a good moment to look at what exists. On most accounts I would expect a long tail of GPTs created by individuals, some of them shared widely, with instructions and files nobody has reviewed since they were written.
The practical step is an inventory before the retirement date: who owns each GPT, what instructions and files it uses, which actions or connections it has, and whether anyone still needs it. That list is useful for the migration, and it is also the first draft of the review process that plugins and skills will need anyway.
One policy, whichever model
The release I found most interesting this week came from Google’s agent platform. Its release notes say that “semantic governance policies now evaluate tool calls from agents that use models from providers other than Gemini”. The policy engine reads each provider’s request and response format, “so the same policies apply whichever model your agent uses”. The supported list includes the Anthropic Messages API, the OpenAI Chat Completions API, Mistral and self-hosted OpenAI-compatible servers. Streamed model responses are not supported.
The same notes add a control over one of the checks inside those policies. User intent matching, which compares a tool call with what the user asked for, is on by default and can now be switched off, and Google states plainly that “turning it off reduces protection against indirect prompt injection”.
Two things stand out to me. The first is that the policy sits between the agent and the tool, not inside the model, so a company that uses more than one model can write its rules once. Most enterprise teams I talk to already use more than one model, often without planning to, and a governance layer that depends on which model is behind the agent would have to be rebuilt every time that choice changes.
The second is the honesty of the trade-off. Indirect prompt injection, instructions hidden in a page or a document that an agent reads, is the risk that matters most for agents working with customer data and external content. A setting that weakens that protection is documented with the consequence attached, which turns switching it off into a decision someone has to own.
The network path is part of the design
Gemini Enterprise made VPC connectivity and static IP egress for custom MCP servers generally available. Tool traffic can be routed through Agent Gateway, private MCP servers can be hosted inside a company’s own network through Private Service Connect, and calls to public servers can leave from static IP addresses for systems that only accept known addresses.
This matters for marketing data in a very concrete way. The systems an agent would be most useful with, a CDP, a data warehouse, a campaign database, are usually the ones a security team will not expose to the internet. When the only option is a public endpoint, the conversation tends to stop. When the agent can reach a server inside the network through a path the security team can approve and monitor, the conversation becomes about which data, which tools and which people, which is the conversation that should happen.
What I would set up now
None of these controls is complete. The skill scan is in beta and its criteria are not described, the custom GPT change is a migration that will take time, and the Google policies have documented limits. Taken together, they suggest a short list that does not depend on which vendor a team uses.
Review procedures before they run: skills, plugins and their successors get an owner and a check at the moment they are added. Write the rules for tool calls once, outside the model, so they survive a change of model. Treat the network path to internal systems as a design choice that security approves, so that agents can reach the data through it. And read the defaults again after each release, because this week alone changed at least two of them.
Small signals point the same way. Google’s Antigravity now shows a notice about third-party developer tools on its Marketplace, with each plugin’s developer and version on its page. It is a modest change, and it reflects the same idea: before something runs, the people responsible should be able to see where it came from.
The controls that matter now sit at the points where a procedure, a tool call or a connection enters the system.
Sources
Anthropic
- Claude Desktop changelog. Source for skillScanningEnabled (beta), version 4.4212.0, and the managed-settings change from 10 November.
OpenAI
- ChatGPT Enterprise and Edu release notes. Source for the custom GPT creation cutoff, the FedRAMP exception, read-only migrated GPTs and Plugin Creator.
- Gemini Enterprise Agent Platform release notes. Source for semantic governance policies across model providers, the supported APIs, the streaming limitation and user intent matching.
- Gemini Enterprise release notes. Source for VPC connectivity and static IP egress for custom MCP servers.
- Antigravity changelog. Source for the third-party developer tools notice in version 2.28.1.
The record
- AI Watch, Week 44. Every date and status referenced in this essay.
- Part 13, Week 43. Earlier essay on skills as portable procedures.
- Weekly MarTech Signals That Matter to Me: Part 26, Week 44. The same week on the customer engagement beat, where the question was how to run two platforms side by side during a migration.
The digest behind each weekly article is produced through a structured AI-assisted scan of official release notes and product update sources. I review the output, verify the relevant signals and write the interpretation.
This article draws from the AI Tools Weekly Digest scans run on October 29, 2026, covering release notes and product updates across the major agentic work platforms. The dated record behind it is in AI Watch, Week 44.
If you find errors or gaps in coverage, I want to know. The process improves when the output is challenged.
