The New AI Governance Test: Can You Stop an Agent Mid-Task?
Microsoft's latest Responsible AI Transparency Report makes the important shift from policy to operational control. Enterprise teams should treat it as a practical test: can they see, constrain, and stop AI agents while work is happening?
Last week, Microsoft published its 2026 Responsible AI Transparency Report. The headline is not another list of principles. It is the acknowledgement that capable AI systems now retain memory, use tools, access data, and take actions on behalf of people. That changes what good governance looks like.
A policy that approves an AI application before launch is still useful. But it is no longer enough. When an agent can decide which tool to call next, retrieve a new data source, or trigger a workflow after approval, risk is created at runtime. The key governance question is therefore much more concrete: can the organisation see and stop the agent before a bad action becomes an incident?
That question should be familiar to security leaders. We do not accept a production service as secure because someone reviewed its design six months ago. We require identity controls, least privilege, logging, detection, and a way to contain it when behaviour changes. AI agents deserve the same operating discipline.
Why pre-deployment approval is not enough
Traditional AI governance often begins with intake forms, risk tiers, and a one-off review. Those mechanisms identify obviously unsuitable use cases and create accountability. Keep them. The failure is treating approval as a permanent safety certificate.
An agentic system does not behave like a static model behind a chat box. Its effective capability is a combination of model, instructions, memory, connected tools, data permissions, user identity, and the conditions it encounters. Change any one of those pieces and the system's risk profile can change without a new model release.
A procurement agent may begin by assembling supplier comparisons. Later, a connector lets it read contract folders and a workflow gives it the ability to create purchase requests. Combined, those ordinary changes turn an assistant into an actor with access to sensitive information and authority to commit the business.
An application inventory alone is incomplete. Enterprises need a live view of what each agent can access, which identities it uses, what actions it can take, and which controls apply. That is the difference between knowing an agent exists and governing its real-world behaviour.
Build controls around the action, not just the model
Microsoft's report highlights the direction of travel: agent identities, tool permissions, continuous evaluation, and monitoring of actions. That is a more useful frame than debating whether a model is "approved."
For each production agent, define a small set of action boundaries:
- **Identity:** Give the agent a distinct, attributable identity. Do not let it borrow a human administrator account or hide behind a shared API key.
- **Tool permissions:** Grant only the tools and scopes needed for the stated job. Read access, draft creation, and final submission are different privileges.
- **Data boundaries:** Specify which repositories, classifications, and tenants an agent may use. Retrieval should not quietly become broad enterprise search.
- **Approval points:** Require a human decision for consequential actions such as sending external communications, changing records, approving payments, or exporting sensitive data.
- **Runtime evidence:** Record the prompt or trigger, the tool call, the relevant identity, the data source, the result, and whether a policy allowed it.
- **Kill and contain:** Make it possible to revoke a tool token, disable an integration, or pause a workflow quickly without waiting for a software release.
The goal is not to make agents useless. It is to make their authority legible and reversible. An agent that can prepare a customer response but cannot send it without approval can still save meaningful time. More importantly, its control design is intelligible to the people who will own the incident if something goes wrong.
Shadow AI is where runtime governance gets tested first
The hardest part is not usually the polished agent a central platform team built. It is the business-unit workflow assembled from a browser extension, a SaaS automation tool, a personal API key, and a shared drive. It may have no register entry, named owner, or trail from request to action.
That is the practical form of Shadow AI: usage outside the controls the organisation believes it has. As tools become easier to connect, Shadow AI becomes Shadow Automation. The risk is not only data leaving the company, but an unreviewed system changing something inside it.
Start with discovery before imposing a blanket ban. Security and governance teams should be able to answer four questions across the environment:
1. Which AI services and agents are actually in use? 2. Which ones have access to enterprise data or business systems? 3. What identities, credentials, and tool scopes are attached to them? 4. Where is there no owner, no approval path, or no runtime record?
The answers give you a prioritised remediation list. An unapproved chatbot with no enterprise data access is not the same problem as an unowned workflow that can read HR documents and modify CRM records. Treating them identically wastes trust and security capacity.
A 30-day operating plan
Security leaders do not need to redesign the entire AI program this quarter. They need to establish a minimum control loop that gets stronger as adoption grows.
Week 1: map the active estate. Combine SaaS discovery, identity telemetry, procurement records, and interviews. Find the agents, integrations, and automation platforms already doing work.
Week 2: rank action paths. Prioritise the highest-risk combinations of sensitive data and action authority: agents that can send, change, approve, export, or invoke privileged tools.
Week 3: add guardrails. Create separate identities, narrow scopes, add approval gates, centralise logs, and test that the emergency disable path works.
Week 4: exercise the loop. Simulate an agent using an unapproved connector or performing an out-of-policy action. Can the SOC see it, explain it, and stop it in minutes?
That final exercise matters more than a polished policy document. It turns governance into an observable operating capability.
Governance that earns adoption
The business will keep adopting agents because the efficiency case is real. Governance wins when it enables that work safely rather than arriving only as a rejection queue. Teams need a clear path to get an agent approved, a secure default pattern for identities and integrations, and fast help when their intended use falls outside the pattern.
The bar has changed. A mature AI program is not one that can produce a register of approved models. It is one that can explain what every important agent is doing now, what it is allowed to do next, and how to intervene if the answer changes.
Aona helps enterprises discover AI usage across their environment, surface the Shadow AI that conventional inventories miss, and turn that visibility into actionable governance. If your team cannot yet answer who is using AI, what data it can reach, and which actions it can take, start by mapping your AI exposure with Aona and make runtime control the next milestone.
