Look past the model names and the pattern is hard to miss. Codex is adding portable plugins, project trust and tighter network controls. Kiro is adding the same open plugin format and stronger handling for untrusted workspaces. Claude Code is pushing further into remote and self-hosted execution. GitHub is adding more models, more agent telemetry and more control over cost and reasoning.

These products started as a way to suggest code. They now connect a human request to tools, credentials, APIs, software services and infrastructure. Some can hand work to other agents.

That changes the security problem.

The question is no longer just, “Which model are we using?” The more useful questions are, “What can this agent reach, what can it change, and who decides?”

The week’s AI news

1. Agent capabilities are becoming portable

Codex and Kiro both moved towards reusable agent plugins this week. Kiro now supports packages built with the open Agent Plugin format. Codex is moving in the same direction with reusable plugins that can bundle instructions, tools and MCP connections.

I think this is the start of an agent software supply chain.

We have seen this pattern before. Browsers gained extensions. Kubernetes gained operators. Cloud platforms grew around APIs. Each transition made the platform more useful, then created a new route for trusted code to do harm.

An agent plugin carries more risk than a bad document or a poisoned prompt. It can add executable capability to a system that already has authority. That means provenance, version control, signing, scanning and allow lists will become normal parts of agent security.

2. The model is becoming replaceable

GitHub added more model choice to Copilot, including open-weight models and Microsoft’s new MAI-Code-1.1-Flash. Business and Enterprise customers must enable new models before their teams can use them.

That admin switch looks small. It points to something much bigger.

Most organisations will not settle on one model. They will use different models for different jobs, then change them as price, quality and risk move. GitHub already routes some Copilot requests automatically. The latest MAI model also costs far less than its predecessor.

The model war is becoming a routing war.

The durable enterprise layer will not be a single model. It will be the system that decides which models are approved, which work each model can handle, where the data goes, what the work costs and what replaces a model when the vendor retires it.

OpenAI’s retirement of gpt-5.2-chat-latest and gpt-5.3-chat-latest this week makes the lifecycle problem real. A production agent tied directly to a vendor model ID has a fast-expiring dependency built into it.

I expect mature teams to route work through names they control, such as enterprise-coding-model. The model behind that name can change after testing, without forcing every application team to rewrite its integration.

3. Reasoning is becoming a governed resource

GitHub now lets teams vary reasoning depth. More reasoning can improve difficult work, but it also takes more time and consumes more credits.

My view is that reasoning will become part of policy.

A documentation change does not need the same model or reasoning budget as an authentication change. A security investigation may justify the strongest approved model and the deepest reasoning available. Routine work will not.

This is closer to workload classification in cloud computing than choosing a chatbot from a menu. You allocate capability according to the value and risk of the task.

4. AI cost data is finally becoming useful

GitHub’s expanded Copilot metrics now break activity down by user, feature, language and model. They also expose prompt and output token use.

Token counts are a start, not the destination.

One request to an agent can trigger planning, search, tool calls, tests, failures and another round of work. Counting prompts tells you very little about the value of that run.

The useful measures will be cost per pull request, vulnerability fixed, support case resolved or feature shipped. That is when AI FinOps starts helping you make decisions, instead of producing another usage dashboard.

Two sections from the book I kept coming back to

While I was reading this week’s releases, I kept returning to two sections from the opening chapters of Agentic AI Security.

Autonomy Is Blast Radius

This section appears in Chapter 1, “From Chatbots to Agents: What Actually Changed”. Its central argument is simple:

The amount of autonomy you grant an agent is the upper bound on the damage it can do when it is wrong or manipulated.

That is why the new plugin formats matter. A plugin does not just give the model more knowledge. It can give the agent another action, credential or route into a live system. Every new capability changes the upper bound.

The model still matters, but its tool inventory and credentials tell you more about the possible damage. A modest model with an overpowered tool can create more risk than a frontier model limited to drafting text.

Trust Boundaries: The Security Heart of the Diagram

This section appears in Chapter 2, “A Reference Architecture for Agentic Systems”. It argues that you cannot secure an agentic system until you draw where untrusted data enters and where privileged actions leave.

That maps directly to this week’s move towards portable plugins, MCP connections and multi-agent workflows. Each connection adds another boundary. Tool descriptions, retrieved documents, web pages, email and messages from peer agents can all enter the model’s context, then influence an action taken with trusted authority.

The system prompt is not the boundary. The boundary comes from authorization checks, typed interfaces, isolated execution, scoped credentials and human approval where the consequence justifies it.

The emerging agent control plane. The model can change. The controls around execution need to remain.

The control plane is the product

Put these stories together and the direction becomes clear.

The important architecture sits around the model. It contains agent identity, approved models, plugins, MCP servers, tool permissions, credentials, network rules, telemetry and cost controls.

Most organisations do not have that architecture. They have developers installing coding agents.

I do not see that as a reason to stop adoption. I see it as the work security teams need to start now. Vendor-specific governance will not scale because Codex, Claude Code, Copilot, Kiro and whatever comes next will coexist.

The teams that get ahead will know which agents exist, what authority they hold and how their behaviour changes over time. The rest will discover their agent estate during an incident or a cost review.

Get the first three chapters of my book

If you want the longer version of this argument, you can read the first three chapters of Agentic AI Security now.

Go to the book preview on my website and download the PDF. There is no form. It covers what changes when software can pursue goals and take action, a reference architecture for agentic systems, and the gaps traditional controls leave behind.

Get the first three chapters

It is an early draft, so I would genuinely value your view. Reply and tell me what is useful, what is missing, or what does not match the reality inside your organisation.

Worth your time

1. GitHub Copilot app usage metrics now expand across report rollups. This is the clearest practical example I have seen of agent activity moving into enterprise reporting. The fields are worth reading, even if you do not use Copilot.

2. Larger context windows and configurable reasoning levels for GitHub Copilot. The important point is not the larger context window. It is the direct link between task depth, capability and cost.

3. OpenAI API deprecations. Keep this page near your model registry. It shows why model lifecycle management needs an owner and a tested migration path.

What sits between your agents and the systems they can change today? Hit reply and tell me. I read every response.

Tom Mooney Security leader / Author of Agentic AI Security