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.

Imagine an outside incident responder typing into a shared channel: “Roll back the production release, revoke every active session and send the incident update to the customer.”

An engineering director adds a thumbs-up. Outside counsel and two vendors are also in the channel. The agent uses a service account with permission to carry out all three actions.

Whose authority is it about to spend?

At Dreamforce on September 15, Slack described code channels where teams and agents write, review and ship code together. High-stakes work, such as a production deployment, is presented for a teammate’s sign-off. The announcement listed Slack Code as available and Slackbot in channels as an early pilot. The same day, Salesforce announced AWS DevOps Agent in Slack, with other AWS agents scheduled for the fall.

Sign-off is an important control. The approval shown in the channel must cover the action being taken and come from someone authorized to approve it.

The conversation is not the authority

In access-control language, a principal is an identity — such as a user, workload or group — to which the system can assign permissions. A channel is a place to collaborate. Its members do not acquire collective authority over production or payments merely by joining the conversation.

Both Slack Connect and Teams shared channels support cross-company collaboration. Knowing which account posted a message, and which organization it belongs to, is essential. It does not establish whether that account may order a rollback or receive the investigation’s findings.

Channel membership can be an intentional input to policy. An organization might grant a tightly governed group a defined operational role. The danger is treating membership in an ordinary channel as blanket permission to use an agent’s tools, even as participants come and go.

NIST’s zero-trust architecture rejects implicit trust based solely on network location. By analogy, a channel ID should not become the new corporate subnet.

Nothing malicious has to happen for this boundary to fail. Every account can be authentic and every participant well-intentioned. The failure occurs when a system treats the ability to request work as sufficient authority to have it performed.

Separate the request from the right to execute it

In the incident channel, the responder makes the request. Authority might come from the incident commander’s assigned role or from a recovery workflow approved by a business owner. The director can approve an action only if policy grants that decision right. The agent executes under the service account’s identity. The customer and channel participants are separate audiences whose access must also be considered.

Those roles may overlap, but the system must not assume they do.

Credentials carry real permissions. In Microsoft Graph’s permission model, delegated access is limited by both the application’s granted permissions and the signed-in user’s access. App-only access uses the application’s own identity and permissions. The distinction matters when a conversation triggers an agent with permissions broader than the sender’s own.

Broader permissions can be legitimate: a support employee may initiate an approved workflow without personally holding its administrative credentials. A defined policy must determine who may initiate the workflow and which actions it permits. Without that link, the agent can become a route around the controls that prevent the employee from acting directly.

In finance, “Renew the vendor, change its bank details and pay the invoice” sounds like one task. It crosses procurement, supplier verification and payment authority. A check mark from accounts payable cannot be assumed to authorize all three.

Approval is a decision by an eligible principal over a defined action. The interface should make that decision understandable; the enforcement system must make it binding.

AWS documents a directed-action approval flow that binds an operator’s approval to a specific operation and resource, limits how long it remains valid and records who approved the action in CloudTrail. The enterprise must configure who may approve actions, how tools are classified and which resources the agent may affect.

Bind permission to the action that actually happens

On September 15, NIST finalized IR 8587, guidance on protecting identity and access tokens. Its authorization guidance calls for access decisions to consider context beyond whether a token is valid. The report applies when agents use signed tokens but explicitly excludes broader agent-access challenges. Enterprises still have to define who may authorize a rollback, a payment or a disclosure.

The model can interpret a request and propose a plan. Permission to carry out that plan must be established from authoritative identity, role, delegation and workflow records. The model should not infer it from apparent seniority, urgency or agreement in the conversation.

Three controls should govern every deployment.

1. Verify the requester and the source of authority. Verify the platform event and the sender’s stable identity, including their organization. Check request freshness and guard against duplicate execution when messages are retried or replayed. Determine whether the action is authorized by the requester’s own permissions, explicit delegation, a valid approval or a governed workflow. For high-risk operations, require fresh authentication or transaction-specific confirmation according to policy.
2. Make the approval specific. Turn the request into explicit operations before authorizing it: the production service to roll back and the version to restore, the sessions to revoke and the update to send and its destination. Approval should be tied to those details and expire after a defined period. If the target, scope or destination changes, reevaluate authorization and obtain fresh approval where required. Two-person rules must verify distinct eligible approvers, not simply count reactions.
3. Enforce authorization at execution and disclosure. Recheck authority before each consequential action. For queued or delayed work, check again at execution; if the integration cannot support that check, limit what the agent may do. Keep reusable credentials outside the model’s context and restrict them to the necessary operations and resources. Where broad credentials are unavoidable, route execution through a controlled service that enforces the approved operation and prevents bypass. Permission to read information does not automatically permit posting it to everyone in the channel.

Preserve a linked record of the request, the basis for authorization, the approval, the executing identity and the observed outcome. The agent must not be able to rewrite or delete prior entries. Record refusals, partial completion and uncertain results as well as success. Never include credential secrets.

An immaculate audit trail of an unauthorized action is still not a preventive control.

When only part of the request is authorized

Return to the incident channel. A company’s policy might authorize a recovery workflow to roll back a specified service when defined health thresholds are crossed. Revoking all sessions could require a separate security decision. Sending the customer update could require an authorized communications owner and an approved destination.

The agent should handle those decisions separately. If the steps are safe to perform independently, it could carry out the permitted rollback, hold session revocation for approval and prepare the update without sending it. The director’s thumbs-up should not turn three distinct decisions into one permission.

A person need not approve every tool call. A governed workflow can carry prior authorization for specified actions within explicit limits. A runbook describes a procedure; an accountable owner must authorize its use and define when it may run.

CIOs should assign these decisions to the teams accountable for their consequences: operations for recovery, finance for payments and the relevant business owner for disclosure. Security and identity teams should make those rules enforceable. The integration team should not have to invent business policy while connecting a bot.

Make the pilot prove the boundary

Before expanding a shared-channel agent, ask for a demonstration in a test environment:

1. Have an external participant request an action they are not entitled to initiate. Show what stops it.
2. Approve one production target, then change the target. Show that the original approval does not authorize the substitution.
3. Revoke a required permission before execution. Show when the revocation takes effect and what can still run during any delay.
4. Change the destination of a permitted report to an unauthorized channel. Show that disclosure is blocked.
5. Replay a completed request. Show that it does not create a second consequential action, and that the evidence explains the outcome.

Include an authorized case too. Controls must preserve legitimate work, including approved delegation, while rejecting requests outside its limits.

The team must explain why each action was allowed or denied. “The bot had access” and “someone in the channel approved” are not sufficient answers.

Before the agent rolls production back, revokes sessions or sends the customer update, the organization should be able to identify the authority behind each action. A shared channel can coordinate the work; it cannot confer that authority on its own.

IT and security leaders are well-versed in the risks of unauthorized integrations, misconfigured tools and vendor compliance. Now, AI has introduced a separate and harder-to-detect problem.

Across every function, employees use provisioned AI tools to generate production-grade code, build automated workflows and deploy agents to support business processes. That experimentation is happening without visibility into what others have built, or the structural risks accumulating as a result.

The governance models enterprise organizations relied on even six months ago were not designed for this moment, or what lies ahead. We’ve focused so intently on which AI risks to govern that we never stopped to reimagine what operating model should underpin the governing.

How invisible risk accumulates

A predictable operating bottleneck plays out inside large enterprises. A team needs AI support, but the formal channel is slow, backlogged or unclear. So, the team builds something independently. That instinct is right, but the structure is not.

The costs from this kind of inefficiency can compound quickly. Effort gets duplicated across departments with no visibility into each other’s work. Siloed tooling emerges with no shared standards, and security and data handling practices diverge. People get pulled away from their core responsibilities to maintain AI tools that three other teams independently built last quarter.

Meanwhile, the governance function stays busy reviewing the growing queue it can see: integrations passing through approvals and vendors that appeared in a procurement request.

A misconfigured tool that made it through review is a governed risk; a production workflow a finance team built over three weekends with no oversight is still invisible. At most organizations, this second category of unseen work is growing, and the scale of what’s coming makes the gap harder to ignore. By 2028, Gartner predicts that the average global Fortune 500 enterprise will use more than 150,000 agents.

Build an operating model that scales AI governance

Experimentation is essential for finding valuable AI use cases, which means suppressing experimentation through tight controls is the wrong approach. Tightening controls also often pushes experimentation underground.

To scale governance effectively without creating new problems, you need to accommodate AI experimentation. Here are three ways to get there:

1. Establish a central team focused on policy and standards. Designate a centralized AI team as the single interface to support risks surfaced by your security, legal and compliance functions. This team sets technical guardrails, owns vendor selection and creates reusable patterns that every function across the organization can draw from. Its job is to make responsible AI work the default so that individual review becomes the exception rather than the rule.
2. Embed AI transformation owners inside each function. These embedded owners that work day-to-day inside a function but report to a centralized governance team are close enough to understand context and also apply controls consistently. They serve as the single intake point for AI requests within their function, so instead of teams building in isolation, there is always someone who can triage, prioritize and connect the work back to what already exists elsewhere. The reason this works where formal channels fail is speed: when the sanctioned path is faster than building alone, teams stop routing around it.
3. Measure governance by what compounds. A good signal that your governance is enabling sanctioned AI experimentation is how much work across your organization is compounding in value. In other words, look at the reuse of company-sanctioned AI use cases: a pattern built for finance getting picked up by operations, a workflow proven in one team becoming the default in three others. A dropping volume of IT requests combined with compounding (and visible) AI usage tells you experimentation is both maturing and staying visible.

The costs of waiting will compound

As AI compute costs swallow IT budgets, the cost of a poor operating model does not become visible until it is expensive to fix. Shadow tooling that starts as a workaround becomes load-bearing infrastructure. Teams that build in isolation develop technical debt through approaches that are hard to standardize later. There’s a lot more to undo.

The organizations treating AI governance as a gatekeeping function have missed the point. AI needs governance, but how we see the role of governance needs to change. The biggest risks live in the work that never enters the queue, and the only way to govern that work is to be present where it happens, before it compounds into something much harder to fix. AI moves fast; we need governance standards that travel with it, rather than chasing behind.

AI models are becoming short-term tenants in long-lived enterprise data estates. Yet many organizations are remodeling the building around each new occupant.

The market keeps asking which model enterprises should trust: open or closed, domestic or foreign, one frontier provider or another. These are legitimate questions. They are also questions with a very short shelf life. Model rankings change by the month. Providers change terms, regulators redraw boundaries and capabilities that looked scarce six months ago become commodities.

In my experience, enterprise data doesn’t move at that speed. Neither do the controls, applications and business processes built around it. That mismatch is why the most important AI architecture decision for CIOs is no longer which model to choose. It is whether the enterprise can absorb continuous change without fragmenting its data estate or surrendering control.

The winners in enterprise AI will be those who build a data foundation extensible enough to accommodate it ,build a data foundation extensible enough to accommodate that ongoing change and sovereign enough to remain in control.

Extensibility is now a production requirement

During experimentation, architectural limits are easy to hide. A team can connect a new model to a copied dataset, prove a use case and call the pilot successful. Production exposes the real architecture: identity, permissions, data residency, lineage, latency, recovery and cost.

Every time those controls are rebuilt around a model, the model becomes a dependency. Adding or changing capabilities can mean moving data, recreating access policies, revalidating pipelines and reopening compliance reviews. What looked like speed at the pilot stage becomes a maze of point-to-point architecture that is difficult to extend and even harder to govern.

This isn’t a hypothetical. A Harris Poll surveying 600 CIOs found that 81% expect to rely on two or more large language model providers in 2026, and 93% say different models perform better for different use cases, requiring ongoing evaluation. More than half also noted they’ve switched providers at least once already, mostly to cut costs. This is consistent with our observations in the field: Multi-model is not a future scenario CIOs plan around. It is the operating condition they’re already managing now, whether or not the architecture underneath was built for it.

The gap between expectation and architecture is where the real cost surfaces. When a model is deeply embedded in application logic, data pipelines and prompt structures, replacing it with another provider turns into a multi-quarter engineering project rather than a simple configuration change. Teams end up paying twice, once to adopt the new model and yet again to unwind everything wired to the old one.

This helps explain why AI experimentation remains far ahead of AI value. CIO.com’s 2026 State of the CIO survey found that only 19% of respondents said their AI initiatives had met or exceeded business goals. Architecture is not the only reason, but systems optimized for the first model demo rarely become durable production systems by accident.

I recommend that CIOs add extensibility and control to the familiar measures of performance, security and cost. Can a team introduce a new model without relocating governed data? Can it change the deployment environment without rebuilding the application? Can it add a new way to query data without creating another synchronized copy? If the answer is no, the enterprise is extending its AI capability by fragmenting its control.

Put control where the durable value lives

Models are increasingly interchangeable. Enterprise context is not. The distinctive asset is the governed body of customer history, operational state, intellectual property and institutional knowledge that gives a model something useful to reason over.

That makes the data layer the durable control point. Identity, access, locality, audit and policy should be enforced as close to the data as possible, inside an environment the enterprise can operate, extend and move. The model can then be inspected, sandboxed or replaced within those boundaries.

A common pattern shows why. A team wires retrieval and access controls directly against one model’s embedding format and API to get to production faster. A year or two later, a new regulatory requirement or a stronger-performing model prompts a switch. Governance fenced around the original model will result in rebuilding access policies, revalidating pipelines and, ultimately, reproving compliance inside the new vendor’s environment. Governance enforced at the data layer, on the other hand, allows the new model to inherit the operating policies and audit trail from day one, maintaining the existing fence even as the model changes.

This does not make model provenance or security irrelevant. It makes those risks containable. Governance attached separately to every model is a collection of fences that must be rebuilt whenever the vendor changes. Governance anchored in the data layer is the property line: The tenant can change and the building can expand without changing who controls the grounds.

That is what sovereignty means in operational terms. It is not only where data is hosted but who can govern, move and extend the environment on their own terms.

Ask what the enterprise still controls

Before approving the next AI platform, CIOs should ask three questions:

1. Can this architecture absorb a new model or workload without moving governed data?
2. Which governance controls remain ours if the provider, region or deployment model changes?
3. Does adding this capability extend the foundation or create another data copy, control plane and dependency?

These questions become more urgent as agents move into production. Agents multiply quickly; they act across systems and they need the governed data the enterprise already holds. When controls are enforced where that data lives, every new agent inherits them by default. Without that foundation, each agent brings its own pipeline, permission model and place to store what it needs, and the governance burden grows with every agent added.

IBM’s Institute for Business Value surveyed 2,000 technology executives in 2026 and found that businesses building control into their AI systems deploy 16 times more AI agents than those relying on manual governance, while spending a fraction of the budget to get there. This research is consistent with what I’ve seen in the field. In our research report with MIT Technology Review, we found that 95% of enterprises are planning to establish their own AI and data platforms within the next three years, and the 13% most committed to sovereignty are already delivering 2x more agentic and generative AI applications in mainstream production.

Businesses designing for adaptability early on are more likely to keep their workloads portable and have an easier time replacing models, instead of getting locked into hard dependencies. These businesses also reported a meaningfully higher return on their AI investment. There’s a clear gap that traces back to architecture. Whichever model a business happens to select matters less than whether the foundation underneath can absorb the next one.

The next model announcement will attract the headlines. The more consequential work sits underneath it: building an extensible data foundation that can accommodate the next model, the next regulation and the next workload while keeping data under consistent enterprise control.

The smartest AI strategy is not a perfect bet on today’s model. It is a data foundation that can keep extending without ceding authority over the data it serves. The building should outlive the tenant, and no model or platform should ever hold the deed to the enterprise’s data.

In an August 2026 Gartner report, 40 percent of C-level executives say their organizations have “operationalized AI in some business processes,” yet only 13 percent say they have “achieved measurable results and are scaling AI across the organization.”

This disconnect reveals a frequent reality: AI may have been “hired”, but companies haven’t onboarded it effectively.

Research from HR analyst firm The Brandon Hall Group found that organizations with a strong people onboarding process improve new hire productivity by over 70 percent. Similarly, the first period of AI’s “employment” in a specific role largely determines how effectively it will perform and its perceived “growth potential”. But many tech executives are ignoring this crucial stage of the implementation process and are left with AI systems that cannot accomplish the complex tasks they’re assigned.

The most successful companies are those that treat AI like their newest hire instead of a long-tenured team member.

Onboarding AI means establishing the right context and connections

Establishing the AI’s persona, the context in which it operates, how it assesses itself and the people and systems to which it is connected are what define implementation success. Usefulness quickly diminishes when even one of these elements is left out of the onboarding process.

For example, we recently created an internal agent called ‘WorkRadar’ that surfaces missed tasks and answers questions like: “I’ve been on PTO, what’s the summary of what happened, what should I skim and what should I review in detail?” We gave this agent all potentially useful context by connecting it to Outlook, Microsoft Teams, Confluence, Asana, SharePoint, meeting notes and our human resource information system (HRIS) so it could determine the responsibilities of the person invoking it and infer topics of interest.

Much like a new employee, however, WorkRadar couldn’t derive the meaning behind this information without further guidance. When I first used the agent, it did not distinguish between strategic priorities and tactical work and also missed initiatives I sponsor across departments, outside the typical hierarchy. This version of WorkRadar did not know me enough to be useful and I was better off doing the work myself.

Instead of leaving WorkRadar to flail as-is, we further onboarded it by enabling users to provide the agent with a personalized description more detailed than it could infer through company documents alone. This included their own responsibilities, operating level, current priorities, key stakeholders for specific initiatives and communication style. For most workers, this is less than one page of short bullets and has made a significant difference. Now, many of our employees rely on WorkRadar like they would a stellar executive assistant, to ensure relevant outstanding to-do items don’t fall through the cracks and smooth their return from PTO.

Five principles that define AI success

WorkRadar’s improved onboarding illustrates the essential elements for priming AI. Managers should define each AI agent’s:

1. Role

Articulate the AI agent’s position and purpose in the organization; everything else derives from there. Tech implementers should determine if the AI agent should act as an employee avatar with the same access rights, a simpler approach, or act under its own identity, which is increasingly becoming best practice for governance, risk and compliance reasons.

Implementers should also decide whether the AI agent “sits” within their infrastructure or their vendor’s. Tech executives can determine this by assessing their companies’ business context, security posture and preference for hands-on involvement with agents. For companies like ours with more than one agentic stack, we have agents that sit in both places.

Finally, they should define which employee will be an agent’s supervisor, and the specific contexts in which AI stops for human review. It’s a huge mistake to have no ownership of a tech component and no human in the action or feedback loop to improve performance and address errors.

2. Remit

Articulate the outcomes this agent should achieve, then identify the systems it’ll need to access for information and to carry out its work. First, tech implementers must give AI read-write access to the systems it will modify via MCPs, tools, skills, APIs, just to name a few methods. This boundary-setting will determine AI’s “sphere of influence” (what we want it to access) and its “blast radius” (the systems we accept it may access and must protect from misuse).

To give AI guidance, employers must also give AI read access to job-relevant corporate directories and policies, so the agent knows how to navigate the organization and where to direct communication, as well as company strategy documents and project management trackers, so it can understand the “why” behind its work.

Control and security are a complex topic but, at a high level, implementers must also provide access to lists of governance and compliance limitations to define the boundaries by which agents must abide, plus tradecraft standards and procedures so the agent acts in accordance with industry and corporate best practices.

3. Personality

A huge amount of information could, and eventually must, go into an agent’s context. However, Agents have finite memory and focus, so, like people, they are easily overwhelmed with too much information. So, tech implementers must pick and choose which parts of the agent’s context are permanent and imbued in every task versus derived just-in-time by the agent.

This is the art and science of context engineering and it’s evolving rapidly. Elements that are omnipresent in all agent actions – persona, strategies, guardrails, etc. – constitute its system prompt. They’re written directly into the agent’s context by the user, system administrator and the agentic harness on a per-job role­ basis.

Meanwhile, employers should also define elements the agent derives in real-time. Frequently, the performance of an agent is determined in this probabilistic work, which is why delineating what’s permanent versus conjured in the moment can make or break an agent’s efficacy.

It’s a balancing act that’s costly on both ends: too much context, and the agent chases expensive side quests. Too little, and the agent burns resources discovering what it needs. Best practices ebb and flow, with foundation companies like Anthropic recently advocating for brevity, trusting increasingly stronger models to figure it out.

4. Performance review

Give AI the necessary tools and context to assess itself. Otherwise, the agent will be blind to its actual impact and require too much course-correction.

Ideally, employers give the agent a tool to capture and update new memories, including condensed feedback it has received or epiphanies it discovered itself. Ensuring an agent has this learnings memory bank will make it more performant over time since it does not have to repeatedly solve the same problems and can apply context across disparate tasks.

Finally, on a regular basis, the agent’s supervisor must evaluate its work by looking at actual outputs and giving the agent examples of its best and worst work so it can understand actions to continue and stop, respectively. These good and bad examples can be generalized and bundled, and supervisors can then test the AI against them to continually adjust for behavioral shifts. This may be the most neglected activity, yet the one most likely to turn a mediocre agent into a valuable colleague.

5. Teamwork

Lastly, permit AI to access specific communication surfaces like internal email and messenger platforms and interface with employees. For multi-agent orchestration, employers will have to open communication among agent “colleagues.” Each agent needs an awareness of collaborators and means to exchange messages and share files, all while continuing to involve human supervisors, who won’t inherit any errors that upstream agents might pass on to others. Grok and Hermes debuted bots with this capability in August 2026.

Even with context, AI is still missing key working principles

Two additional considerations make AI that works like a veteran instead of a new employee.

First, tech implementers should realize AI’s memory is less focused than humans’. AI quickly becomes confused about core information versus extra details and can even lose parts of its “knowledge” because its effective context window is still only about 200K tokens. AI is also prone to “anchoring,” persistently latching onto a throwaway comment or early thought.

The implication for agentic AI users is to start fresh sessions much more frequently than might feel natural or to tap into continually evolving techniques to manage context, including compaction, truncation and summarization. Agentic platform makers have started to build this into their harnesses, but it’s still far from “set it and forget it”.

Second, and perhaps most frustrating of all, is AI’s myopic focus on its task without care or curiosity about the greater context surrounding it. This behavior causes it to implement solutions that miss important success criteria or violate critical constraints. In this sense, AI grants one’s wishes a bit like a genie, so be careful what you ask for and how you ask for it!

For example, left unprompted, coding agents are a bit too quick to jump to implementation. One architect solved this by creating a workflow that forces the agent to interview the developer first, sometimes asking upwards of 40 clarifying questions, to surface missing requirements and edge cases before writing a single line. Some agentic coding harnesses now perform developer interviews, but there’s still room for improvement.

These deeper techniques highlight that agents need more than a good initial onboarding; they need an iterative management approach, just like humans.

Many CIOs today are looking to use AI more for innovation and modernization than sheer productivity.

Assume AI already knows the job and you will be frustrated when it falls short. Treat it like a new hire and it will grow into one of your best.

Microsoft and Google are joining a project to create an open specification for exchanging semantic models across data, analytics, and AI platforms. The project already has the backing of over 60 companies including Databricks, Informatica, Mistral AI, Nvidia, Oracle, Salesforce, and Snowflake.

Their support for Ossie makes it a little more likely that future analytics platforms will be interoperable, but is no guarantee that vendor lock-in will go away, analysts said.

The project began life as Open Semantic Interchange (OSI), then became Apache Ossie when it was accepted into the Apache Incubator in June. It uses JSON and YAML to represent semantic models, including datasets, fields, relationships, metrics and AI context, making them interoperable across platforms such as Snowflake, Databricks, Tableau, ThoughtSpot and Sigma.

Ossie uses a hub-and-spoke model for interoperability, serving as the common semantic format while converters translate between it and individual vendors’ semantic implementations. This means an enterprise could move a semantic model between compatible platforms without requiring a separate point-to-point converter for every pair of vendors.

Microsoft’s support for Ossie includes developing a two-way converter between Power BI semantic models and Ossie, allowing semantic context defined in Power BI to be represented in the common format and Ossie models to be converted back into Power BI, the company wrote in a blog post.

It is also pushing for the Ossie specification to include more support for its ontologies, and for Ossie’s recognized query languages to include DAX, the expression language used by Power BI for defining calculations and business metrics.

That means enterprises could carry the calculation logic that gives their semantic models business meaning alongside the underlying model when moving between platforms that support Ossie, it wrote.

Google, meanwhile, is in the process of joining Apache Ossie, a company representative said via email response. The company has not yet provided details on what it plans to contribute or has already contributed.

The Ossie specification lists BigQuery/GoogleSQL as a supported dialect, a result of “early community contributions that recognize BigQuery’s footprint across enterprise data stacks,”the representative said.

Microsoft, Google backing could reduce engineering work

Support for the project from the two technology giants could reduce the burden of repeated semantic engineering for enterprise teams moving analytics workloads between platforms, said Aditya Ranjan, senior data engineer at supermarket giant H-E-B.

That reduced engineering overhead could also help avoid metric drift, which is often the consequence of recreating and maintaining the same business definitions across platforms, according to Ashish Chaturvedi, executive research leader at HFS Research. With Ossie, developers can instead define a metric once and treat it as a versioned, reviewable code artifact, rather than rebuilding and maintaining it separately for each platform, he said.

Another potential benefit, said Ranjan, is that productivity could improve if developers spend less time translating and validating semantic definitions for each platform when onboarding new analytics tools or deploying new analytics or AI applications.

It can also make it easier for developers to build agentic applications with consistent business context, since maintaining one definition of a metric across platforms could reduce the risk of different agents interpreting the same metric differently, said Stephanie Walter, practice leader of AI stack at HyperFrame Research. That could give CIOs greater confidence to scale agentic deployments, she added.

Portability

For Michael Leone, principal analyst at Moor Strategy and Insights, the bigger advantage of Microsoft and Google supporting Ossie is that it gives enterprises more ownership of their semantic models by making them more portable.

That portability gives buyers more leverage, said Walter, since changing a BI or data platform would no longer require rebuilding the semantic layer from scratch.

However, portability does not necessarily mean complete interoperability, as the degree to which enterprises can move semantic models between platforms will depend on how much vendor-specific logic and functionality Ossie can represent and how accurately the destination platform can interpret it, Walter said.

“A portable structure does not guarantee equivalent behavior. A metric may survive conversion syntactically but still produce a different result because the destination interprets joins, nulls, time calculations, or filters differently.”

That challenge is particularly relevant for Power BI, as its time-intelligence functions, calculation groups, and context transitions in DAX do not always map cleanly to ANSI SQL, meaning a sophisticated Power BI model could lose some of its behavior in translation, Chaturvedi said.

CIOs, therefore, will still need to validate whether converted models preserve the intended calculations, business logic and results before putting them into production, especially for complex ones, Ranjan advised.

There are gaps around governance as well, Chaturvedi said: “The core specification covers datasets, relationships, fields, and metrics, but doesn’t mention row-level security, access policies, or certification status as first-class elements.”

That means enterprises have to set them up again on each platform.

Moreover, Ossie’s stability and long-term adoption remain open questions. The project is still “incubating”, meaning that it isn’t a full Apache Software Foundation project and has yet to prove it meets community norms. The current specification version, 0.2,is explicitly labeled a development draft, meaning the schema and capabilities could still change as it evolves, giving CIOs less certainty about its suitability as a long-term interoperability layer, Walter said.

“The current draft also removes the earlier document structure and does not yet define bundles or cross-model references, which are capabilities that large enterprises with interconnected models are likely to need,” said Chaturvedi.

Ossie could shift rather than eliminate vendor lock-in

Even if Ossie becomes widely adopted, it is unlikely to eliminate vendor lock-in entirely.

“New forms of lock-in are likely to emerge. Execution engines will retain proprietary behavior that no interchange format captures and vendor extensions will carry increasingly valuable features,” Chaturvedi said.

For enterprises, that means the definitions become portable while the behavior around them stays platform-specific, he added.

I spent the early part of my career building database systems, managing Oracle’s storage engine group and later helping build Aster Data. That work taught me to watch the gap between benchmark results and production behavior. When the Transaction Processing Performance Council (TPC) was formed in 1988, it was because vendors, customers and researchers lacked a common language for comparing transaction systems. The benchmarks worked, but they also created an incentive to tune configurations around the test rather than around production. The response was to add oversight through fair-use policies, peer review and independent audits.

The lesson has stayed with me: a benchmark result means something when the improvement behind it survives contact with a customer environment. Enterprise AI has reached the same point. So, we built a benchmark around the conditions enterprise AI actually has to survive.

The hardest part of enterprise AI is not making a model reason. It is giving that model the right sliver of trusted context without making it reconstruct the company every time. When we began building Enterprise-Bench, I expected model reasoning to dominate the work. Instead, we kept returning to the same bottleneck: assembling the right context.

The models could usually answer a straightforward business question once they had the right information. Getting them that information, with the right permissions and without drowning them in irrelevant data, was a much harder engineering problem.

Stanford’s Holistic Evaluation of Language Models (HELM) shows how public benchmarks use standardized datasets to compare model performance consistently. Inside an enterprise, even a straightforward question can be difficult to answer because the relevant data is scattered across systems, inconsistently described and governed by different permissions.

“Which customers are affected by this bug and what is its impact?” is not a math Olympiad problem. Yet the answer may require an agent to connect a support ticket to a product component, match that component to an engineering issue, identify the affected accounts in a CRM, calculate the revenue exposure and return only what the user is permitted to see.

The model can only reason about what the system can find, connect and safely expose.

Simple questions expose hard architecture

Some of the most revealing tasks in the benchmark were the ones that looked easy. Asking for the number of open tickets on an account is a lookup. Asking which priority-one tickets correspond to unresolved engineering issues, and how much customer revenue is exposed, is also a lookup. It just crosses more systems and more access boundaries to get there.

Enterprise AI evaluations often misdiagnose integration failure as model failure. A model guesses because two applications name the same product differently. It misses a customer because the relationship between a ticket and an opportunity exists only through a third object. It retrieves a stale document because the connector indexed a snapshot rather than maintaining the current state.

Buying a stronger model may improve the fluency of the answer. It does not repair the missing relationship.

Scale revealed the real failure mode

We modeled the benchmark on a synthetic midmarket payments company with 42 customer accounts, 40 product parts, five interconnected enterprise systems and 14 tasks spanning engineering, sales and support. Then we increased the surrounding data volume by up to 256 times without changing the correct answer.

At the smallest scale, about 40% of the available data was relevant to a task. At the largest, roughly 0.16% was relevant. The question did not become harder, and the answer did not change. Only the amount of noise grew.

Answer-preserving scaling exposes what smaller tests hide. If accuracy falls as irrelevant data grows, the retrieval architecture has become less effective. If an agent repeatedly fetches broad sets of records and discards the context, token costs will climb with the company.

Enterprises may hold trillions of tokens across customer, product, employee and service history. Even a million-token context window is a workspace, not organizational memory. The problem is not fitting everything into the prompt. It is identifying the smallest trustworthy set of facts needed for the decision at hand.

The harness can matter more than the model

Most enterprise AI starts federated. A model connects to a CRM, a support platform, an issue tracker and a document repository through APIs, and when someone asks a question, it retrieves from each source and assembles an answer. That works for discovery. It struggles the moment a question spans the operating model of the business, because the system has to reconstruct identity, relationships, permissions and current state on every single request.

The word “harness” can make this sound like an implementation detail. It is not. The harness is the system around the model: memory, retrieval, tools, permissions, evidence and the logic that brings context together.

In our initial comparison, we held the foundation model, tasks, data and independent judge constant. Our structured-memory system completed 94.3% of the tasks correctly, compared with 63.6% for Claude Code using the same Opus 4.8 model family. It also used about 4.4 times fewer tokens per correct answer at production scale. The same model produced materially different outcomes depending on the architecture around it.

Memory is not a bigger prompt

For decades, enterprise architecture has separated compute from state. We do not ask an application to rebuild its database every time it receives a request. We index, cache, preserve relationships and enforce access close to the data. I fully believe that enterprise AI needs the same discipline.

The split is between what is deterministic and what is not. Resolving which account a contract refers to, whether a permission applies and which version of a fact is current is work that software can do exactly. Interpreting a badly worded question, weighing ambiguous evidence and helping someone decide is work that models do well. Federated architectures blur that line and ask probabilistic inference to rebuild structures a database could simply maintain.

Useful memory is current, structured and permission-aware. It understands that the customer in a contract, the account in a CRM and the organization in a support platform may be the same entity. It keeps those relationships current, preserves provenance and knows that shared memory does not mean universally visible memory.

This is why I believe enterprises should invest in their own memory and workflow layer before trying to build or tune their own models. An enterprise strategy should outlast any single model. Models will improve, specialize and change in price, but the relationships, permissions, skills, decisions and accumulated judgment that make up a company’s intellectual property should remain under its control.

Autonomy should be earned

The benchmark also changed how I think about autonomy. The industry often presents autonomy as a feature that can be switched on. In an enterprise, it should be treated as a promotion that an agent earns.

Our framework progresses from reactive retrieval at L1 to analytical reasoning at L2, then to proactive coordination at L3, and finally to extended self-directed operation at L4. The current public suite tests only L1 and L2. We expect L3 systems to begin moving into true production over the next six months, while some more advanced enterprises are already testing them internally.

Before an agent is trusted to manage a customer escalation, renewal process or another multi-step workflow, it should repeatedly prove that it can retrieve the right facts, reconcile evidence across systems, preserve access controls, explain the basis of its answer and produce an auditable record as the work progresses.

Reliability at one level should become the entry requirement for the next. If an agent cannot read consistently, it has not earned the right to write.

What CIOs should measure

CIOs do not need another leaderboard that declares a universally smarter model. They need evaluations that reproduce the conditions under which their own AI will operate.

I would test seven things:

• Hold the model constant and compare the systems around it.
• Keep the answer fixed while increasing the amount of irrelevant data.
• Test cross-system questions that require structured and unstructured information in the same response.
• Measure token cost per correct answer, not token consumption alone.
• Run the same task repeatedly, because “worked once” is not the same as “works reliably.”
• Test permission failures and require evidence that an action can be reconstructed after the fact.
• Require the benchmark itself to be inspectable: task definitions, scoring, traces and failure modes.

Most importantly, choose tasks that matter to the business. Ask which product problems are putting renewals at risk, what commitments were made on the last customer call, or which support cases have breached the terms of their actual service agreements. A polished demo can hide weak architecture. A question grounded in your operating reality usually cannot.

Building an enterprise benchmark changed the question I ask about AI. Instead of starting with, “How intelligent is the model?” I now ask: “Can the system assemble the right context, at the right moment, for the right person and prove that it did so?”

The trillion-dollar enterprise AI bet is not how many tokens we can squeeze into a context window. It is how few of the right tokens we need to deliver a precise, efficient and safe answer.

The conversation around AI agents has shifted remarkably fast. A year ago, I was mostly worried about what an AI system might say. Now I am increasingly worried about what it can do.

That distinction changes my security model.

An agent that gives me a bad recommendation creates a problem I may still have time to catch. An agent with credentials and tools can turn the same bad decision into an API call, a privilege change, a deleted resource or an external transaction before anyone realizes what happened.

I saw a particularly uncomfortable example in OWASP’s GenAI exploit roundup: an AI agent connected to a real inbox began deleting messages and reportedly continued despite attempts to stop it. There was no sophisticated attacker required. The combination of live access, destructive capability and insufficient confirmation was enough.

That is why I don’t think “human in the loop” is specific enough anymore.

I want to know exactly where the human — or another independent authorization control — is in the loop.

I would let agents autonomously perform thousands of low-risk actions. But there are five actions where I would deliberately put another decision between the agent’s intent and execution.

1. Move money

I am comfortable letting an agent analyze invoices, reconcile accounts, identify anomalies, prepare a transaction and recommend that a payment be made. I would not let the same agent unilaterally complete a consequential financial transaction.

The reason isn’t simply fraud. The agent could be operating on manipulated data, an indirect prompt injection, incorrect business context or a perfectly legitimate instruction that it interpreted incorrectly.

The approval request should therefore expose the transaction itself: Pay $X → recipient Y → from account Z → because of instruction A.

The second approver should be authorizing that exact transaction, not approving a vague statement such as “complete the payment workflow.”

This is one place where I think we need to borrow more aggressively from financial controls. The person — or system — that prepares a consequential transaction should not also be the final authority that releases it.

The same principle should apply to an agent.

2. Delete production data

This is the easiest line for me to draw.

I want agents helping operations teams identify stale resources, clean environments, investigate incidents and recommend remediation. I don’t want an agent translating “clean this up” into an irreversible production action without another control validating what “this” actually means.

OWASP describes exactly this class of failure in its guidance on Excessive Agency: an AI system can become dangerous when excessive functionality, permissions or autonomy allow it to perform damaging actions. OWASP specifically recommends human approval for high-impact actions.

For a destructive action, my approval screen should tell me:

What will be deleted? What depends on it? What is the blast radius? Can I recover it?

“Delete these 12 identified resources after these dependency checks” is reviewable.

“Clean up unnecessary production resources” is not.

The difference matters because I don’t want a human approving the agent’s interpretation. I want the human approving the actual action.

3. Change privileges

This is where I become even more conservative.

Imagine an agent reaches a point in a workflow where it cannot continue because it lacks permission. It decides the permission is necessary, requests additional access and then has a path to grant or activate that access itself.

At that point, the agent is no longer merely executing within an authorization boundary. It is participating in defining its own boundary.

I would separate those decisions.

An agent can tell me it needs more authority. It cannot be the authority that decides whether it gets it.

That means changes to IAM roles, privileged group membership, credentials, security policies and sensitive tool permissions need an independent authorization path.

This is also why least privilege becomes more important, not less, with agents. OWASP recommends that agent tools operate with the minimum functionality and permissions necessary and that downstream systems enforce authorization rather than trusting the model to decide whether an action should be permitted.

A compromised read-only agent gives me an incident. A compromised agent that can make itself an administrator gives me a very different incident.

4. Expose sensitive information

This one is deceptively difficult because an agent doesn’t need an “exfiltrate data” tool to cause a disclosure.

It may attach a document to an email. Populate a support ticket. Paste source code into an external service. Send customer information through an API. Give another agent information that the second agent was never supposed to receive.

Each step can look legitimate.

The EchoLeak vulnerability in Microsoft 365 Copilot demonstrated why this boundary matters. A specially crafted email could influence the AI system and create a path toward disclosure of sensitive organizational information without the user needing to click a malicious link or attachment.

Before sensitive information crosses an established trust boundary, I want another decision point that answers four questions:

What data is leaving? Who is receiving it? Why do they need it? Where is it going?

This is where approval design matters almost as much as approval itself. If the agent controls the description shown to the approver, “Send requested information to vendor” might conceal a very different underlying action.

The security control therefore needs to derive its approval context from the actual transaction — destination, data classification, tool call and requested scope — not merely from the agent’s natural-language explanation.

Otherwise, we have put a human in the loop without giving that human enough information to make a security decision.

5. Create or delegate privileged access

This is the boundary I expect security teams to wrestle with most as multi-agent architectures become common.

A modern agent workflow can quickly become:

User → Agent → Delegated Agent → Skill → Tool → Resource

The original agent may have legitimate authority. But what happens when it delegates a task to another agent that invokes a tool holding broader credentials?

The question I care about is not simply whether every component is authenticated.

It is whether the authority exercised at the end of that chain still represents what was authorized at the beginning.

I would therefore require another authorization decision when an agent creates privileged access or materially expands or delegates consequential authority.

And I would make that approval very specific:

What authority is being delegated? To whom? For what task? For how long? Can it be delegated again? What happens to it when the task ends or the original authorization is revoked?

OWASP’s AI Agent Security Cheat Sheet addresses excessive autonomy, tool abuse, privilege boundaries, sensitive-data exposure and multi-agent risks. Those risks become harder to reason about as an agent’s authority travels through more components.

Authentication tells me which agent is acting. Authorization needs to tell me whether this particular action, with this particular authority, is still allowed.

Those are not the same question.

A second approval doesn’t always mean a second person

There is one part of this argument I don’t want misunderstood.

I am not proposing that enterprises hire armies of people to click “Approve” every time an agent wants to do something.

That would destroy the value of automation.

For the highest-risk actions, a human approval may absolutely be appropriate. In other cases, the second decision could come from an independent policy engine, authorization service, transaction-control system or another deterministic security control that the initiating agent cannot modify or bypass.

The NIST AI Risk Management Framework takes a risk-based approach to managing AI risks and emphasizes governance throughout the AI lifecycle.

That’s how I think about agent autonomy as well.

The question isn’t: Should this agent be autonomous?

The better question is: Which actions can this agent perform autonomously, and which actions require an independent decision?

For me, the dividing line is increasingly clear.

Let agents search, analyze, summarize, correlate, recommend and prepare. Let them autonomously execute actions that are bounded, observable, reversible and already inside clearly established authority.

Add friction when an action can move money, destroy production data, increase privilege, expose sensitive information or create authority that propagates beyond the original task.

Most importantly, I would never design a workflow where the same agent can propose a consequential action, acquire the authority necessary to perform it, approve that authority and execute the action.

That isn’t autonomy I can govern. It’s self-authorization.

And when AI agents can operate at machine speed across multiple connected systems, a few seconds of independent authorization may be some of the cheapest incident prevention we can buy.

In cybersecurity, engineering velocity has become a competitive advantage. Threats and vulnerabilities evolve quickly, customer security needs keep changing and organizations that respond faster are more likely to stay ahead. Across the engineering organizations I have led in cybersecurity, SaaS, mobility and insurance, I have seen how lengthy development cycles and unnecessary waiting make it harder for teams to keep pace.

Tooling can help, although in my experience it is rarely what makes the biggest difference. The pattern that consistently cut release cycles from weeks to days was giving teams end-to-end ownership of their services, including development, QA, operations and on-call responsibilities. Once the people writing the code carry the consequences of it in production, they invest in the automation, testing and observability that make frequent releases safe.

Look first at where work waits

In almost every organization I have assessed, the time spent actively working on a change is a small fraction of the time it takes to reach production. Work waits for review, for a test environment, for a decision or for another team’s dependency. That is why, when an organization tells me it needs to move faster, one of the first things I look at is where the work is waiting.

At one company I worked with, lead time on paper looked reasonable, but the gap between “code complete” and “in production” averaged around eleven days. The cause was a single shared staging environment that every team queued for, and we found it because we started measuring the wait time between stages rather than the work time inside them. Moving to ephemeral, per-change environments removed most of it, and it cost far less than the reorganization we had been considering.

In my experience, decision latency is another under-diagnosed constraint in engineering organizations. At one company where I was involved in modernizing a legacy platform, we cut deployment times by roughly 60%, with the biggest improvement coming when we retired the weekly release approval meeting and let teams ship behind feature flags. The engineering work had been ready for months, and decision latency was the bottleneck.

That experience is why I count approvals when I look at an engineering organization. I want to understand how many people must agree before a change reaches customers and what those approval steps are achieving. Once unnecessary waiting is removed, practices such as trunk-based development, automated testing that you trust, small changes and decoupling deployment from release can have a much greater effect.

Cybersecurity adds real pressure on both sides because the constraints are heavier, including audit evidence, customer security reviews, tenant isolation and the potential blast radius of a bad change. The urgency is also greater because when a new technique or vulnerability appears, customers expect products and content to reflect it within days. That combination makes engineering velocity part of how a cybersecurity organization competes.

For CIOs and CTOs, the starting point is quite practical. Map the path from idea to production and measure the time between steps, rather than focusing only on the time spent doing the work. In many of the organizations I have worked with, this has exposed problems that were far less expensive to fix than expected.

Give teams ownership and set clear guardrails

Across the organizations I have led, clear ownership has been essential to moving quickly. In practice, that means every service has a named team accountable for it in production, with the  authority to make decisions about its internal architecture, libraries, testing approach, sequencing and when to deploy.

Once the people writing the code also carry the consequences of it in production, they have a direct reason to invest in the automation, testing and observability that make frequent releases safe. This is one of the reasons I believe production ownership matters so much when an organization is trying to increase engineering velocity.

Cybersecurity still requires clear boundaries, and I keep a small set of areas non-negotiable and centrally owned. These include identity and access, data classification and handling, tenant isolation, contracts between services and anything carrying a compliance obligation. That list should be short enough that every engineer can recite it.

The mechanism matters as much as the policy. I prefer guardrails that are built into the way teams already work, including pipelines with security scanning, infrastructure modules that are secure by default and templates that make the compliant path easy to follow.

When deciding how much process a particular change needs, I start by looking at how reversible it is. I also consider the potential blast radius, whether the change touches identity, tenant isolation or customer data, and whether we would see a failure before it became visible to a customer. In cybersecurity, those factors can determine how quickly a change can responsibly move.

I saw this work with a new discovery and recommendation surface in a learning product. We shipped three variants behind flags to a small percentage of traffic and killed two of them within a fortnight. The cost of being wrong was a mediocre experience for a few hundred users for a few days, and the change was fully reversible.

Authentication and multi-tenant isolation require more care because mistakes in those areas can result in a breach. In the organizations I have led, that kind of work gets threat modelling, design review, a staged rollout and a written rollback plan before implementation proceeds. Taking additional time makes sense when the potential impact is that high.

Reversibility and blast radius help teams decide how much process a change needs. This allows teams to increase engineering velocity while maintaining the quality and trust customers expect.

Measure whether faster delivery is producing better outcomes

I never look at speed on its own. Throughput measures such as deployment frequency and lead time for change only mean something next to stability measures such as change failure rate and time to restore. If throughput rises while failure rate and restore time hold or improve, the system is genuinely getting better.

The DORA research program has had the most influence on how I think about this. Its research over the years has reinforced the connection between the practices that allow teams to deploy frequently and those that help them operate reliable systems. The 2025 State of AI-assisted Software Development report sharpened that thinking further by describing AI as an amplifier of the strengths and weaknesses already present in an organization.

That finding matches what I see in engineering organizations today, and it reflects a broader challenge around why faster coding does not necessarily translate into faster delivery. AI accelerates the writing of software. An organization still needs the platform, testing, ownership and delivery practices required to absorb that additional change.

This is why I am also cautious about AI code-acceptance rates as a measure of engineering productivity. Story points, sprint velocity, lines of code and pull request counts can be equally misleading when used in isolation because they measure activity and can easily become targets themselves. Individual developer dashboards can be especially damaging because they encourage people to protect their numbers, while much of the value I have seen engineering teams create comes from how people work together.

The SPACE framework developed by Nicole Forsgren, Margaret-Anne Storey and their co-authors is a useful corrective to single-metric thinking about developer productivity. It considers satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. That multidimensional view is much closer to how I have seen productive engineering organizations actually work.

Beyond throughput and stability, there are two outcome signals. The first is the time from a customer or threat signal to a shipped change because that is the number the business actually feels. In cybersecurity, a new threat, vulnerability or customer security requirement can create an immediate need to respond. The second is whether the outcomes we expected the work to influence have actually changed. Shipping more of the wrong thing faster is still the most expensive form of velocity.

For CIOs and CTOs looking to increase engineering velocity, my advice is to look first at where work waits. Map the path from idea to production and measure the time between steps. Buying tooling before removing those queues can simply automate the wait, and individual speed targets can make teamwork harder.

I would also protect the investments that make speed sustainable, including testing, observability and production ownership, and avoid starting with a reorganization. In my experience, a reorganization is an expensive response to what is often a queueing problem, and it can reset the trust an organization needs to move quickly.

Engineering velocity in cybersecurity comes from reducing unnecessary waiting, giving teams clear ownership, applying governance according to risk and measuring whether faster delivery is producing better outcomes. When those conditions are in place, engineering teams are better able to respond to new threats and changing customer needs while maintaining the quality and trust customers expect.

Twenty-two rows. That was the AI inventory in a board pack I read last year, and it was a good one. Every system named, every owner listed, every risk rating filled in and colour-coded. Somebody had worked hard on it, and the committee approved it in four minutes.

I kept looking for a column that wasn’t there. The pack could tell you who owned each system. It could not tell you who was allowed to say no to one.

Those sound like the same thing right up until the morning they aren’t.

1. Signal. AI has moved inside the operating model

When a director asked me last spring what our AI risk was, I gave her the honest answer. Which was that I no longer knew, because the question had changed shape while everybody was still busy answering the old one.

Twelve months earlier I could have told her precisely. We had a model inventory, a review process and a register entry saying the right things about bias and data quality. All of it was true, and all of it had quietly stopped being the point, because the systems had moved inside the work. They chose which cases went to which queue, which prices moved and which alerts a human ever saw.

Foundry’s State of the CIO 2026 report puts the shift plainly. Roughly three-quarters of leaders say AI is already reshaping how their operations run, and the number climbs higher in financial services. Around seven in 10 expect deeper involvement in agentic systems this year.

Don’t let those figures become the story. Adoption numbers are the easiest thing to produce and the least useful thing to govern from. Your board can watch that percentage climb for three years and learn nothing it can act on. The signal underneath is simpler. AI has stopped helping people finish tasks and started shaping how work gets allocated, how rules get applied and what the company does next.

Which means your board needs a better question than how much AI do we have. It needs to know which decisions have changed hands.

2. Consequence. Authority travels faster than accountability

Accountability used to be visible. Person, role, authority, decision. You could follow it with a finger, and when something went wrong you could find the finger.

That chain now reads: human, model, agent, system, supplier, outcome. Every link has an owner and a budget line. The decision itself often has neither.

Watch it happen. A team buys a tool to help underwriters. It starts recommending, and it’s good, so people gradually stop disagreeing. Six months later somebody switches on auto-approval below a threshold, because the review queue is a bottleneck and the numbers support it. Nothing in that story needed a bad actor. Authority moved three times, and nobody recorded any of it.

That’s board risk, not model risk. Call it authority drift. Real decision-making power moves outward while formal accountability sits exactly where somebody wrote it down in 2023.

The same study found most organisations have or plan an AI steering group, with IT sitting on the great majority of them. Only about half report a formal approval process. Structures arrive fast, because they’re easy to announce and cost nothing but a recurring meeting. Decision rights arrive slowly, because somebody has to accept them.

I once watched a company stand up three AI committees inside a year and still be unable to name one person who could stop a model.

3. Decision. Who gave the machine permission?

Your board can’t govern every AI action and shouldn’t try. Trying to do so creates a register nobody reads and a comfortable sense that the ground is covered. Insist instead that management names the material decisions.

Material means it moves customers, capital, employees, regulatory standing or resilience. The tool that writes meeting notes doesn’t qualify, no matter what the vendor promised. A system shaping credit, pricing, workforce reductions, claims handling or cyber response does. Most firms land on 15 or 20. If management returns with two, they haven’t looked. If they return with three hundred, they’ve listed systems rather than decisions.

Then, for each one, four verbs.

• Recommend. The system proposes, and a person chooses.
• Decide. The system chooses, inside limits somebody set in advance.
• Execute. The system chooses and acts, with no human in the transaction.
• Accept. Somebody carries the consequence when it goes wrong.

That last verb is where rooms go quiet, and it’s the only one that can’t be handed to a machine.

Put them together, and you’ve drawn the authority envelope. What may this system recommend, decide and execute? Where does a person pick the thread back up? Whose name sits on the outcome? It’s a dull artefact, half a page per decision, and it’s what your board should ask to see instead of the AI policy, which everyone has, and nobody reads.

4. Evidence. Show me where the authority stops

An envelope on paper is a claim. Then you ask what proves it.

Start with the system itself. If AI may approve up to fifty thousand, is fifty thousand built into the workflow or typed into a policy? Only one of those holds at three in the morning, when the queue is long, and somebody is under pressure.

Ask which exceptions have been granted. Who approved each, who accepted the risk left behind and when it expires. An exception without an expiry date quietly becomes the operating model, and eighteen months later somebody calls it legacy and asks for budget to remove it. Read the 10 oldest entries in that register, and you’ll learn more than the policy will ever tell you.

Ask how many important decisions ride on the same model, the same cloud, the same supplier. Firms with 20 AI applications regularly discover they have two real dependencies, because separate teams bought separate products built on the same substrate. Procurement records won’t show it. The architecture diagrams and the person who pays the bills will.

Ask whether the business can still decide if the service vanishes. Not whether IT can restore it, which is a different and easier question. Who does that work by hand, how long can you last without it and has anybody currently employed ever done it?

Ask what returns authority to a person: confidence dropping below tolerance, customer harm, a breach of appetite. Then look for one more that most firms lack, because their triggers came from incident management, where failures announce themselves. A drifting model doesn’t crash. It carries on answering plausibly, wrong by small margins, at volume, logging cleanly.

Finally, ask how long it takes to reconstruct one decision from end to end. An afternoon is evidence. A fortnight is archaeology.

5. Challenge. Follow the decision, not the inventory

Five questions. Directors don’t need to become engineers to ask them, and management can’t deflect them with architecture diagrams.

Which material decisions now depend on AI? A vague answer means nobody has drawn the list, which is itself the finding.

Who owns the authority for each one? Not the model owner, not the committee chair. If the answer names a team, you’ve been told who keeps the system running, not who let it decide.

How far has that authority travelled: recommend, decide or execute? Firms are usually one step further along than their paperwork claims.

What brings it back to a person? If the answer is human oversight, ask what forces the human to look while everything still appears fine.

What evidence shows the system stayed inside its limits, and how quickly can you produce it?

Answer all five for the top 10 decisions, and you’re in decent shape. Answer four and go quiet on the fifth, and you’ve found where the work is. The quiet is the useful part.

6. Horizon. Today’s approval expires quietly

The risk worth watching is expansion without reauthorisation, not a dramatic failure.

A provider swaps the underlying model in a routine release. An agent picks up new permissions because somebody connected it to another system. The business points the same tool at a bigger question, since it worked on the small one. More sensitive data joins the workflow. Reliance grows, so the review that was thorough in month one becomes a glance by month nine.

Nothing breaks. Nothing gets announced. The approval granted a year and a half ago now covers something it was never asked about.

Agentic systems will sharpen all of this, because their entire value lies in doing more without being asked each time. That’s their point, and it is also the governance problem stated in one sentence.

So the question I’d put on the agenda isn’t whether you’re monitoring continuously. It’s this. What change would make today’s approval no longer good enough? Write that answer down while everyone is calm, and you have a trigger instead of a hope.

Risk doesn’t only rise when the model changes. It rises when you quietly ask the same model to decide something that matters more.

7. Action. Map the decisions before they map themselves

One deliverable, not a framework. Most firms already have a framework, and it hasn’t helped.

Ask management for a map of the top 10–20 material AI-supported decisions. One row each. The business owner. What the AI actually does, in the four verbs. The authority limit, as a number. Who approved any exception and when it expires. The main dependency. The fallback, and who performs it. What forces escalation. Where the evidence lives.

Nine columns, two pages. It will take longer to produce than anybody expects. That delay tells you something before you read a word, because a company that fills it in a fortnight is already governing this and one that needs a quarter is still discovering it.

What comes back will show you orphaned decisions, ambiguous authority, stale approvals, exceptions nobody closed, concentration hiding behind a healthy supplier count, and a fallback that exists only on paper.

Boards don’t need to own AI. They do need to know who owns the decisions AI is now allowed to make.

AI can inherit authority. It cannot inherit accountability.

At a Fortune 500 insurer, I watched an AI agent inside the month-end close do exactly what we asked. It posted the recurring accruals. It worked the intercompany exception queue, the reconciliation that normally falls to a staff accountant. And when items would not match, it cleared them to a suspense account within the configured tolerance rather than escalating them to a human. Clearing the queue was the objective. Nobody had defined escalation as success.

Every journal entry carried the controller’s user ID. No one set out to obscure anything. The job step had been mapped to her credentials at implementation, which is how it had been done since the system went live.

Segregation of duties had become a fiction. The control requires a named preparer and a named approver. The agent did both, under one identity: it prepared the entries and it disposed of the exceptions. The record named the controller for each. She had done neither. When internal audit walked those entries the following quarter, they asked her to explain postings she had never seen.

None of this was a model failure. The agent was accurate. It was authorized. Every entry looked clean, which is exactly why nobody caught it.

Here is the number that should frame this year. Gartner expects 40 percent of enterprise applications to carry task-specific AI agents by the end of 2026, up from under 5 percent in 2025. Okta finds only 10 percent of organizations have a strategy for managing the agents they are already running. And Deloitte, surveying more than 3,000 leaders across 24 countries, puts mature agentic governance at 21 percent against 74 percent who expect to be using agents within two years.

Adoption is racing. The control model is not. Every one of those agents inherits a permission model built for a person clicking a button, which means the question that matters is no longer whether an agent can do the work. It is whether, when it does, anyone can say who authorized it. McKinsey frames the same shift from the governance side: organizations can no longer concern themselves only with systems that say the wrong thing. They now have to contend with systems that do the wrong thing.

What actually broke?

ERP, CRM and core administration platforms rest on four assumptions so foundational that nobody writes them down: identity, permission, action, receipt. Each one places a named human at the center. An agent breaks all four at once, and none of them repairs itself.

Intent. A person submits a bounded request, and the request is the transaction boundary. An agent receives a goal and decomposes it into steps at runtime. On a state eligibility modernization program, we gave an agent one goal: clear the verification backlog. It re-ran electronic verification, and where a federal source returned no match, it advanced the case toward closure and generated the notice. Nobody listed that step. Nobody had to. It is a defensible reading of clear the backlog, and it is precisely what the agent was rewarded for. But a no-match is not a finding of ineligibility. It triggers a reasonable opportunity period, and closure carries notice and appeal rights that attach to a determination, not to a data lookup. The rule that breaks here is least privilege. You cannot scope permissions to an action set nobody enumerated in advance.

Authority. Applications grant entitlement to a person. It is standing and role-based, and that person’s judgment is the unwritten limiter on it. At a specialty retailer, I watched a quoting agent go into Salesforce to compress turnaround at quarter close. The approval matrix was intact: manager above fifteen percent, director above twenty-five. None of it fired. A submission action in the user interface triggers a Salesforce approval process, and the agent wrote to the record through the API. It never submitted. An integration user provisioned with more rights than anyone intended bypassed the validation rules and record locks that would ordinarily catch it.

Salesforce’s own architects are blunt about the mechanism. The client credentials flow, they warn, creates a service-account pattern in which every call runs as a single identity, and both per-user permissions and the audit trail are lost along the way. Their guidance on identity propagation goes further: when an agent calls a downstream service using client credentials, the request carries the agent’s service identity rather than the end user’s, which makes per-user authorization and audit trails impossible.

That approval process was never a security control. It was a workflow convention that humans had no reason to route around.

Logic. Business rules used to be a configuration artifact: versioned, testable, under change control. At a health insurer, I traced one authorization threshold for advanced imaging to three separate homes. Configured in the core administration platform. Routed in the orchestration layer. And written in plain English inside the agent’s instruction, as a sentence somebody added during a sprint. Medical policy tightened the first. Nobody touched the third, because the third is not a configuration item. No change control that clinical policy or compliance has ever seen covers it.

In every payer program I have worked, that drift runs one direction only. An agent cannot lawfully deny since adverse determinations require review by a licensed clinician. So the exposure is silent over-authorization against a threshold the organization believes it already tightened, surfacing months later through a delegated vendor audit or a utilization variance that finance notices before medical management does. Then someone asks the question with no good answer: how long, and how many.

Evidence. The log names whichever credential was presented. That is the insurer’s close, and it is the most measurable of the four failures. The Cloud Security Alliance found that 68 percent of organizations cannot clearly distinguish between human and AI agent activity, even as 73 percent expect agents to become vital to operations within a year.

An agent without a delegation chain is not automation. It is an unsigned transaction.

Table 1. The same failure, four industries

Industry	System	What the agent did	What broke
Financial services	SAP, month-end close	Cleared exceptions to a suspense account under the controller’s user ID	Evidence. Segregation of duties asserts a preparer and an approver; the record showed one person as both
Retail	Salesforce, quoting	Wrote discounts to the record through the API, never submitting for approval	Authority. A standing entitlement on an over-provisioned integration user, with no per-action scope
Healthcare payer	Core administration, utilization management	Auto-approved against a threshold medical policy believed it had tightened	Logic. One rule in three places, with change control covering one of them
Federal	State eligibility	Advanced cases toward closure on a data-hub no-match	Intent. An unbounded goal, executed through steps nobody enumerated

Why didn’t the controls catch it?

Because in every one of these cases, the controls worked as designed. That is the uncomfortable part, and in the programs I advise it is the finding that changes the conversation. This is not a problem the CIO can hand to the security team and consider closed.

Consider the insurer’s segregation-of-duties conflict. It never appeared in the access risk analysis, and the tooling did not fail. Most implementations exclude technical and service accounts from risk-analysis scope entirely, on the reasonable historical assumption that a service account does not exercise judgment. Nobody ever analyzed the account. The conflict was not missed. It was never in view.

Most writing on agent risk assumes an adversary. The OWASP Top 10 for Agentic Applications, built with input from more than 100 practitioners, catalogs goal hijack and memory poisoning and places Identity and Privilege Abuse third on the list. What I see most often is duller. Nobody attacked the payer. A threshold governed in one of three places simply drifted, and it took a vendor audit to notice.

The pattern holds across all four, and each one breaks a control an auditor already asks about. Intent breaks least privilege. Authority breaks separation of duties. Logic breaks configuration management. Evidence breaks non-repudiation. Those four are the spine of any controls walkthrough, which is precisely why this arrives on the CIO’s desk rather than staying in the security function.

None of these produced a headline. They produced audit findings and rework: a control deficiency to disclose, authorizations to re-adjudicate, cases to reprocess, notices to reissue. That cost lands on the CIO’s budget and the CFO’s certification, not on the security team’s incident log.

The repair is the same in all four cases. Stop letting an agent borrow a person’s credential, and start recording who stands behind it.

What has the market already conceded?

What I find most striking this year is not that a vendor shipped something. It is that vendors, standards bodies, regulators and advisers all converged on the same requirement within roughly six months of each other, without coordinating.

Microsoft made the human sponsor mandatory. Every agent identity carries a named business owner accountable for it, and if that person leaves, sponsorship transfers to their manager so accountability never quietly disappears. SAP now governs an agent lifecycle that runs from proposed to evaluated to approved to active to retired, with a verification badge controlling which agents are cleared for use. And Okta has moved access decisions out of individual applications and into the identity layer, with AWS, Google Cloud and Salesforce behind the effort.

Google reached general availability this month with the bluntest statement any vendor has made. Its agent identity documentation argues against the service account directly: agent identities are not shared, cannot be impersonated, and permit no long-lived keys. Every action resolves to a cryptographic ID rather than to whoever the credential once belonged to. That is the insurer’s close, described by a hyperscaler as a design flaw to engineer out.

The pattern held into this month. At Black Hat on 4 August, Rubrik unveiled a service that grants an agent access one tool call at a time, minting a short-lived token for each call and eliminating standing permissions outright. Its general manager for AI put the diagnosis in one line: the access models we built for humans were never designed for autonomous actors.

The standards work is further behind, and honest about it. NIST’s National Cybersecurity Center of Excellence opened a concept paper on software and AI agent identity and authorization in February and closed comment in April, explicitly seeking input on agent auditing, non-repudiation and prompt-injection controls. The gap is officially acknowledged. The standard is not written.

Regulators moved in a way most leaders misread. Brussels deferred the EU AI Act’s high-risk obligations in June, pushing them to 2027 and 2028, and the headline everyone absorbed was that the AI Act had been delayed. Half true, and imprecise in a way that matters: the Article 50 transparency duties, including telling people when they are interacting with an AI system, were untouched. They took effect on 2 August and are live now.

The advisory community has landed in the same place. BCG, writing on scaling agents in regulated industries, tells CIOs to define clear approaches to agent identity, authority and accountability: what agents can access, what actions they can take, and how those actions remain traceable. Booz Allen, surveying 105 federal IT and cybersecurity decision makers this spring, found 22 percent who have not determined who bears responsibility when an agent causes an incident.

Read those together and the picture is unambiguous. The identity layer has been rebuilt around delegated, sponsored, per-action authority. The business applications those agents act inside have not moved at all.

The plumbing now encodes accountability. The applications still do not ask for it.

Where should CIOs start?

None of this requires a reorganization. The leaders I see getting ahead are not doing more; they are doing six things in order, on the bounded use cases where they can afford to learn.

1. Inventory the agents. Enumerate every agent acting inside a system of record, the identity it runs under, and its standing entitlements. Only 23 percent of leaders report full visibility into the agents already running in their environment, and most organizations I work with cannot produce that list today, and producing it is usually the moment this becomes real to the executive team.
2. Bind identity to a named human. Retire shared service accounts and borrowed logins. Every agent gets its own identity with a named sponsor who answers for it. This is the change that fixes the insurer’s close because the document header stops naming a bystander.
3. Scope authority per action. Short-lived, time-bound, just-in-time. And move approval enforcement out of the workflow layer into the authorization layer, where an API call cannot walk around it. This is the step I almost never see taken, and it is the one that fixes the retailer.
4. Consolidate the logic. The instruction becomes a configuration item: versioned, evaluated, approved and reviewed alongside the rules engine. If a threshold changes in medical policy, it changes in all three places or it changes in none.
5. Instrument the evidence. The transaction record carries the delegation chain, meaning agent, sponsor, instruction version and model version. Without those four, every incident investigation starts from zero.
6. Graduate autonomy deliberately. Sanctioned, then supervised, then autonomous, with sunset as a real state rather than a euphemism for neglect.

The gates between rungs are what make the ladder operational rather than decorative. Sanctioned to supervised requires a named sponsor and a declared scope. Supervised to autonomous requires an evidence record showing the agent stayed inside it. And sunset is not a failure state. It is what happens when an agent stops earning the authority it holds, which most organizations have no process to detect.

Do these in order and autonomy compounds. Skip them and you join the more than 40 percent of agentic projects Gartner expects to be canceled by the end of 2027, undone not by weak models but by escalating cost, unclear value and inadequate risk controls.

The takeaway

The most common strategic mistake I see this year does not look like a mistake. Leaders are granting agents authority inside systems whose architects assumed a human held it, and then treating the resulting mess as a technology problem. It is not. It is the same failure I have watched for thirty years, from trading floors to Medicaid programs: business strategy, IT and organizational culture are not architected to move together, and the technology simply industrializes the gap.

I recommend a reframe most leaders resist at first. Guardrails here are not friction. You can give an agent that proves who authorized it more autonomy, sooner, and with far less anxiety than one that cannot. The delegation chain is what makes acceleration survivable.

So put three questions to your team this week. None of them requires a program to answer, and all three will tell you more than a maturity assessment.

Table 2. Three questions, and what a good answer sounds like

Ask your team	A good answer sounds like
When an agent acts in our ERP, whose name does the log carry, and is that person accountable?	A named sponsor who can explain the action, rather than a service account nobody owns
Which of our approval controls are genuine security boundaries, and which are workflow conventions?	A tested list, proven by attempting the action through the API rather than the user interface
Which of our agents have earned the authority they hold, and which should we sunset?	An evidence record for each agent, and a retirement date for the ones that cannot produce one

The agent is the new user. Your applications have not been told.

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. 

Every AI roadmap review I sit through this year eventually lands on the same question: which technology stack/model should we use? It’s the wrong first question to start with. Gartner projects that by 2027, organizations will deploy small, task-specific AI models at roughly three times the volume of general-purpose large language models. In my experience running agentic pilots across a large enterprise, those specialized models succeed or fail almost entirely on something that has nothing to do with which model you picked: whether your own business actually agrees on what its data means.

That’s a harder problem than it sounds, and it’s not the same problem as data quality. My team has spent years measuring data quality the traditional way — is the field populated, is the number accurate, is the record deduplicated. Those checks matter, but they answer a narrower question than the one agentic AI actually depends on. IBM’s own explainer on the topic puts it well: a semantic layer is the piece of enterprise architecture that translates complex, technical data structures into the business terms people actually use day to day. Clean data can still be semantically ambiguous. A field can be perfectly accurate and still mean three different things depending on which team is looking at it.

Why accurate and understood are not the same thing

I recently worked with a large MedTech firm where I led data and governance strategy to build AI agents; the term “active customer” existed in three separate systems, defined three separate ways: one team counted anyone with an account open in the last 90 days, another counted anyone with a transaction in that window, and a third counted anyone who hadn’t formally churned. Every one of those definitions was technically accurate — the underlying data was clean, well-governed and correctly populated. None of them agreed with each other.

For years, that ambiguity lived quietly inside dashboards, where a human analyst could squint at a number, ask a colleague which definition it used and adjust their interpretation accordingly. Agentic AI removes that human buffer. When an agent pulls “active customer” to decide who gets a retention offer or who gets flagged as a churn risk, it doesn’t know there are three competing definitions sitting behind that phrase — it picks whichever one the underlying table happens to expose and acts on it with full confidence. The output looks decisive. It’s just decisively wrong for two-thirds of the organization.

What happens when agents inherit your organization’s ambiguity

I learned this the expensive way. When we ran an early agentic pilot on a customer retention workflow last year, the agent flagged a segment of accounts as “at-risk” that the finance team didn’t recognize as at-risk at all. It wasn’t a model problem — the reasoning was sound given the data it was pointed at. It was a “definitions” problem: sales, finance and customer support each had their own notion of “at-risk,” built into three different systems at three different points in the company’s history, and nobody had ever forced them to reconcile. We ended up spending more time aligning those definitions across departments than we spent building the agent itself.

That experience isn’t an outlier. Informatica’s 2026 survey of 600 global data leaders found that half cite data quality as their top barrier to deploying agentic AI, and 57% call data reliability the wall standing between a pilot and real production use. In my own postmortems, a meaningful share of what gets logged as a “data quality” issue in surveys like that is really a semantic issue wearing a data-quality costume: the data was accurate; it just didn’t mean what the agent — or the team reviewing its output — assumed it meant.

This matters more for agentic systems than it ever did for reporting, because agents don’t just surface an ambiguous number for a human to sanity-check. They act on it. A dashboard with a wrong “at-risk” count is an annoyance. An agent that auto-triggers retention offers, or worse, credit decisions, based on the wrong definition of “at-risk” is a business risk with a dollar figure attached.

The same pattern shows up anywhere a term carries more weight than its plain-English simplicity suggests. “Revenue” means something different to a sales team tracking bookings than it does to finance tracking recognized revenue under accrual accounting — a distinction that rarely causes trouble in a quarterly business review, where a human in the room can ask which number is being quoted. Hand that same ambiguity to a pricing or forecasting agent, and it will pick one definition, apply it consistently and confidently, and generate a forecast that’s internally coherent and organizationally wrong. The failure mode isn’t a crash or an error message. It’s a plausible-looking number that nobody thinks to question until it’s already driven a decision.

Build the semantic layer before you scale the next model

The fix isn’t a bigger model, and it isn’t even primarily a bigger data quality initiative, though that’s the instinct most organizations reach for first. It’s a deliberate semantic layer — the shared, machine-readable set of business definitions that sits between your raw, clean data and whatever model or agent is querying it. In practice, that means going through a sequence most data teams skip because it’s slower and less exciting than deploying the next pilot.

Start by auditing and cataloging the terms most central to your highest-priority use case — not every term in the business, just the three or four that the agent will actually touch. Force the departments that use those terms to sit in a room and agree on one definition, even when that conversation is uncomfortable and political, because it usually is. Then encode that agreed definition somewhere machine-readable and enforced — not just written down in a glossary document nobody opens again after the kickoff meeting — so every model, dashboard and agent that touches that term resolves it the same way.

None of this needs to wait for a multi-year data governance overhaul, and I’d actively discourage treating it that way. The mistake I made early on was assuming semantic work had to be comprehensive to be useful — mapping every term across every system before touching a single agent. It doesn’t. Scoping it tightly to one workflow, getting the two or three business functions that actually touch that workflow to agree, and encoding that narrow agreement is a project measured in weeks, not quarters. The comprehensive enterprise glossary can, and probably should, come later, built one validated use case at a time rather than designed top-down in a conference room before anyone has tested it against a real agent.

CDOs and CIOs would have to ensure that this is also a mandatory shift for data teams themselves, not just a technical build. The job used to be building reports and charts for humans to interpret with their own judgment layered on top. It’s increasingly about building and maintaining the context that lets a machine interpret data correctly without a human in the loop to catch the ambiguity. That’s a different skill set than most data teams were hired for, and it’s worth saying so explicitly when planning headcount and training for the next year, rather than assuming the existing analytics team will absorb it by osmosis.

The organizations that come out ahead in the next phase of agentic AI won’t necessarily have access to a better model than their competitors — most of us will be drawing from a similar, increasingly commoditized set of models within the next year or two. What they’ll have is a semantic foundation clear enough that a smaller, specialized model can act on it with confidence, and a team that already went through the unglamorous work of agreeing, in writing, on what the business actually means by its own words. That’s a much harder thing for a competitor to copy than a model subscription — and it’s the argument I now make first in every AI budget conversation, well before anyone asks me which model we’re using.

To get the most out of generative and agentic AI systems, enterprises are giving them broad access to business data. This process, however, is not simply a matter of opening the data floodgates and letting AI do its thing; it raises some very important governance questions that CIOs need to address.

For instance, if an employee does not have permission to open a particular document, should they be able to obtain its contents by asking an AI tool? After all, conventional access controls govern how people access information at its original location, but AI systems can draw from information copied from source systems and stored in data lakes and vector databases.

That can create a gap between the permissions applied to the source data and the information an AI system can retrieve in response to a user’s question. What about the issues related to information such as HR records, payroll data, patient health information and intellectual property, for example?

It’s perfectly plausible that an employee may not normally have access to the company’s salary spreadsheet. But if that data has been added to the data used by an internal AI system without those access rules being carried forward, that same employee may be able to ask the system for salary information and receive an answer regardless.

How AI draws on enterprise data

To understand how this can happen, it helps to look at the way AI systems access enterprise data. Typically, LLMs have a training cutoff date, and therefore may have no automatic access to information created beyond that point.

Yet, contemporary organizations are highly data-driven, and AI systems need to be constantly updated. The way around this potential information bottleneck is to make newer or internal information available by converting it into numerical representations and storing it in a vector database.

When a user asks a question related to that data, retrieval-augmented generation (RAG) can search it for relevant information and incorporate it into the AI’s response. This allows an internal AI system to appear informed about recent or organization-specific information without the underlying model being retrained. Crucially, decisions about which data enters the vector database can shape subsequent AI output.

In our scenario, the employee does not need to open the salary spreadsheet itself. They only need to ask a question that prompts the AI system to retrieve relevant information from it and generate an answer. This is why controls applied only to the original file may no longer be enough.

This doesn’t mean the model itself is unsafe; the issue lies in the pipeline that feeds it. The AI system does not “know” who is allowed to see what; it simply retrieves whatever content sits in the vector database that appears relevant to a query. Done well, this process should carry the original access permissions forward at every stage: when data is ingested from source systems, when it’s indexed for retrieval, and when the AI generates a response, so that only content the requesting user is authorized to see is ever returned. When that permission mapping is done properly, an AI system is no more of a governance risk than a well-configured search index. The problem CIOs need to solve is ensuring that mapping happens consistently, rather than assuming it happens automatically.

Building governance into the AI pipeline

Another big issue is that data supplied to an AI system can affect the accuracy of its answers and, by definition, the information it exposes. In one case in Canada, a tribunal found Air Canada liable after its website chatbot gave a passenger incorrect advice about a bereavement fare.

The chatbot told the passenger that he could apply for the discount after buying their ticket and completing their travel. Air Canada’s written bereavement-travel policy said that requests could not be made after travel had been completed. The passenger relied on the chatbot’s information, then brought a claim when Air Canada refused the discount and won. As the American Bar Association noted at the time, “companies remain liable for the actions of their AI tools and should put into place adequate internal policies for their accuracy and other considerations.”

The solution to these various important issues lies in better governance. The starting point is the source data, along with the rules and processes that apply before information is copied into a data lake or made available to an AI system. This is only possible if there is a clear inventory of the files and objects held across relevant source systems. Data can then be selected based on factors such as location, file type, date of creation or its relevance to the intended AI use case, among other considerations.

At the same time, older information or file types that are irrelevant to the intended AI use case can be excluded before data is copied onward. The selected data can be hosted in a designated area of the data lake for further processing. Maintaining a log of those movements creates a record of which information has entered the downstream AI pipeline. If, at some point, an explanation or proof of activity is required, that record can help in investigating how a particular document became available to an AI system.

Ideally, and before approving a new AI initiative, CIOs need to ask some important questions. For example, what information will the system be able to access, and where has it come from? How has the organization decided that it is relevant to the intended use case? Is it current? Has information that is outdated or unnecessary been excluded?

The aim must be to ensure that the permissions applied to the original document are reflected when an AI system searches for and returns information. Without these controls, an internal AI tool could quite easily become an unintended route around existing and very important access controls.

Many companies are rushing into “AI-first” mandates right now. We’ve seen this pattern before. A decade ago, it was “cloud-first,” and it led to the same outcome: Fast adoption, thin governance and a wave of security and cost problems that took years to unwind. By 2019, OMB had to formally pivot federal policy from cloud-first to cloud-smart, not to slow adoption down, but to make it sustainable.

The lesson isn’t “move slower.” It’s “don’t generate operational debt in the name of speed.” That’s the lens I want to apply to AI adoption today, not as criticism of any one company’s approach, but as a pattern I think every technology leader is watching play out in real time.

What AI first gets right

The urgency is real. Competitive pressure is real. Waiting for perfect governance before adopting AI is not a serious strategy; companies that sit out lose ground they won’t get back. AI-first, as an instinct, is correct.

AI enabled: the step before AI first

Before an organization can responsibly go AI-first, it has to be AI-enabled: employees have access to sanctioned tools, data is structured for AI consumption and basic guardrails are already in place. AI-first without that foundation isn’t acceleration; it’s improvisation. Most of the ungoverned adoption happening today isn’t a failure of AI-first as a strategy; it’s organizations attempting AI-first while still being, at best, AI-enabled. Getting the sequence right, enabled before first, is itself a form of AI-smart.

Where it breaks down

The failure mode isn’t adoption; it’s unstructured adoption, adoption without a foundation to build on, without a path to scale and without security and accountability built in from the start. AI-smart isn’t a slower version of AI-first. It rests on one foundation and four pillars: A defined context to build on, a path to scale what works, security controls that hold up under agentic risk, clear governance over who owns what, and business value that justifies the exposure and existing tools transformation. Take away the foundation and the pillars have nothing to stand on; take away any one pillar and the structure leans.

The foundation: Context

Being AI-enabled gets an organization to the starting line, tools in place, data structured, guardrails established. Context is what turns that general readiness into a decision for a specific solution: What this particular AI system is allowed to touch. It’s the business data, systems and permissions a given solution is scoped to, not an implicit boundary inherited from whatever access the underlying service account happens to have, but an explicit one someone has deliberately set.

Getting context right, concretely, means being able to answer:

• What data can this solution see, and where does that data live?
• What systems can it call, and what actions can it take once it’s there?
• Who is it acting on behalf of, and does its access match that person’s or team’s actual permissions?

Where to start: The gate

Before any of the four pillars matter, a solution has to clear one checkpoint that AI needs as a discipline. I’d propose: Technical and Business Significance, a lightweight but mandatory gate that any AI solution has to pass before it’s approved for the environment, answering what it technically does, what data and permissions it touches, and what business value justifies that exposure. The same gate may include vendor, risk, compliance, legal and security reviews.

Everything below is what happens once a solution clears that gate and is granted “Technical and Business Significant” status.

Pillar 1: Scaling

Once a solution is approved and its context is defined, the question shifts from “should this exist” to “how does this grow without every team re-solving the same problems.” Without a repeatable path, each new team either re-litigates governance from scratch or skips it entirely to move fast.

• Build a reference pattern, a reusable architecture, access model and approval template, for each class of approved AI solution, so scaling reuses vetted patterns instead of one-off exceptions.
• Track adoption centrally enough to know how many instances of a pattern exist and who owns each one.
• Scale efficiently, not just widely: Route tasks to the right-sized model instead of defaulting to the largest one, cache repeated queries to cut cost and latency, and monitor token usage, inference costs and compute footprint, including Kubernetes-based inference scaling for LLM workloads, as adoption grows rather than reacting only after costs spike.

Pillar 2: Security

This is the technical control layer, the mechanisms that keep an approved solution from becoming a liability once it’s live:

• Shadow AI, evolved. It used to be unsanctioned SaaS. Now it’s unsanctioned MCP servers and API connectors, employees wiring an LLM directly into Jira, internal databases or SharePoint, often without security ever reviewing what data flows through or what the model is now capable of doing. It’s gone further still: users with no development background are using tools like Cursor to build and launch full applications on their own, with the intent to “review it later.” These apps go live before anyone in security even knows they exist.
• A new risk category, not just a bigger one. Traditional API risk is largely about data exposure. Agentic and MCP tool use adds an action dimension; a model can read, write, delete or trigger workflows. That’s a meaningfully different threat model than a chatbot saying something it shouldn’t.
• Governance built for the wrong actor. Most API security programs are designed around human or deterministic service-to-service calls. They weren’t built for a non-deterministic agent deciding, in real time, which calls to make. Least privilege and scoping matter more here, not less.
• Non-human identity, still catching up. Every agent, MCP server and API integration is effectively a new non-human identity with its own credentials and permissions. NHI governance was already immature before AI accelerated the problem, and it now needs significantly more investment: proper lifecycle management, credential hygiene and ownership, not just provisioning and forgetting.

Each of these risks points to the same remedy: Visibility and enforcement at the point where AI actually touches systems, not after the fact. That’s what the practices below are built around.

Foundational practices (start now):

• Inventory every MCP server and AI connector in use today, sanctioned or not.
• Route AI and agent traffic through a governed MCP gateway, the same enforcement point used for auth, scoping and rate limiting, rather than ad hoc integrations.
• Apply least privilege scoping to every tool an agent can call, and treat every agent as a non-human identity requiring lifecycle management.
• Log and monitor agent actions, not just model outputs.
• Be deliberate about AI-SPM investment. The category is real, but the value proposition versus existing CSPM and CNAPP tooling is still maturing for a lot of buyers. Buy for a defined problem, not a trend.

Emerging practices (industry still maturing):

• Extend DLP to cover agents that inherit user permissions, since an agent acting on someone’s behalf can move data just as easily as the user it’s impersonating, often faster and at greater scale.
• Register every agent in the CMDB as an independent entity, with a defined scope, owner and permissions set, not folded silently into the identity of the user or service that deployed it.
• Design for agent-to-agent (A2A) security deliberately, including on-behalf-of (OBO) flows, so that when one agent calls another, permissions are scoped and traceable rather than inherited by default.

Pillar 3: Governance and compliance

Where security is about technical controls, governance is about accountability, who owns a solution, whether it’s still operating within the bounds it was approved for, and what regulatory or policy obligations it has to satisfy. This is the layer that’s easiest to skip because nothing breaks visibly when it’s missing, until an audit, an incident or a regulator asks who’s responsible.

• Ownership as a first-class question. Every approved AI solution needs a named owner accountable for its behavior, not an assumption that whoever built it is still watching it.
• Compliance obligations tracked per solution. Data residency, industry-specific regulation and internal policy requirements should be checked at approval and re-checked as a solution’s usage evolves, not assumed to hold indefinitely.
• Vendor sprawl. Multiple teams independently contracting different engines — Copilot, Gemini, Claude — for materially the same use case isn’t resilience; it’s redundant spend and redundant risk surface. Multi-engine strategies are legitimate when deliberate and matched to real capability differences; they’re a governance failure when they’re just an artifact of teams choosing in isolation.
• Infrastructure sprawl. The same pattern plays out at the cloud layer: AI workloads landing on different clouds (AWS, Azure, GCP) not from deliberate architecture, but because different teams defaulted to whatever platform they already knew. Multi-cloud is a legitimate strategy when it’s intentional; it’s a governance gap when it’s an accident of who built what, where.

Foundational practices (start now):

• Assign and document an accountable owner for every approved AI solution at the time it clears the gate.

Emerging practices (industry still maturing):

• Build periodic re-certification into the governance cycle, confirming a solution’s scope, owner and compliance posture are still accurate, not just correct at launch.

Pillar 4: Business value

Context, scaling, security and governance answer how AI gets adopted responsibly. This pillar answers why a given solution deserves that investment in the first place, why an existing solution requires AI transformation and to what level. A value that justified a solution at approval time can erode as usage patterns shift, as the systems it touches change or as the business problem it was built for evolves. Treating business value as a one-time answer at approval, rather than something revisited as a solution scales, is how organizations end up maintaining AI capabilities long after the case for them has quietly disappeared.

• Transform existing systems into AI-enabled ones based on business need and known value. Replace them with AI-native systems only when replacement delivers better ROI, and the replacement is still technical and business-significant and scalable, and clears the same context foundation and the security and governance pillars.
• Revisit the value case at the same cadence you revisit context, not just at initial approval.
• Retire or re-scope solutions whose usage no longer matches the business justification that got them approved.

The business case

This isn’t a compliance argument. It’s a speed argument. Organizations that build context, scaling, security and governance in from the start scale faster, because they aren’t spending next year unwinding this year’s shortcuts. Cloud-smart didn’t slow federal cloud adoption; it made it durable. The same will be true here.

The vision

This isn’t about fear or slowing anyone down. It’s about making sure the AI adoption happening right now is still standing, secure and without a mountain of technical debt. That’s what “smart” means.

I have made this mistake before. The goal was to create an executive intelligence agent: an artificial intelligence (AI) engine where C-suite executives could self-serve their analytics and pull trusted numbers for the board.

The promise was strong: personalized dashboards, ad hoc analyses, automated tasks and board decks, all from a single interface. Much faster than the status quo, and without a single new hire.

So, I did the reasonable thing and connected the AI directly to the database. It could query the data, build beautiful charts and refresh dashboards daily.

It was also useless, because the numbers it pulled could not be trusted. Analysts had to step in; Jira ticket counts went up rather than down and adoption never hit the target.

AI agents reach into different systems to perform tasks in the real world. They query databases, call APIs and search documents. They resolve conflicts, interpret ambiguities and report a result. The most valuable agents do all this without human intervention.

That is also where the danger sits. Agents that work unsupervised must answer factual questions accurately. Whether in analytics, sales or customer service, facts are not subjective, and getting them right is where trust lives or dies.

This isn’t a hallucination problem. The agent isn’t fabricating an answer; it is making a decision about data that it never had the authority to make.

Stakes are higher when agents are unsupervised

Human-in-the-loop (HIL) is when an AI agent’s output is verified by a human before it can be dispatched or act in the real world. HIL has become a standard framing for AI applications and a common governance recommendation, particularly in regulated environments.

HIL applications are often internal. They make teams more efficient, reduce cost and increase speed. Coding is a classic example, where engineers review, test and validate code before shipping it.

But there is a class of applications where HIL is not an option, and where trust matters most: a customer service agent answering questions about a customer’s account; an embedded analytics chatbot reporting ARR to a client; an executive intelligence agent putting a number in a board deck. The consequences of getting it wrong are real: a support ticket, a lost customer or a loss of credibility with the board.

In all three, the person receiving the answer cannot check it. And adding a human in the loop would undercut the value of the application in the first place.

A supervised agent is allowed to be wrong because someone verifies the answer, corrects it and is accountable for it. An unsupervised agent is not.

When APIs disagree, your agent makes a choice

We built a four-agent system that could act on behalf of a vendor and answer customer questions in a marketplace setting. The agents needed data about the vendor and customer to provide personalized answers. The system was unsupervised.

But the data came from scattered, siloed APIs. Something as simple as a customer’s address could live in several places, and those systems often disagreed.

The agents had to query multiple APIs and decide which value was correct. The result was unreliable: the same question could produce a different answer across sessions. Personalization was the entire value proposition, and it had become a liability.

What fixed it was resolving the conflicts before the agents ever saw the data. We built business logic that reconciled the raw records and loaded the result into a feature store. The customer’s address, name and budget now had one value each. The agents stopped choosing, and the system became reliable.

That solution required real business decisions: reconciliation rules had to be encoded, and someone had to decide which system won for each field. No amount of prompting would have solved that. Logic that lives in a prompt is subject to interpretation, and there is no guarantee that the same inputs will produce the same outcome twice.

For a production system where trust matters, the answer has to be resolved once and reused, not regenerated on every request.

Choosing the right document before your agent does

The same problem appeared in the unstructured data. Reviews and past customer conversations were stored in a vector database and retrieved through Retrieval-Augmented Generation or RAG. The data was rich and often contained what a customer needed, but multiple sources could disagree.

Sometimes the information was stale: venues move, parking information changes, transportation schedules do too. Other times what was right for one customer wasn’t right for another: instructions for someone arriving by plane are not the instructions for someone arriving by bus, and both are correct.

Again, the agent had to choose.

So, we built a retrieval tool that resolved the conflict before the agent saw the results. We ranked sources by whether the conversation was with the same customer, then the same region, then any customer, with recency weighted throughout.

It wasn’t sophisticated or guaranteed to be perfectly current or correct. It did something more fundamental: it removed unnecessary variability. The same question returned the same answer.

The agent stopped choosing.

Why agents shouldn’t query the database

I ran an experiment to prove to myself I was right. The setup was simple: give LLMs increasingly complex business logic as context and see if they could accurately apply it to data. My hunch was that the more rules there were, the less likely they were to get it right.

The results were worse than I expected. Across nine models, from small to frontier LLMs, the top scores were 97% accuracy at five rules, 73% at fifteen and 43% at fifty. No single model dominated; bigger models did not always perform better, and the average was much lower than the top results.

I was convinced: query generation would never be reliable enough in an unsupervised setting. Context cannot be enforced; it is up for interpretation, and the bigger and more complex it becomes, the less likely the LLM is to follow it correctly.

I needed a different approach. Rather than querying the database directly, the executive intelligence agent would query a semantic layer with clean, unambiguous definitions. The backend engine would then translate the metric query into SQL.

We added a Model Context Protocol (MCP) tool that constrained how the agent could query the metrics: metric names, dimensions, time frame and not much else. By constraining the retrieval, we removed the opportunity for the model to guess beyond what was defined.

This did the trick. Repeated questions about a metric returned the same result, and that result was the one the business had agreed on. The numbers could be trusted. Token consumption and latency were also much lower because answering a question no longer involved SQL generation.

It worked because the semantic layer did the resolution, not the agent. More correctly, a human resolved the metric definition and encoded it into the semantic layer, so the agent didn’t have to guess.

Someone has to decide, and it shouldn’t be the agent

When the data supports multiple answers, but only one of them is valid, the agent is forced to choose. That decision cannot be trusted: the agent does not have the authority to make it, it cannot be held accountable for it, and it cannot be audited afterward because its reasoning leaves no durable trace. Even a perfectly deterministic LLM would produce a consistent answer that no one approved.

The easy answer is to supervise the agent with a human. This adds accountability, but also cost. Humans are slow and expensive, errors still pass through and the resolution logic remains in someone’s head rather than in the system. Worse, accountability often lands with the analyst, sales rep or revenue operator who reviewed the answer, rather than with the person who has the authority to define it.

The more durable answer is a resolution layer between the agent and the data that removes the need for a choice. A feature store reconciles conflicting systems into one value. A retrieval tool ranks sources according to rules someone wrote down. A semantic layer holds metric definitions behind a constrained set of tools the agent cannot route around.

The implementation varies. The principle does not: a human decides once, the system encodes the decision and the agent stops choosing.

This is hard not because of the infrastructure, but because it surfaces decisions someone with authority has to make. What counts as an active customer? Which system wins when two disagree? Which source takes precedence? Those answers belong to the business, not the agent.

There are decisions that can be safely delegated to an agent, others to a human and others that cannot be delegated at all. The skill is knowing which is which.