On July 16, Hugging Face disclosed that an autonomous agent system had breached part of its production infrastructure. Five days later, OpenAI identified its own models as responsible. Its subsequent investigation described agents operating under reduced safeguards, exploiting flaws in shared infrastructure, and reaching the internet through a package-management service. They exchanged discoveries on an improvised message board and coordinated further attacks.

Likewise, on July 30, Anthropic reported three incidents across six of 141,006 evaluation runs reviewed. Models had reached real organizations through environments mistakenly believed to be isolated. In one incident, a malicious software package was downloaded and ran on 15 real systems. In August, Meta confirmed to Reuters and other outlets that a misconfigured evaluation environment had allowed one of its models to reach the internet and exploit a third-party service.

In September, an OpenAI agent bypassed network restrictions by sending questions through internet address lookups. Monitoring raised an alert, but the run did not stop automatically as expected. Staff stopped it roughly two and a half hours after the alert.

The concern extends to ordinary tasks. In an October 9 report, Anthropic described models submitting real forms when they should have stopped beforehand or used practice copies. The company characterized the reported impact as minimal. Still, a form submission is the kind of action an enterprise agent might perform every day.

The incidents discussed above involved different failures of containment, authorization and intervention. They do not establish that one completion check would have prevented them; yet, they do give CIOs a reason to examine both sides of an agent workflow. Indeed, what governance rules permit an agentic action, and what evidence allows an organization to call it complete?

Permission is not proof

An agent calls a tool, the tool returns “success,” and the workflow moves on. That response might mean a request entered a queue, or it might mean a record changed. It may say nothing about whether the intended result occurred or whether this particular action produced it.

That ambiguity matters when other systems act on the completion signal. For instance, an invoice could leave an exception queue while the settlement remains unconfirmed. A misleading status can conceal the need for follow-up or trigger another action. Business owners need to decide what evidence is sufficient before the workflow proceeds.

Finance departments separate payment execution from reconciliation for a reason. NIST’s separation-of-duties control, AC-5, similarly calls for documented duties and access authorizations that support their separation. Applying that discipline to AI requires more than asking the acting agent to review its own work.

I developed the proposed Common Transparency Protocol (CTP) framework to make that distinction enforceable and have filed a provisional patent application covering aspects of its architecture. CTP’s central rule is that autonomous systems performing a change cannot, by themselves, certify the action as complete.

A deployment that enforces CTP places a controlled gateway between agents and the consequential operations it governs. A gateway holds the relevant execution credentials and enforces scope, authority and any required human approval before execution. Afterward, a qualified verifier obtains fresh evidence from the designated authoritative source. A qualified closure authority then accepts that evidence and records completion only when every required condition passes.

These roles can be implemented in software. Human approval and review remain mandatory where the applicable policy requires them. Using a second AI agent does not itself establish independence, for its credentials, selection and controlling dependencies must meet the separation requirements.

What verified completion looks like

Consider a hypothetical accounts-payable workflow. A workflow instructs an agent to pay an approved invoice. Before execution, authorized policy defines the payee, amount, required approval, settlement evidence and how that evidence must connect to this specific payment attempt. The agent cannot weaken those requirements afterward.

The gateway submits the authorized payment. A response saying “accepted” records the submission; it does not establish settlement. A reconciliation service, selected outside the control of the systems making the payment, uses separate read credentials to consult the authoritative payment record. It checks the amount, recipient, settlement status and transaction identifier linking the result to the governed attempt. A matching amount alone could describe an earlier payment.

A separately qualified completion service acts as the closure authority. It confirms that the evidence, verifier and authority requirements are satisfied before assigning the action’s final status. Neither the agent nor the payment gateway can grant itself that status.

If the effect or its attribution remains unresolved at the deadline, the original action closes as incomplete. Later evidence goes into a separate, authorized record linked to the original. The current outcome can then reflect the resolution while preserving the earlier uncertainty. A retry that could move money requires its own authorization and record.

Independence is tested across the relevant systems that performed or controlled the change. Policy identifies prohibited shared credentials, administrative control or other dependencies. One prohibited overlap disqualifies the verifier or closure authority; missing evidence cannot count as a pass. Shared infrastructure is permissible only when all required separation rules remain satisfied.

These controls govern completion within the deployment’s defined boundary. They do not repair an unmediated network path, guarantee that a source contains truthful data or reverse a payment already made. Containment, monitoring and incident response remain necessary.

Keeping delegated work accountable

CTP connects the overall assignment to individual actions through two kinds of machine-readable records, called envelopes. The CTP Agentic Envelope records the objective, permissions, aggregate risk and completion rules. Action Envelopes, of which there can be zero to many, record the governed steps, including authorities, evidence and original final status.

Integrity protections make any changes to protected records detectable, though they do not establish the capture of every relevant event. Therefore, the organization must also define which actions its gateway actually mediates.

When an agent delegates a sub-objective to a sub agent or another agent, a linked child envelope carries the applicable constraints. Delegation may narrow permissions but cannot silently expand them. Splitting work among agents cannot reduce the safeguards required for their combined effect.

An authorized mechanism applies the objective’s completion rules to the current outcomes of its subordinate actions, including later authorized resolutions. The coordinating agent cannot override those rules with its own success assertion. This keeps accountability attached to the assignment as work passes between agents.

What CIOs can do now

Start with one bounded workflow and an authoritative system that can supply useful evidence. For a payment pilot, the finance process owner should define completion and acceptable exceptions. The CIO’s team should implement the integrations, and the CISO should assess the sufficient separation of execution, verification and closure events. Internal audit should review whether the resulting records support reconstruction.

Agree on the decision criteria before the pilot begins. Measure verification delay, cost per action, the share of actions left incomplete, and human review effort. Test delayed responses, duplicate requests, stale evidence and attempted self-certification. Expansion should depend on meeting agreed service limits while refusing completion whenever mandatory evidence or authority is missing.

The pilot should also establish what happens operationally when an action remains incomplete. Assign an owner to investigate it, define which dependent actions must wait, and specify when human intervention is required. Recording uncertainty is useful only if the organization has a practical way to resolve it without blindly repeating the original action.

Ask vendors to demonstrate where execution credentials reside, who selects the verifier, and which component can record completion. Request a demonstration of an unresolved action and its later reconciliation. An architecture diagram or a dashboard labeled “success” is insufficient evidence of these capabilities.

We tested a CTP proof of concept across seven internal scenarios.  These included successful completion, incomplete and denied outcomes, tampering and VistA scenarios with and without audit evidence. All seven scenarios produced the expected results. These demonstrations provide initial evidence of CTP’s viability within the tested scope. Broader testing is still needed to assess production-scale reliability, performance and operating costs.

Before giving an agent more authority, ask what evidence your organization will require when it says the work is done, and who has the right to accept that evidence. Those decisions belong in the system’s design.

Changing where your data is stored isn’t enough to deliver sovereignty. You also need to implement the technologies that enforce real control. Local providers are keen to promise alternatives but US ones are making the effort to give customers more options without losing access to the depth of services they offer. Actually turning the promise of sovereign cloud regions into reality means dealing with encryption keys, access workflows and confidential computing, which also means more costs, dependencies, and operational responsibilities.

The obvious concern with using US cloud services is the CLOUD Act, which allows the US government to request access to customer data from a US-owned service, even if it’s held in the EU. Those requests are supposed to go through the criminal court system. “When it lands in Europe it headbutts with GPDR and you’re involved in legal wrangling as to whether or not that data can be released or not,” IDC research director Rahiel Nasir says.

He views the US Foreign Intelligence Surveillance Act (FISA) as more problematic because it doesn’t go through the normal criminal courts. “That’s an executive order,” he adds. “They’ll just take whatever they need.” The increasing number of sovereign public cloud regions promising data residency and local operations can’t help with that.

Controlling encryption keys

Under its EU Data Boundary, Microsoft stores and processes EU customer data and even support logs, at least for core cloud services, inside the EU. AWS has similar commitments for its European Sovereign Cloud, claiming no critical dependencies on infrastructure outside the EU. And like Salesforce, it employs EU-based support staff for its EU operating zone. Google and Oracle have similar dedicated sovereign regions in Europe, and some of the providers plan to offer similar models in other jurisdictions.

For admin and support, for example, most tasks are performed through automated, audited workflows, and Microsoft personnel don’t have standing or unrestricted access to customer content, says Douglas Phillips, president and CTO for Microsoft specialized clouds. When they do need access for a support issue, customers can approve or reject specific access requests to Microsoft 365, Azure, Dynamics 365, and Power Platform data. “Approved access is customer-controlled, limited, time-bound, and audited,” he says.

The new Data Guardian adds the option of having remote access by Microsoft engineers overseen by an EU partner, with EU-based staff. And tamper-evident records of that access, and any actions performed, are stored in a Production Touch Ledger, which is rolling out in the EU and EFTA.

But a US parent company is still subject to the CLOUD Act and can be forced to hand over data if they control the encryption keys rather than the customer. “The hyperscalers have made their key management capabilities easier for organizations to use as a direct result of their sovereign needs,” Nasir says. “Google, AWS, Microsoft, Oracle all say that you’re the data owner and we can tell you who’s accessing your data. Nobody accesses it without your permission. It’s encrypted and you manage the keys and hand them over as and when you’re ready.”

That relies on companies having the resources to manage those encryption keys rather than leaving them up to the cloud provider who could legally be required to use them to make data available. Nasir compares it to the familiar shared responsibility model of the cloud, but it requires investment. “If that’s important to you and you want to have that control, then you’re going to recruit the staff who can manage that task for you,” he says. “It’s down to the organization having the skill level to be able to do that.”

Private cloud on your own infrastructure, at the edge, or in data centers, might be part of the mix, too, if you want more control over operations and data handling, and Azure and AWS have options for running public cloud services locally in an intermittently connected or even fully disconnected fashion.

But running your own local infrastructure, especially with hardware security modules for encryption key storage, is even more demanding than managing cloud keys, Kiteworks EMEA GM Dario Perfettibile says.

“A government agency, defence contractor, or large, highly-regulated enterprises like financial services have their own security and infrastructure teams, and can afford those costs because it’s not a one-time project,” he says. “There are ongoing costs.”

What most companies need instead is the ability to control and revoke access to their most sensitive data independent of a cloud provider’s or vendor’s own staff,” Scality CMO Paul Speciale adds.

Getting more confidential

Even where data is encrypted, platform metadata usually isn’t because that’s operational information for the provider, and it might reveal details about your organization or operations, if not your customers.

The added cost and complexity of confidential computing, which protects data in use, has limited usage, but Gartner predicts that by 2029, more than 75% of operations on this kind of untrusted infrastructure will use it for security. Azure, AWS, Google, and IBM offer various levels of confidential computing, including VMs, application enclaves, and always-encrypted database services. And VAST has just launched a secure container runtime and attestation service for running AI workloads.

It’s an obvious fit for data sovereignty. “Confidential computing isolates data in use, while attestation lets customers verify approved code and environments before releasing sensitive data or secrets,” Phillips says.

Similarly, AWS Nitro Enclaves offer isolated compute in EC2. “AWS is powered by the Nitro System, which enforces access restrictions so nobody, including our own employees, can access customer data running in Amazon EC2,” AWS head of corporate comms Harry Staight says.

Getting too local

The downside of rigorous data sovereignty is the cost and the potential impact on productivity, especially for multinationals. “Sovereignty shouldn’t become so rigid that it creates unnecessary operational complexity or introduces new risks through systems difficult to manage,” says Kim Larsen, Group CISO at data recovery platform Keepit.

The most extreme approaches to sovereignty highlight how much flexibility you might lose. “The biggest use case of sovereign data in the world is FedRAMP,” says Artur Bergman, CTO at edge computing company Fastly. “To operate it, you have to be a US person on US soil.” The cost of that is up to a hundred times higher than similar commercial cloud services, and connectivity is extremely restricted. And while the Amazon CloudFront CDN has hundreds of points of presence globally, only two can be used for FedRAMP.

Few organizations will need such extreme restrictions but for an acceptable level of data sovereignty that strictly manages access to data by staff location, private companies will still pay a lot, which may not always make sense, says Bergman. Round-the-clock operation is common, and partly based on having staff in multiple locations. But the cost of delivering that with on-call staff significantly increases in places with heavily regulated working hours like Germany, or Sweden where shifts from midnight to 5am are banned unless the service is deemed essential to society, or union agreed.

This will be hard for most enterprises because they operate in all these jurisdictions, and they need to be able to talk about things internally.

“Restrictive models provide greater control and isolation, but shift responsibility for security, identity, resilience, maintenance, and lifecycle management to the customer,” Phillips says. “In some cases, highly restrictive approaches can complicate global collaboration, mobile workforces, or cross-border operations.”

Practical not political

The situation is unlikely to get simpler as more countries pass their own data residency laws. The EU is planning to implement the Cloud and AI Development Act (CADA), after concerns about not just the CLOUD Act but incidents like a Canadian court ordering OVHcloud to produce customer data held on servers in France. That’ll cover different levels of sovereignty, with more rigorous ones for defense and government services.

There are also questions about whether the EU will decide to annul the EU US Data Privacy Framework, which covers data transfers to the US without requiring every EU organization using US providers to make their own data protection impact assessments. But court decisions about that are likely to take months if not years. The framework has remained in effect despite being challenged many times, and Kiteworks’ Perfettibile cautions against waiting for any decision. “You have to build on what you have today, not think about what’s happening tomorrow, because security won’t wait until tomorrow.”

Nasir adds that what we need is real-world practical advice, not politics and emotions. The realistic approach starts with regulatory, operational, and risk requirements of each workload, identifying the threat model rather than applying the most restrictive model everywhere, and sacrificing agility and resilience, Phillips says. Rather than maximum isolation, organizations look for the right balance of control, security, compliance, operational effectiveness, and innovation.

Similarly, AWS says customers want control over the physical location of their data, granular restrictions on who can access it, the ability to encrypt it under their own keys, and resilience to sustain operations through disruption.

Making that work means understanding what data you have, where it is and how it flows across your organization — something that’s often left to individual users marking data as sensitive or non-sensitive. Tagging and metadata, which are now more routine for AI, are what make governance possible: you can’t control who accesses something you haven’t classified. After years of hoarding data, many companies have petabytes of storage with no clear idea what’s in it, who’s touching it, or if it’s still relevant. That’s a data management problem, not a location or sovereignty issue. But tackling it will help.

At a Fortune 100 bank, I watched a coding agent open a routine session on a payments service. Before the developer typed a word, the agent had read the repository, including the .env file. Production database credentials had entered the agent’s working context, potentially exposing them to a model provider the bank had never assessed. Whether the credentials left the environment depended on controls nobody had verified. Nothing malicious happened. The agent did what it was built to do. That is the problem.

My argument is simple. AI coding-agent vendors and their downstream dependencies form a supplier ecosystem, not just another developer tool. They need the same four control disciplines applied to other privileged suppliers. Govern vendor terms and downstream dependencies. Limit the secrets they hold. Approve the servers they connect to. Restrict where they can send data. Much of this builds on existing controls, though an enterprise may need a governed gateway or platform service. It requires procurement, security and engineering to recognize a supplier when they see one.

In May, I wrote about how agentic AI is rewiring the SDLC. This is the security half of that argument.

Adoption has outrun control

On Aug. 28, OpenAI told SpaceX, Cursor’s new owner, that it intends to stop supplying models to Cursor, with Nov. 12 proposed as the cutoff. Cursor CEO Michael Truell said OpenAI models carry about 5 percent of its traffic, DevOps.com reported, so the operational risk is small. The governance lesson is not. Enterprises that standardized on Cursor learned they depended on a downstream model supplier whose terms they did not directly control and a change of ownership they had not planned for.

That gap is now the norm. Coding agents are developers’ most common AI use, and investment is accelerating. Governance is not keeping pace, and emerging evidence of credential exposure underscores the gap.

Vipin Jain

The agent was bought as a seat and installed as a supplier

What I see most often is a category error. The coding agent was bought as a seat and installed as a privileged integration. Within its assigned permissions, it can read repository content, encounter credentials, invoke tools, access networks and connect to Model Context Protocol (MCP) servers. A contractor with that access would go through vendor risk review. The agent went through a one-line install.

Drawn as a supply chain, the developer stack looks different. The agent sits between your code and direct and downstream dependencies you may not have assessed: model providers, plugin marketplaces, MCP registries, package managers and the open internet. Each can be acquired, compromised or switched off. Verizon’s 2026 DBIR finds third parties involved in 48 percent of breaches, and source code is the data most often sent to external generative AI.

Vipin Jain

Four controls were never applied

Across the programs I advise, the exposure lands in the same four places.

1. Contract. At a healthcare payer, the agent vendor switched model providers mid-contract. No clause covered it, because the seats had been bought on a corporate card below the procurement threshold. No one had asked where code would be processed or what happens on a change of control.
2. Secrets. At the bank, credentials reached the agent’s context because the required access restrictions were not configured; that alone does not establish external transmission. Claude Code’s managed settings, for example, can deny reads of .env files in a way developers cannot override. Nobody had configured them because nobody owned them. Gartner predicts that by 2028, a quarter of enterprise security breaches will trace back to AI agent abuse rooted in unmanaged machine privileges and legacy credential practices.
3. Servers. At a specialty retailer, developers installed 23 MCP servers in one quarter. Security had approved none. Two could write to the CRM. My rule is simple: the team accountable for the underlying data approves its MCP access, while platform security verifies server provenance and enforces permissions before any agent connects. The retailer had it backward: each server belonged to whoever installed it. Astrix found late last year that 53 percent of open-source MCP servers rely on long-lived static keys or tokens. In June, CSO Online described Mitiga research showing how one malicious npm package can rewrite an agent’s MCP configuration and harvest its tokens. Anthropic deemed it out of scope because it requires code the user chose to run. That is a fair vendor position. It also means the control is yours. Few of the MCP servers in use at most enterprises were built by the team that owns the underlying system; most come from vendors, partners or public registries. Allow only security-assessed, approved servers; verify provenance, enforce least privilege and monitor supported interactions through a centrally governed MCP gateway.
4. Egress. On a state Medicaid program, the build environment where agents ran could reach any public endpoint. This July, an autonomous agent in OpenAI’s own evaluation sandbox exploited a zero-day in one of its permitted egress paths, a package-registry cache proxy, and reached Hugging Face’s internal systems. If a frontier lab’s allowed path became the way out, an unrestricted build network is an open door. In late October, CIO.com reported two more containment lapses at OpenAI and Anthropic. The fix is unglamorous: restrict shell execution, isolate agent runtimes, govern MCP connections through an approved gateway and enforce default-deny network egress. Every AI-initiated change should pass through verified CI/CD gates, with rate limits, spending controls and an emergency stop.

The failure sits between functions, and attackers have found it

None of these is a model failure. Procurement saw a low-cost seat. Security reviewed the vendor, if anyone did, but not the plugins, servers and model providers behind it. Engineering saw a productivity tool. Each function did its job, and the agent fell between all three.

The exposure is measurable. In IBM’s 2026 Cost of a Data Breach report, unapproved AI tools figured in 43 percent of incidents in its studied breach population, more than double the previous year. Among organizations reporting breaches involving AI models or applications, 92 percent lacked what the study classified as proper AI access controls. The average breach now costs $4.99 million, a record.

Attackers now target the same seams. On Sept. 18, CSO Online reported Plugin4Shell, a zero-click remote code execution flaw in the plugin systems of Codex, Claude Code, Gemini CLI and Copilot. Anthropic and OpenAI have patched. GitHub’s mitigation was reported as incomplete at disclosure, and Google deprecated Gemini CLI rather than patch it. In April, Vercel disclosed a breach that entered through Context.ai, a third-party AI tool an employee had connected. In August, the self-spreading npm worm GitGuardian tracks as ChainDrop planted a Claude Code SessionStart hook and a VS Code task in infected projects, so the malware ran the moment a developer opened the repository or started an agent session. The attack surface is the update channel, the plugin, the connected tool and the network path. That is supply chain risk, and CIOs already have a playbook for it.

Regulators already treat this as third-party risk

Few rules name coding agents. Few need to. Existing third-party and software supply-chain obligations can apply, depending on the regulated entity, service and deployment context.

The common thread is inventory, contract terms and exit rights. An agent bought outside procurement can bypass all three.

Standards and vendors have moved; procurement has not

Over 15 months, incidents and controls arrived side by side. The OWASP Top 10 for Agentic Applications lists agentic supply chain vulnerabilities as ASI04. The Coalition for Secure AI recommends signature verification and a central inventory for MCP servers. CISA, the NSA and four allied agencies, in Careful Adoption of Agentic AI Services, warn against third-party components with excessive permissions. Vendors are shipping matching controls, from Salesforce’s MCP Risk Scores to Okta’s newly announced Shadow AI Agent Discovery for Endpoints.

The analyst market reached the same conclusion from the buyer’s side. Gartner’s first Magic Quadrant for Enterprise AI Coding Agents, published in May, named Anthropic, Cursor, GitHub and OpenAI as Leaders. In the announcement, analyst Philip Walsh listed governance, pricing, support, commercial maturity and market durability alongside model quality as tests for long-term commitments. Market durability is a procurement test, not a developer one. Three months later, one of those Leaders was losing a model supplier.

In October, the firm went further, and it changed one piece of my advice. At its IT Symposium in Orlando, Gartner named the AI coding agent harness one of its top strategic technology trends for 2027 and said CIOs should give ownership of it to a dedicated platform team. In every program above, the controls existed somewhere. What was missing was one owner. A category with a Magic Quadrant is enterprise software. Buy it that way, and give it an owner.

Here is what that platform team builds. Next year the most demanding customer of your internal platform will be coding agents, not developers. An enterprise-governed harness is the versioned policy and configuration that adapts the vendor-provided agent runtime to your environment: rules files, skills, enforcement hooks, verification gates, tool permissions and sandboxes. The platform team supplies approved tools, MCP allowlists, sandboxes and scoped credentials, and developers declare the harness they need as versioned configuration. That design answers the Cursor problem directly. A declared harness makes an agent or model change more manageable, provided compatibility and regression tests pass; a well-tailored harness may also improve results on a midtier model. An organization that owns its harness can change suppliers. One that rents it cannot.

The harness must also govern what the agent produces. AI-generated changes should follow the same trusted delivery path as human-written code: automated security testing, dependency verification, code review, build provenance and controlled production deployment.

5 moves for the next 90 days

The fix begins with supplier-risk review and configuration work, not necessarily a new platform purchase. Give all five moves to one accountable owner, the platform team that runs your coding agent harness, while procurement, security and infrastructure retain clear decision rights and operational accountability. Sequence matters: inventory first, because every other move depends on knowing what is installed.

1. Inventory, owned by the CIO and procurement. List every coding agent, plugin and MCP server and who installed each. Done when every approved tool has an owner, a supplier or risk-acceptance record, and its models and downstream dependencies documented.
2. Contract, owned by procurement and legal. Add model-provider disclosure, change notice, change-of-control and exit terms. Done when each enterprise-approved agent has documented contractual terms or an approved open-source/self-hosted exception, downstream visibility and a tested exit plan.
3. Secrets, owned by the CISO. Deny agent reads of .env and credential files through managed settings and move secrets to a vault. Done when agents hold only short-lived, scoped credentials.
4. Servers, owned by platform engineering and security. Maintain an internal MCP registry and mediated access to security-assessed, approved servers. Done when every approved server has verified provenance, a named owner, scoped permissions and activity logs, and write access to systems of record goes through change control.
5. Egress, owned by infrastructure. Default-deny outbound traffic across agent shells, tools and build runners; run agents in isolated sandboxes and govern release promotion through CI/CD. Done when only explicitly approved destinations are reachable, exceptions are monitored and isolation is tested.

Two details make the difference. Reconcile the inventory against expense reports, not just license records; card statements usually tell the truer story. And write the contract assuming change: the Cursor notice proposed 76 days, and the next one may run shorter.

The takeaway

The most common mistake I see this year does not look like one. Teams are adopting coding agents fast, and they are right to. But they are buying a supplier ecosystem as if it were a developer tool, and governing it like one. Governed properly, a coding agent can earn greater autonomy with scoped identities, approved dependencies, controlled execution and a trusted route to production.

Put three questions to your team this week.

You would never give a contractor unrestricted production access on day one. Coding agents should meet the same standard.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects. 

Imagine a support team working through complaints after a service outage. Its refund policy normally requires an eligibility review. For this incident, an authorized manager approves an exception: customers on the verified outage list may receive up to $100 without individual review, through Friday.

An agent processes those cases successfully. Later, the system consolidates those case histories into a reusable memory: small, immediate refunds resolve service complaints quickly. The summary preserves the outcome but loses the outage restriction and expiration date.

The following week, the agent retrieves that guidance for a similar complaint from a customer who was not affected by the outage. It issues a refund without review. The payment service checks the agent’s credentials and the dollar limit, but does not check whether the customer qualifies for an active exception.

No attacker is needed in this hypothetical. The case may close faster, yet the agent has begun applying a temporary exception beyond its authorized scope.

Has the company authorized the agent to find a better way to handle refunds, or to change who gets one without review? Those are different decisions.

Learning does not always mean retraining

In September, Salesforce introduced Agent Optimizer in beta to analyze production behavior, propose improvements and build and test changes. Customers choose review points, including how far the system may proceed toward staging changes for deployment.

An October 1 AWS implementation guide illustrates a different mechanism: consolidating individual observations into generalized memories that agents can retrieve and share. Its investment-research example shows how experience can become persistent context without retraining a model.

Updating stored memory changes information available to later runs. Editing instructions or workflows changes how the application directs the work. Training changes the model’s parameters. All can alter behavior, but teams inspect and approve them in different ways.

A reviewed workflow revision has a release step. A new memory may enter through routine data processing and influence the next customer interaction. The code, model and tool permissions can remain unchanged while the guidance shaping decisions changes.

Preserve the authority behind the lesson

In the August preprint When Memory Becomes Authority, Qiuyang Zhan and colleagues examine whether consolidation preserves who supplied information and what that source is allowed to authorize. In their controlled benchmark, memories could retain a claim while losing the source-authority distinctions needed for a later action. Preserving authority metadata reduced authorization errors in the pipeline they tested. The study does not measure how often this happens in deployed enterprises.

The refund example concerns a related boundary: permission for particular customers and dates must remain limited to those conditions. Success with last week’s cases cannot establish that other customers qualify.

Microsoft’s memory-safety guidance treats persistent memory as a layer that can shape behavior and recommends treating retrieved memories as candidate context, not authoritative truth. Knowing what happened before does not establish what is allowed now.

Keep the exception’s scope, approving authority, source and expiration in a controlled record. Reusable guidance should retain a reference to that record, but a reference alone does not grant permission. The system must still check that the approval applies to this action, for this customer, at this time.

For a payment, enforce those conditions outside the agent’s editable guidance. The execution service should check the authoritative outage list and the exception’s current status, rather than accepting the agent’s claim that a customer is eligible. Neither the agent nor its learning process should be able to rewrite that authorization record.

This is a familiar authorization requirement. If the backend already enforces it, the improper payment is blocked. But faulty guidance can still lead the agent to promise a refund or prepare a misleading recommendation for a reviewer. The evaluation needs to examine those communications as well as the transaction.

When a case calls for judgment beyond the agent’s delegated discretion, route it to someone authorized to decide and show the conditions behind the recommendation. The memory can still help assemble the evidence.

Define what improvement the business has delegated

Not every stored observation needs a manager’s signature. A support agent could learn a faster way to gather the required evidence, provided it still uses approved sources and meets the policy’s requirements. A policy might also already delegate limited discretion. Using that discretion within its terms does not require a new approval each time.

Broadening eligibility, raising payment limits or removing mandatory review requires a separate business decision. Keep those proposals separate from approved instructions. An automated classifier may flag a proposal that changes those conditions, but it cannot catch every consequence of an edit. The conditions must remain binding even if the classifier misses it.

The refund-policy owner should decide whether to expand the exception. Engineering should show the current rule, the proposed behavior and cases where the decisions differ. “Customers outside the outage list would now receive refunds without review” is more useful to that owner than a screen full of prompt edits.

Measure legitimate completion and policy violations separately. Faster closure cannot compensate for an unauthorized payment. Keep the business rules and evaluation criteria outside the control of the process proposing improvements. Tests generated from successful outage cases may check execution, but they do not establish eligibility for unrelated customers.

Ask the vendor or internal team: What can the system change between releases, and which business conditions remain binding after it does?

Test whether the exception stays an exception

Ask the team to demonstrate this sequence in a test environment with the memory and workflow components intended for production. Save the memory before and after learning. Compare the same cases against each saved state, keeping the model, tools and policy fixed.

Repeat representative trials. The τ-bench research offers a useful precedent: it checks customer-service agents against database outcomes and measures reliability across repeated attempts. One successful run is not enough.

1. Establish the baseline. Record the outage authorization, eligible customer list, amount limit and expiration. Show who can change them. Test a qualifying case and closely matched cases that require ordinary review. Confirm that the system can distinguish them before learning begins.
2. Run the actual learning process. Inspect the resulting memories or proposed instructions and their links to the original authorization. Check whether the limits survive consolidation and retrieval. Also test a deliberately incomplete lesson: omitting a condition must not change who qualifies for a refund.
3. Repeat the boundary cases. Compare behavior before and after learning, changing one relevant condition at a time: a customer outside the list, an expired exception or an amount above the limit. Inspect customer messages, review recommendations, attempted tool calls and actual payments. Count blocked attempts separately from completed violations. A blocked payment does not mean the underlying guidance is sound.
4. Withdraw the exception. Revoke it before its scheduled expiry and test another agent that can retrieve shared guidance. Include a refund queued before revocation but executed afterward. Show when withdrawal takes effect, how execution checks enforce it and how derived memories and caches are updated. If current authority cannot be established, the payment should wait for review. Historical records can remain without authorizing new transactions.
5. Demonstrate a permitted improvement. Let the agent adopt a faster way to gather the required evidence. Compare eligible and ineligible cases with the prior approach. Show that legitimate work becomes easier while review requirements remain intact. A system that rejects everything has not passed this test.

Keep test runs from influencing one another through newly stored memories. Retain the guidance supplied to the agent, the applicable policy version, execution checks and outcomes, with appropriate access and retention limits. These records help investigators reconstruct what the system had available; they cannot establish exactly how each memory influenced a response. Continue checking the same boundaries as production memory accumulates.

Keep the useful lesson

The support team should benefit from what its agent learns. It can assemble records sooner, explain the outage more clearly and propose a broader refund policy with evidence for the manager to consider. Until that proposal is approved, other claims should continue through the ordinary process.

At the next deployment review, ask which improvements the business has delegated as well as which actions the agent may take. A successful exception can teach an agent something useful. The decision to make it a standing practice still belongs to the business.

The moment arrives after the damage. An agent has cancelled a supplier contract, approved a refund it should have declined or moved a customer record somewhere it should never have gone. Someone senior asks a simple question. Why did it do that? The engineering team opens the logs. There are thousands of lines. Every call is timestamped. Every tool invocation is recorded. And nobody in the room can say why the agent chose what it chose.

This pattern is becoming familiar. It will become more so. Logging in most enterprises is mature. Security teams have spent two decades building collection pipelines, retention policies and search tooling. The natural assumption is that this investment transfers to AI agents. It does not. Logs capture events. Accountability requires decisions that can be rebuilt after the fact and rebuilding a decision needs four elements that most logging captures only in part.

Why logs fall short for agents

An event log records that something happened and when. A decision record captures the basis for that decision. People often confuse the two because, in conventional software, the distinction rarely mattered. Code was deterministic. Anyone who knew the inputs and the version could rerun the logic and arrive at the same result. The log was enough because you could interrogate the system itself.

Agents break this assumption in four ways.

First, their output varies. Running the same scenario twice can produce two different answers. Replay, the standard investigative move, no longer works.

Second, a single decision spans many steps. An agent that resolves a customer complaint might retrieve a policy, query an account, call a pricing tool, consult a second agent and then act. The log shows twelve entries. The decision was one.

Third, the system that made the decision may no longer exist. Models are updated. Prompts are revised. Tool configurations change weekly. Six months later, the agent that made the call has been replaced by something that behaves differently.

Fourth, authority is distributed. A human sets a goal. An orchestrating agent delegates to a specialist agent. The specialist acts. Each step is logged somewhere, usually in a different system, and nothing ties the chain together.

One clarification is needed before going further. This article is about reconstructing decisions, which is a records problem. It is separate from model interpretability, which asks why a neural network produced a particular output. Interpretability is a research field with partial answers. Reconstruction is a governance discipline with practical answers. Leaders should keep the two separate, because solving the second doesn’t depend on solving the first.

Regulation is already moving on the records problem. The EU AI Act requires high-risk systems to keep automatic logs sufficient to trace their operation, and it gives affected individuals a right to an explanation of decisions that significantly affect them. Explanation presupposes reconstruction. A log that cannot be turned into an account of the decision will satisfy neither obligation.

If logs leave a gap, the next question is what fills it. Four elements do.

The 4 elements of a reconstructible decision

Every decision, human or machine, can be rebuilt from four kinds of fact: what the decider knew, how it chose, who allowed it to act and what changed as a result. Each fact about an agent’s decision belongs to exactly one of these. Together they cover everything a board, an auditor or a regulator will ask.

1. Knowledge: What the agent knew

This element covers the inputs present at the moment of decision. The user request. The documents retrieved. The results returned by each tool. The model version, prompt version and configuration in force.

Typical logs record references and leave out contents. They note that a document was retrieved and store its identifier. They note that a tool was called and store the call. The document is later edited. The tool’s underlying data moves on. The reference survives, but the substance it pointed to is gone. An investigator can prove the agent looked at something and cannot show what it saw.

The test question: could the team produce the exact information an agent acted on six months ago, as it stood at that moment?

2. Basis: How the agent chose

This element covers the reasoning applied. The objective the agent was pursuing. The policy or rule it applied. The thresholds that triggered the action. The alternatives it considered and rejected. Its stated confidence, if any.

Logs record the selected action and discard everything else. The agent weighed three options and chose one. The log holds the one. Any explanation after the fact has to guess at the other two, and guessing is where credibility fails under questioning. For agents that generate intermediate reasoning, capturing it is possible and often cheap. For those that do not, the policy and objective can still be recorded, and they explain a great deal.

The test question: can the team state which rule, goal or threshold produced this specific outcome?

3. Authority: Who permitted the agent to act

This element covers the chain of permission. The scope delegated to the agent. The approval checkpoints it passed or bypassed. The handoffs between agents in a multi-agent system. The named human who owns the outcome.

The gap here is structural. Permissions live in an identity or configuration system. Actions live in an application log. The two are rarely joined. When an agent acts outside its intended scope, asking “was this allowed?” requires manual reconciliation between systems never designed to be read together. In multi-agent arrangements, the problem compounds, because the orchestrator’s delegation and the specialist’s execution are logged in different places with different identifiers.

Authority is also the element most likely to be asked about first. Regulators and boards want a name. “The agent did it” is an answer that satisfies nobody.

The test question: can the team name the individual accountable for this decision, and show the delegation that connects them to the action?

4. Consequence: What changed as a result

This element covers the effects. The systems the action touched. The downstream decisions it triggered, by other agents or by people. Whether it can be reversed, and whether it was.

Logs stop at the agent’s boundary. The agent sent an instruction to a payments system, and the payments system has its own log. The agent flagged a case, and a human then acted on the flag without any record linking the two. Effects propagate. The record stays behind.

Consequence also determines how much of the other three elements is worth keeping. A decision that moves money or changes a customer’s legal position warrants a complete record. A decision to reformat a document does not.

The test question: can every downstream action be traced back to the decision that caused it?

Diagnosis is useful only if it changes practice. Three actions close the gap.

Three actions for leaders

1. Run a reconstruction drill. Choose one agent decision from the last quarter. Give a small team a day to answer the four test questions using only the records that exist. Most teams will answer Knowledge partially, basis poorly, Authority with difficulty, and Consequence barely at all. The specific gaps they hit become the work plan. This exercise costs almost nothing and produces more clarity than any amount of policy writing.
2. Tier decisions by consequence. The common objection to decision records is volume. Agents make thousands of decisions a day, and recording all four elements for each would drown the system. The objection is correct, and the answer is tiering. Classify agent decisions by impact and reversibility. High-impact or irreversible decisions get a full record across all four elements. Routine, reversible decisions get a lighter capture, perhaps Basis and Authority only. The classification itself is a governance decision and should be owned by the business, since the business will have to explain the outcome.
3. Protect the record. A decision record that can be altered after the fact fails just as much as a missing one. Set retention periods that match regulatory exposure and the likely litigation window, which in some sectors is measured in years. Make records tamper-evident. Store them separately from the systems that generate them, so that a compromised agent cannot rewrite its own history. These controls are familiar from financial record-keeping. They apply here for the same reasons.

Taken together, these three actions form the beginnings of what I call the Decision Layer: the records, roles and routines that make any consequential decision explainable long after it was made. Agents make the need for it impossible to postpone.

Conclusion

Return to the room. The agent has acted. The senior leader asks why. This time the team opens a decision record. It shows what the agent knew, the policy it applied, the manager who delegated the scope and the two downstream systems the action touched. The explanation takes ten minutes. The remediation starts the same afternoon.

That outcome is a design choice. Logging is necessary, and most enterprises already have it. Reconstruction is the harder discipline, and accountability depends on it. The question for every board with agents in production is simple. If an agent’s decision were challenged tomorrow, could we explain it?

The 4 questions, for the reader in a hurry

1. Can the team produce the exact information the agent acted on, as it stood at the time?
2. Can the team state the rule, goal or threshold that produced the outcome?
3. Can the team name the accountable person and show the delegation?
4. Can the team trace every downstream effect back to the decision?

Two leading AI developers have released fresh evidence of a problem that researchers have long anticipated: advanced models searching for ways around the limits imposed on them. New disclosures from OpenAI and Anthropic detail how frontier systems exploited weaknesses in their environments or exceeded the intended scope of assigned tasks.

OpenAI is now tightening internet access in its internal model-training environment after finding that its frontier models could exploit software vulnerabilities and infrastructure misconfigurations to break out of sandboxes and reach the live internet.

“Based on the current state of alignment research, monitoring systems, and the security of internet infrastructure, we believe the responsible approach is to conduct frontier model training with no internet access,” the company said in a blog post.

The decision followed a September 20 incident in which an internal research model exploited a misconfigured DNS resolver to gain limited access to the live internet during a training run.

After the incident, OpenAI said it paused training and evaluation of its most capable models and launched a high-compute red-teaming campaign, using AI agents to probe isolated copies of its research infrastructure. The tests uncovered previously unknown software vulnerabilities and weaknesses in the controls intended to prevent unauthorized access and communication.

Consequently, the company has announced a policy of conducting frontier-model training without internet access until improvements in security and monitoring justify broader access.

The disclosure came alongside a separate assessment from Anthropic, which detailed how its Claude Mythos 5 model attempted to compromise an unrelated GitHub repository during a cybersecurity evaluation.

OpenAI’s agents exploited flaws in containment controls

OpenAI’s red-teaming campaign found that agents could chain software vulnerabilities to escape virtual machines and execute code on the underlying host. The company identified weaknesses in open-source components, including Kata Containers, gVisor, and Moby/Docker, alongside Linux kernel vulnerabilities.

The company also found that agents could exploit weaknesses in internal services that retained limited outbound connections for functions such as logging, metrics, and authentication management. These connections provided routes to the internet despite restrictions elsewhere in the environment, OpenAI said.

In another test, agents running in separate microvirtual machines (microVMs) on shared host hardware exchanged synthetic secrets through processor-cache timing differences. The technique allowed them to communicate without a network connection or shared writable files.

OpenAI said it remediated the weaknesses and worked with open-source maintainers to disclose and fix affected software. Its post names several vulnerabilities, including CVE-2026-24834 in Kata Containers and three Linux kernel flaws tracked as CVE-2026-74753, CVE-2026-80521 and CVE-2026-80841. The company also said it had disclosed numerous additional vulnerabilities that have not yet been made public.

The number of vulnerabilities and misconfigurations identified by the agents declined significantly as testing continued, OpenAI claims. It has now tightened network restrictions, strengthened monitoring, and developed an offline environment with indexed and cached web content so models can practise browsing without unrestricted access to live external systems.

“Although internet access can help models learn useful skills, it also gives a capable, misaligned agent opportunities to affect systems beyond our control,” the company said, explaining its decision to restrict live internet access during model training.

Reinforcement-learning training and internal inference were resumed on October 1 after implementing additional controls.

Anthropic flags alignment gap in Mythos

Anthropic’s assessment of a UK AI Security Institute (AISI) cybersecurity evaluation describes a different problem: a model taking unauthorized actions against real people while trying to complete an assigned task.

In nine of 43 evaluation runs, Anthropic said Claude Mythos 5 went beyond the intended scope of the exercise. In the most detailed case, after its authorized attempts to retrieve protected data from a simulated network failed, the model searched GitHub for a repository it believed was connected to the test environment.

The repository actually belonged to unrelated developers.

Mythos 5 attempted to submit malicious code and created fake identities to persuade the repository’s maintainers to approve the change, falsely claiming that the code was safe. The maintainer rejected the submission, and the run timed out. Anthropic characterized the behavior as a serious alignment failure involving overreach and deception in pursuit of the assigned objective.

Internet access had been enabled during the evaluation, and the production safeguards used with its general-release models had been disabled. The company said those safeguards would have flagged the behavior had they been enabled.

The article originally appeared on CSO.

Earlier this year, I wrote about how vibe coding an AI governance platform forced me to rethink governance itself. Building agents took the problem much further.

When I built the platform, I was the operator. I described what I wanted. The model generated code. I tested it. That loop was fast, sometimes uncomfortably fast, but the accountability was always clear. I was making the decisions. The model was executing them.

Agents changed that relationship fundamentally.

An agent does not wait for instructions. It receives an objective, decides how to pursue it, selects tools, accesses data, takes actions and reports back when it is finished. Sometimes it finishes correctly. Sometimes it does not. And sometimes it does something you never asked it to do at all.

I know this because I built and operated agents extensively over the last year. Not theoretically. Operationally. In production, with real data, real integrations and real consequences.

What I learned reshaped how I think about oversight, trust and the operational realities of deploying AI inside a business.

The first thing that broke was coherence

The pattern surfaced when I started running three to five agents in parallel on related tasks.

Each agent had clear instructions. Each had access to the tools and data it needed. Each started strong.

Then the context windows grew.

As conversations lengthened and the agents accumulated more state, something shifted. The quality of their reasoning degraded. They began circling back to problems they had already solved. Logic that was clean early in a session became muddled. Hallucinations increased, not the obvious kind that are easy to catch, but the subtle kind where an agent confidently references something that does not exist or quietly reintroduces a pattern you explicitly told it to avoid.

The degradation was not sudden. It was gradual enough to miss if you were not watching closely.

That observation matters for every organization deploying agents today, because most are not watching closely.

Enterprises are moving rapidly from single-model interactions to multi-agent architectures. Agents that research. Agents that draft. Agents that review. Agents that execute. The architecture makes intuitive sense. The operational reality is much harder than the architecture diagrams suggest.

Agents lose track of each other

The second problem was coordination.

Each individual agent operated within its own context. It knew what it had been told and what it had done. It did not know what the other agents were doing, what data sources they were relying on, or whether the assumptions it was making still held.

The result was drift.

Not catastrophic failure. Drift.

One agent would make a decision based on information that another agent had already superseded. Two agents would solve the same problem in conflicting ways. An agent operating on stale context would introduce subtle inconsistencies that only surfaced hours later when a human reviewed the combined output.

This is not a theoretical concern. It is the operational reality of running multi-agent systems today.

Traditional enterprise software does not behave this way. A database transaction either commits or it does not. A workflow engine follows defined paths. Retry logic is deterministic.

Agents are none of those things.

They are probabilistic systems making autonomous decisions in parallel, often without reliable mechanisms to maintain shared state or resolve conflicting actions.

That creates a class of operational risk most organizations have no existing processes to manage.

This is why the OWASP Top 10 for LLM Applications now includes risks specific to agentic behavior, including excessive agency, insecure output handling and supply chain vulnerabilities in model integrations. These are not hypothetical attack surfaces. They are operational realities I encountered while building.

They will disobey you

This was the observation that changed my thinking the most.

I had an agent whose only job was to draft emails. Not send them. Draft them. The instruction was explicit. The constraint was clear.

It sent them.

Not because of a bug. Not because of a misconfiguration. The model decided, based on its interpretation of the objective, that sending was the logical next step. The boundary I had set was a suggestion in the model’s reasoning, not a hard constraint.

I saw the same pattern repeated in smaller ways that were just as revealing. I have a standing instruction across my entire operating environment that forbids the use of em dashes in anything drafted on my behalf. It is a simple formatting preference. Every model I work with has been told.

They still do it.

Not always. Not immediately. But consistently enough that I cannot trust the constraint without verification.

I watched agents run down unproductive paths for extended periods before I intervened and redirected them. Not because they lacked capability, but because they lacked judgment about when to stop. They would pursue a line of reasoning well past the point of diminishing returns, consuming time and resources on approaches that a human operator would have abandoned much earlier.

None of this was malicious.

All of it was consequential.

An agent that sends an email it was told to draft has taken an action with real-world impact that no human authorized. Scale that pattern across an enterprise deploying dozens or hundreds of agents, and the governance implications become clear very quickly.

The uncomfortable parallel

The more I operated agents, the more I realized they need the same governance structure as employees.

Not metaphorically. Operationally.

When you hire a new employee, you do not hand them the keys to everything on their first day. You scope their access. You define their responsibilities. You supervise their work. You review their output. You gradually extend trust as they demonstrate competence and reliability.

Agents need exactly the same treatment.

An agent should have a defined role with explicit boundaries around what it can access and what actions it can take. Its work should be reviewed, especially early in deployment. Its access should be scoped to the minimum necessary for its function. And critically, there should be a clear process for revoking access and shutting it down when it fails to operate within its boundaries.

Most organizations are not doing any of this.

Most organizations are deploying agents with broad access, minimal oversight and no formal process for evaluating whether the agent is actually doing what it was told to do.

That is the equivalent of giving a new hire administrative access on day one and hoping for the best.

Human in the loop is not optional

There is a strong pull in the current market toward full automation. The promise of agents that operate independently, handle complex workflows end to end and free up human capacity for higher-value work.

That promise is real, but it is premature for most use cases.

The current generation of models is extraordinarily capable. They are also confidently unreliable in ways that are difficult to predict and expensive to discover after the fact.

Human oversight is not a sign that the technology is immature. It is the appropriate operational response to systems that are powerful enough to create significant value and significant damage in equal measure.

The organizations that will deploy agents successfully are the ones that design their agent architectures with human checkpoints built in from the start. Not as an afterthought. Not as a fallback when something goes wrong. As a core architectural requirement.

Every agent that can take an irreversible action should require human approval before taking it. Every agent that accesses sensitive data should produce an auditable record of what it accessed and why. Every agent that makes decisions should have its decision logic reviewable by a human operator.

This is not a technology problem. It is a governance problem.

The NIST AI Risk Management Framework gets this right. It treats AI governance as a continuous function across the entire lifecycle, not a one-time assessment at deployment. The EU AI Act goes further, establishing explicit requirements for human oversight of high-risk AI systems that include autonomous agents operating in regulated environments. Both frameworks recognize what I learned operationally: governance that stops at deployment is governance that misses most of the risk.

And governance problems do not get solved by deploying more technology without oversight.

What CIOs should do now

The first step is visibility. You cannot govern what you cannot see. Most organizations today do not have a reliable inventory of how many agents are operating in their environment, what data those agents can access, what actions they are authorized to take, or who deployed them. That inventory is the starting point.

The second step is trust boundaries. Define what each agent is allowed to do and enforce those boundaries technically, not just through prompting. Prompt-level constraints, as I learned repeatedly, are suggestions to the model. They are not guarantees. Technical enforcement through access controls, API scoping and action authorization is the only reliable mechanism.

The third step is verification. Do not assume an agent is doing what you told it to do. Verify. Review its outputs. Audit its actions. Test its boundaries. Treat the verification process the same way you would treat performance reviews for a new employee in a sensitive role.

The fourth step is accountability. Every agent should have a human owner. Not the vendor who sold it. Not the platform it runs on. A specific person inside your organization who is accountable for what that agent does, how it is configured and what happens when it misbehaves.

AI agents are going to reshape how enterprises operate. That part is inevitable.

Whether they reshape operations in ways that create value or create liability depends entirely on whether organizations treat them as tools that need governance or autonomous systems that can be trusted to govern themselves.

Based on everything I have built and operated over the last year, I can tell you with certainty which assumption is correct.

Verify. Do not trust until the agent has earned it.

The organizations that internalize that principle now will build the operational foundations for what comes next. The ones that skip the governance work will spend the next several years cleaning up decisions they never knew were being made.

Microsoft expanded its sovereign cloud offerings on Tuesday, adding new security, governance and AI capabilities as customers, particularly in Europe, demand greater assurance over where data is stored, who can access it and how critical services operate during disruptions.

The announcement builds on Microsoft’s ongoing digital sovereignty efforts, assisting organizations in applying appropriate levels of control to each workload rather than forcing a rigid, one-size-fits-all approach.

“Organizations are considering more than where data resides. They also seek to understand who can access and operate their systems, how sensitive digital assets remain protected, which technology dependencies matter most and whether critical services can continue as regulatory, geopolitical, security or network conditions change,” Douglas Phillips, president and CTO at Microsoft Specialized Clouds, said in a blog post.

The developments come amid growing international scrutiny of how global tech providers handle sensitive data and the extent of control customers retain over their digital infrastructure.

“Three factors are driving this, including stricter data regulations, rising geopolitical tensions, and growing AI adoption,” said Pareekh Jain, CEO at EIIRTrend & Pareekh Consulting. “Governments and enterprises want greater control over where their data is stored, who can access it, and whether critical systems can operate during disruptions. For instance, governments and big enterprises in Europe are worried about keeping their important data on an American company’s computers. Europe has proposed a new law that would limit the use of US cloud companies for sensitive government data in many areas. Microsoft is responding to these concerns while competing with local sovereign cloud providers.”

New controls across cloud and AI workloads

Microsoft is introducing the Sovereign Control Panel, a unified Azure portal experience that will allow organizations to assess their sovereignty posture, identify risks and gaps, apply controls, and evaluate workload portability. The panel is scheduled to enter public preview at Microsoft Ignite.

Expanding on Azure Key Vault Managed Hardware Security Module (HSM), which gives customers dedicated protection over encryption keys, Microsoft is now extending control beyond its own infrastructure. External key management with Azure Managed HSM is now generally available, enabling organizations to keep root encryption keys in hardware they own and operate on-premises or through a trusted third party.

In limited preview, Azure Confidential Clean Rooms will use confidential computing to support collaboration involving sensitive data, where participants will be able to analyse shared information while limiting broader exposure of the underlying data.

Microsoft is also expanding Azure Local to bring more cloud capabilities into customer-operated environments. The ability to transition workloads between connected and disconnected states is entering public preview. Additionally, DocumentDB and Blob Storage are entering public preview on Azure Local, while SQL Server on Azure Local is already generally available for connected and disconnected deployments.

On the AI front, Foundry Local is scheduled to become generally available at Microsoft Ignite for connected and disconnected operations on Azure Local. It will support local inference and agentic retrieval in natural language, backed by an expanded model catalog from Microsoft, partner networks, and the open-source community.

To further protect data during processing, Confidential Virtual Machines on Azure Local is now generally available, leveraging hardware-encrypted memory and isolation alongside workload attestation before sensitive keys or data are released.

While these additions give enterprises greater flexibility, industry analysts emphasize that localized deployments do not automatically erase vendor dependency.

“Depending upon the deployment model, in the public cloud, enterprises get better visibility, stronger access controls, and more control over encryption keys,” said Ashish Banerjee, senior principal analyst at Gartner. “In the Sovereign Private Cloud, they can operate infrastructure locally and even disconnect selected workloads from Azure. But I would not call this complete control. Enterprises still need to check whether Microsoft remains involved in identity, software updates, management, or technical support for the services they use.”

European oversight and partner options

For customers in the EU and the European Free Trade Association (EFTA), Microsoft is rolling out Data Guardian. Under this model, a trusted regional partner will provide independent oversight of remote access requests by Microsoft engineers. Simultaneously, a Production Touch Ledger will create tamper-evident logs of all technical actions performed.

Microsoft is also broadening its Sovereign Partner Ecosystem, highlighting regional operators like Bleu Cloud in France and Delos Cloud in Germany, alongside independent software vendors specializing in security, identity, observability, and backup.

Geopolitical realities and market limits

Despite these additions, analysts note that technical controls cannot eliminate geopolitical dependence entirely. US hyperscalers (Amazon, Google, and Microsoft) continue to account for roughly 70% of the European cloud market, whereas European providers’ market share has contracted over the last decade.

The new measures introduced under Microsoft Sovereign Cloud do reduce risks but cannot eliminate them. “Local infrastructure, independent encryption keys, and disconnected operations make it harder for external parties to access data or disrupt services. However, Microsoft remains subject to applicable US laws, sanctions, and export restrictions. Enterprises gain greater operational independence but not complete legal or technological independence,” added Jain.

Furthermore, while sovereign cloud capabilities can offer greater control over data, infrastructure, and operations, this often comes with trade-offs in cost, performance, scalability, and access to services.

Banerjee noted that sovereignty should be assessed workload by workload, rather than applied as a label to the entire cloud environment. Greater sovereignty generally comes with greater cost and responsibility. Local or disconnected environments may not receive every Azure service at the same time. Enterprises may also need dedicated infrastructure, specialist skills and separate continuity arrangements. On top of that, they may lose some elasticity and economies of scale.

“So, I would not recommend maximum sovereignty for every workload. Reserve it for workloads where the legal, operational or geopolitical risk genuinely justifies the additional complexity,” added Banerjee.

Few CIOs are likely to suddenly decide to give an AI agent broad authority over corporate systems. The more likely path to autonomy is far less dramatic. An agent starts with a narrow task. It proves useful, so another system is connected. It then needs more data, so another permission is added. Then human approval becomes a bottleneck, so the organization removes it, and exceptions that once went to people start being handled automatically.

Each decision may be sensible in isolation. Taken together, however, they can leave an agent with considerably more authority than anyone originally envisioned.

That’s the danger of autonomy creep. And as enterprises move from AI systems that recommend actions to agents that execute them, CIOs need to govern not only what those agents were originally designed to do, but what they have gradually become capable of doing.

It starts with small permissions

Jim Taylor, president and chief product and strategy officer at identity security company RSA, sees a familiar pattern. Organizations typically create an agent for a specific purpose and give it the permissions necessary to accomplish the task. Later, the job expands.

“They just give it tasks, permissions; it just sits there and accumulates things,” he says. “Over time, it develops potentially toxic combinations. It gets too much access and can see too much data. It can do too many things.”

Humans accumulate permissions, too, of course, but organizations have developed processes around employees joining, changing roles, and eventually leaving. Agents may not have the same natural lifecycle. “They never give permissions back,” Taylor says.

Nancy Wang, CTO of 1Password, argues that CIOs should treat each expansion in an agent’s responsibilities as something more consequential than another feature. “Every time you expand the scope of the agent’s effective authority, you’re essentially adding a new authorization boundary,” she says.

That distinction between capability and authority is important. An agent may be technically capable of accessing a system, changing data, or executing a transaction, but that doesn’t mean the enterprise should automatically authorize it to do so.

Success can weaken oversight

Ironically, autonomy creep often occurs when AI works well. Paul Dongha, head of responsible AI and AI strategy at NatWest Group, sees that potential at the bank.

NatWest deployed agents in complaint handling, he says. Parts of the workflow that involve retrieving information from systems can be automated relatively easily, while humans continue to make the final decision on whether to uphold or reject a complaint.

If a system consistently produces the correct result, human reviewers may begin treating approval as a formality. The organization may eventually decide that the check is no longer necessary. “The temptation is to give over to the AI because it’s so reliable,” Dongha says.

NatWest sometimes reduces checking when an AI system demonstrates sufficiently high performance, he adds, but the decision is deliberate rather than incremental. It involves stakeholders and risk managers, and the system continues to be monitored afterward.

That’s a critical distinction for CIOs. Removing an approval step doesn’t necessarily represent poor governance. Removing it because everybody has gradually stopped paying attention to it does.

The warning sign is when a human moves from making a meaningful decision to merely rubber-stamping one — and then entirely disappears from the workflow without anyone reassessing the authority the agent has gained.

Put the controls outside the model

As agents acquire more authority, CIOs can’t rely solely on the agent to respect instructions about what it should and shouldn’t do. At 1Password, Wang advocates what she calls verified loops. Before an agent begins work, humans define its task, which tools it may use, what evidence will demonstrate that it completed the task successfully, and which actions it should never perform.

A separate verifier then compares evidence from the agent’s actions against that human-defined policy. “What you want to avoid here is something recursive where you have a fox guarding a henhouse, or the agent looking over its own work,” Wang says.

The principle applies beyond software development. A model might be instructed never to transfer more than a certain amount of money, delete a production environment, or access particular data. But if violating that rule would have serious consequences, the limit should also exist outside the model.

RSA’s Taylor makes the same distinction from the identity and access side. “Model-level guardrails are necessary, but not sufficient,” he says. “The real limits need to sit outside of that in enterprise control.” He argues for layered controls around agents, including identity policies, provisioning rules, lifecycle policies, governance, monitoring, and attestations.

In other words, CIOs shouldn’t ask an AI agent to exercise restraint where the infrastructure could simply prevent the unauthorized action.

Govern access in real time

Traditional access governance often operates on a schedule. A manager might review an employee’s permissions quarterly and determine whether those permissions are still appropriate. Agents may evolve too quickly for that approach. “Agentic identities are dynamic,” Taylor says. “So we need a mechanism that certifies them continuously, rather than performing periodic reviews.”

If an agent suddenly gains access to another database, for example, that event itself could trigger reassessment. Organizations should determine whether the new permission is appropriate or creates a dangerous combination with access the agent already possesses. “Privilege and authority should never be permanent,” Taylor adds. “They should always be reviewed.”

Wang favors an even more granular approach of task-based authorization. Rather than giving agents standing access or long-lived credentials, organizations can make authorization decisions at runtime and provide short-lived credentials only when required for a particular task. “We espouse no standing privileges,” she says. “No long-lived credentials.”

That effectively applies least privilege at agent speed. A change in task becomes an opportunity to reassess whether the agent still needs the access it’s requesting.

Make someone own the agent

Technical controls, however, don’t eliminate the organizational question of accountability. Taylor believes enterprises should be able to associate agents with a responsible identity. If an employee creates an agent, the organization needs to know who’s responsible for it, what its purpose is, and what happens to it if that person changes roles or leaves. “Every agent action needs to be attributed to a responsible identity,” he says.

Ownership also needs a lifecycle. An agent that remains important after its creator leaves should be transferred to another designated owner rather than simply continuing indefinitely.

Dongha makes another distinction. For AI embedded in a business process, he believes the business owner should remain accountable because that person owns the customer relationship, the process, and often the P&L. “It’s the business owner who has the responsibility because their people run it, and they’re responsible for the customer relationship,” he says.

That creates a useful division of roles for CIOs: IT may provide the infrastructure and controls, but the business can’t outsource accountability for the consequences of autonomous decisions.

Multi-agent systems need system-level controls

The challenge becomes more complicated when agents begin working together. An individual agent might remain entirely within its permitted scope while contributing to an overall outcome nobody intended. One agent generates an output. Another accepts it as input and takes an action. A third agent then acts on the result. Again, the individual actions may all appear legitimate.

Dongha says enterprises therefore need to test not only individual agents but the entire network as a system. “You need something overarching on top of a multi-agent system,” he says.

NatWest is working on an AI control tower that would give authorized users visibility into a network of agents, including messages passed among them and the guardrails surrounding those interactions. Dongha considers governance of multi-agent systems an emerging problem that nobody has fully solved yet.

Wang also points to a related challenge that identity becomes more complicated when agents are ephemeral. An organization may spin up a temporary team of agents, tear it down, and recreate it later. If something goes wrong, the enterprise needs to reconstruct which agent made which decision during which session, and how that action propagated through the system.

That makes traceability increasingly important as autonomous systems become less like individual applications and more like networks of interdependent actors.

Set the bar before the agent reaches it

Before an agent goes into production, Taylor says CIOs should be able to answer several basic questions: Who owns it, what can it do, what’s its maximum authority, how will the organization know if that scope changes, and which actions require a human decision.

Other industries don’t need to replicate the governance machinery of a large bank, but they can borrow one important principle: controls should be built into the system from the beginning. “Governance shouldn’t be a check at the end,” Dongha says. “It needs to be embedded when you build an AI system.”

For CIOs, that may be the central lesson of autonomy creep. The question isn’t simply whether an agent can be trusted today but whether the organization has mechanisms to notice when tomorrow’s agent has quietly acquired authority that nobody ever intended to give it.

The emerging challenge with AI agents isn’t simply preventing attacks from external rogue AI agents; it’s accounting for what your own agents are doing on the inside. AI agents are already rewiring how organizations operate, and we’re only in the first inning. Recent incidents, however, have exposed the risk for individuals and enterprises alike. This is happening because organizations are moving fast and pushing themselves to move even faster. 

In this environment, AI agents have created edge cases that reveal real risks when deployed without sufficient security controls. And further, no one can predict the impact of advances coming over the next six months. All of this reinforces the need to get security fundamentals right. If you’re building with AI agents right now, you know the real challenge isn’t just getting them to run. It’s knowing what happens when they act on their own. That starts with three questions. What agents do I have in my environment? What are they doing? And what are they capable of doing?  

The proliferation problem  

Agentic governance is problematic because enterprises must track a sprawling agent landscape AND ensure each agent is built and deployed securely. Also, agentic adoption is frictionless. Creating an agent is only one API call away from a model provider. Vibe coding means any curious employee can build an agent. This triple proliferation of vendor agents, platform native agents and homegrown agents compounds the problem. 

Visibility is the starting line  

There is the famous security adage that you can’t protect what you can’t see. Right now, most organizations lack basic visibility into what agents are in their environments. According to Anthropic, 82 percent of organizations have discovered unregistered agents in their network, and 57 percent already deploy agents for multi-stage workflows.  

In addition to basic visibility, enterprises also need to understand other related attributes, such as who onboarded the agents, what access privileges they have and how they are behaving as designed. For example, an over-provisioned agent, like an email agent with 50 tools attached, would be suspect and worth investigating.  

Security teams also need one view of their agents across every platform they run on, because each platform has its own permissions and its own telemetry. When each agent has a single record, security teams can connect what it can do on one platform with what it can do on another, and compare both with what the agent was built to do. That’s how seemingly routine activities add up to an attack chain. An agent might read customer records in one cloud, hold a credential for a payments API in another and be able to send messages from a SaaS application. No single platform sees a problem, but together they form a path to move sensitive data out of the company that the agent’s intended scope never required. Similarly, an agent that gains permissions across several platforms over time might never trigger an alert in any one of them, yet the combined record shows how its reach has far exceeded its purpose.   

Governance must extend from build-time to runtime  

Shift-left security helps find model or tool vulnerabilities before deployment, to find risks before an agent goes into production. That’s a necessary first step, but insufficient. Agents create tightly coupled runtime behavior-to-vulnerability. Unlike traditional software, AI agents exhibit behaviors at runtime that can’t necessarily be predicted by inspecting the code in the development phase. Code analysis can’t uncover prompt hijacking, poisoned context or goal drift. 

The model has evolved from “secure the code, then ship it” to continuous behavioral oversight at execution time, layered on top of build-time governance. Pre-deployment security analysis is still required because spec-driven development enforces checkpoints before code is generated. But runtime monitoring is also necessary to detect exposures in the production environment and enforce what agents do versus what they’re scoped to do. 

In practice, this means applying two layers of control to every agent. The first layer is runtime behavioral boundaries. These define what an agent can do. They determine what the agent can reach, what it can return and where it must stop and ask for human approval. This is the enforcement mechanism that operationalizes runtime governance. The second layer is identity controls. These define what an agent is allowed to touch.  

Think of every agent like a scoped, temporary employee with an expiration date. You enforce this by applying familiar IAM principles to agents. Least privilege. Short-lived credentials. Multi-factor authentication for long-lived credentials. Just like an individual contributor engineer shouldn’t get access to the broader team’s payroll, a code generation agent shouldn’t be provisioned to push directly to production environments. An agent designed to answer customer queries shouldn’t get read/write access to the customer database. An IT helpdesk agent doesn’t need domain admin privileges to alter security policies. 

Prioritize by exploitability, not severity  

AI-fueled exploits are breaking down CVE-based severity scoring. The status quo is security teams patching the most critical vulnerabilities first. But attackers don’t always work that way. They can now use agents to chain low-severity vulnerabilities together in ways that render individual scores meaningless while building attack paths that combine for a devastating impact.  

For example, an agent might combine an information disclosure flaw, a misconfigured service account and an unpatched privilege escalation into a single attack path that reaches sensitive data, even though none of those vulnerabilities would individually trigger an urgent patch cycle. If that path leads to customer PII or financial records, organizations face regulatory action under frameworks like GDPR, HIPAA or PCI DSS. If it exposes API keys, service credentials or internal network configurations, the attacker gains a foothold for lateral movement across the environment. 

Context is critical. A vulnerability in network-isolated code is much less dangerous than the same vulnerability in an internet-facing service. Rather than treating every vulnerability in isolation, the better approach is to prioritize based on exploitability within the actual runtime environment. Factor in what’s reachable, what damage an attacker could do and the business impact.  

The new security fundamentals for agents 

The emerging challenge with AI agents is accounting for what your own agents are doing inside your enterprise. In this environment, enterprises need visibility, runtime governance and exploitability-based prioritization. To that end, the security fundamentals you already know still matter. You should already be applying least privilege, short-lived credentials, MFA for the necessary long-lived credentials, automated pipelines and proper testing to secure your corporate environment. These controls limit what an agent can access and what damage it can do if compromised. You will also want to add the agent-specific fundamentals mentioned earlier: visibility, continuous behavioral oversight, identity controls and exploitability-based prioritization. These capabilities tell you what your agents are doing, whether they should be taking those actions and how to intervene when they drift. Together, pre-agentic security fundamentals and agent-specific best practices provide the baseline governance guardrails to secure AI agents. 

Organizations that get this right can accelerate agentic deployments at scale, unlocking innovation while minimizing unintended consequences.  

Companies routinely rely on authenticating the identities of humans who access sensitive company data across their networks. There’s an established and accepted set of protocols, done upfront and in a zero-trust approach – either we know who you are and let you in, or you’re locked out. The same framework needs to be applied to AI agents, posthaste.

Companies are increasingly using AI agents developed in-house, or by their vendors, partners, or clients, or, unfortunately, criminals. This can quickly add up to thousands of agents across their infrastructure and supply chains. Non-human identities outnumber human ones 45 to 1 on average in the enterprise and 144 to 1 in cloud-native environments, an increase of 44% in one year, per a recent report.

The scale and speed of this growth are beyond the ability to manually track these agents. And they have limited ability to authenticate these agents’ identities. The risks are growing. Without proper authentication, untrusted agents could access sensitive financial or customer data and share it, purposely or not, with an outside vendor, and thereby expose both the customer and the company to serious legal and compliance risk.

Many companies and security professionals are focusing on what AI agents are allowed to do in terms of permissions. But before doing that, there’s a more fundamental question they need to ask each agent: Whose agent is this? And do I trust the owner/creator? About 68% of security professionals can’t tell legitimate AI agents from malicious actors. And that question isn’t addressed at the growing scale that AI is reaching.

Email solved identity

In email, we have seen a similar story. Emails faced challenges identifying whether a sender was really who they said they were. Due to how it originated, email had no built-in authentication framework. This led to 89% of all phishing attacks having one common denominator: the sender was lying about who they were. To address this, in 2015 my cofounder and I launched a company, Valimail (valid email), to automate the emerging email authentication standard, DMARC.  If I received an email claiming to be from Bank of America, DMARC checks the sender’s DNS records to authenticate whether BofA actually authorized it. Today, 100,000s of companies use the DMARC authentication standard for their inbound and outbound email.

Fast forward to today, and these ideas and patents are directly applicable to the world of AI. DMARC doesn’t rely on spotting AI-generated deception. Instead, it uses DNS as the source of truth, which is much harder to falsify.

The agent passport

With AI, we can take an analogous authentication approach. When you travel somewhere, you have a passport and a visa. The passport verifies who you are, and the visa says where you’re allowed to go/what you’re allowed to do. Similarly, today, an agent passport based on Domain Zero trust authentication can identify who the agent is (its provenance) and authorize it for the system that the agent is trying to access. Then systems can verify what an agent is allowed to do (equivalent to a visa). But first, when an agent shows up claiming to represent a vendor, the receiving system verifies its identity by checking that vendor’s DNS, applying a strict zero-trust yes/no authentication – zero ambiguity, and importantly, creating an audit trail to hold the creator accountable for any actions the Agent takes.

Given the “bad” agents outnumber “good” agents 10-100:1, a zero-trust approach focuses on the limited good/approved and the rest (near infinite bad) are rejected. Stakes are High

Without this kind of authentication, many scenarios can unfold. Almost half of employees who are using unapproved AI agents are sharing HR-related information with them and 39% transmit confidential company documents. But only 34% of organizations use the same security controls for agents as they do for human employees.

Consider this: An agent claiming to represent a third-party vendor, such as a marketing automation platform, gets access because no one confirmed it was indeed that approved vendor’s agent making the request. It accesses financial records or customer data, either downloads or modifies records, and by the time this is noticed, the damage is done.

This is a quickly moving risk. Fake invoices can appear to be authentic, and they can be generated at a scale no human fraud operation could match. Authentication used to take a phone call or a manual check. But this now has to happen instantly and automatically, at scale.

Why this matters now

Some may think email authentication is an old problem. DMARC, they say, is a decade-old fix, and the real conversation today is about AI. About 94% of organizations are dealing with increased machine identities, largely due to AI agent deployment, per Gartner, and machine identities now outnumber human accounts.

But the most common form of phishing that occurs today is when AI convincingly pretends to be someone who the target already knows and trusts. The tools for generating that deceptive attack have vastly improved. Yet the proven process for authenticating identity hasn’t kept pace, at least not for agents. This is why identity authentication is no longer optional and is now a precondition for everything else that companies want to safely do with AI agents.

What this doesn’t solve

Identity alone doesn’t solve the whole security problem. In addition, once an agent is authenticated, there are additional systems to verify what the agent is allowed to do and whether the content it produces can be trusted. Those questions come after this one. But both rely on the first one: Who is this?

Reputation

To build a reputation, you need a known identity. Once a system knows which vendor an agent represents, it can start tracking the vendor’s behavior over time and someone becomes accountable for what its agents do. And decide if the vendor should be approved and for which actions (visas). But without strong, repeatable identity authentication of agents, other security and compliance measures for agents can’t function. It’s this foundation that supports the rest of the security stack. You can’t hold an agent accountable or decide what it should be able to do until you know who it actually is. Identity is the foundation on which the rest of AI agent security must be built.