Anthropic has a $100 million plan to help enterprises get more from AI. No, it doesn’t involve agents. It involves people. Lots of people.

How retro.

On October 2, the company announced Claude Frontier Academy, with a goal of training 10,000 frontier deployed engineers by the end of 2027. Participants work through a simulated deployment, including use-case selection, security review, and handover, before undertaking a 12-week residency on a real project at their own company.

For a business selling increasingly capable models, it’s telling that Anthropic recognizes some of the thorniest problems in AI don’t involve AI at all. This, to me, is indicative of real progress, because the heart of any technological shift is always people.

Which people? Well, that’s where this idea becomes particularly interesting. As critical as developers are to the success of AI in any particular organization, we need those developers working alongside the people who understand the business, with authority to turn that understanding into systems that other employees can use. That’s the key to AI success.

Old advice for a new assignment

It has always been thus, however much we try to pretend that this time it’s different. Back in 2013, I quoted Gartner analyst Svetlana Sicular discoursing on the rise of big data technologies like Hadoop: “Organizations already have people who know their own data better than mystical data scientists.” She continued, “Learning Hadoop is easier than learning the company’s business.” Data becomes useful when paired with industry expertise—from experts who understand which data actually matters.

This topic is perpetually relevant. I covered the argument in 2023 and again in 2025. We’ve always needed people who can translate business requirements into software.

AI expands the kinds of knowledge that software can work with. Language models extend that work to material that often sat outside our applications: research notes, meeting transcripts, internal debates, and explanations of why a decision was made. An employee can ask questions across that material without someone first designing a report for every possible question. That opens up useful work that would have been difficult or expensive to automate before.

It also creates new ways to be wrong. A model may find a convincing explanation that was superseded six months ago, confuse a proposal with an approved policy, or combine two departments’ incompatible definitions of a customer. The people who understand those distinctions need to help engineers make them explicit, then build examples that reveal when the system gets them wrong. Companies that figure this out stand to benefit disproportionately; hence, PwC’s April survey of 1,217 senior executives found that companies reporting the strongest AI performance were twice as likely to redesign workflows around AI.

Teach the system what’s good

Bridgewater, the world’s largest hedge fund, has done some interesting work here that substantiates this theory. At AI Engineer NYC on October 13, two representatives of Bridgewater described Vault, its repository and access layer for external and internal unstructured information. Vault isn’t designed to be a dumping ground; instead, the company has shaped the way it stores data to make it useful for analysts.

I attended the talk and watched as Sam Green demonstrated a question about AI infrastructure investment and the Korean won. Left on its own, a web-connected AI agent relied on July material to answer a question posted in October. Hedge funds depend on up-to-the-second information to figure out optimal trades, making this initial attempt a failure. Connected to the human-influenced Vault, however, it searched October 1 through October 8 and drew on seven documents rather than one or two.

Knowing which period matters is part of understanding the investment question; making the right material available consistently is an engineering problem. You need both. A plausible answer assembled from stale research can be worse than an obvious failure because it gives the investor little reason to investigate further. The team also collected roughly 200 questions and manually identified useful documents, including misleading matches. Bridgewater’s Aaron Linsky reported that subsequent improvements lifted the share of relevant documents among the top 10 search results from about 60% to between 90% and 95% on that evaluation.

This method is useful well beyond investing. Someone has to distinguish a document that merely sounds relevant from one that actually helps answer the question. Engineers can then use those judgments to measure whether a change improves the system. Business expertise becomes something the team can test against, rather than advice delivered after the application has shipped. It’s not a case of human intelligence or artificial intelligence. You need both.

Make the expertise usable

Of course, a skeptic could reasonably ask why a model can’t learn the business, too. It’s a fair critique, as AI can learn a great deal of it. After all, that’s the reason Bridgewater (and others) make a point of supplying the right documents, definitions, and examples. This ensures AI can take on more of the analysis, thereby reducing dependence on the few employees who currently carry essential knowledge in their heads.

But access to every document doesn’t settle which policy is authoritative when two departments disagree. Nor does it authorize a change to an approval process or establish who owns a mistake. A model can help expose contradictions and propose resolutions, but someone with responsibility for the business has to decide which resolution the company will adopt.

Of course, most companies don’t have Bridgewater’s decades of codified investment knowledge. They may also have conflicting definitions scattered across spreadsheets and a few employees who know why the official process doesn’t quite describe reality. Nor does it make sense to search for one extraordinary hire or a star employee who knows every model, understands every department, and can persuade everyone to change. (Good luck with that!) After all, someone with deep knowledge of the business may also be the exact wrong person to help an organization evolve, wedded as they may be to how things have always been.

Gartner’s Sicular was right about the value of people who understand the business. AI gives companies more ways to put that understanding to work. Give those people engineers to build with, authority to resolve disagreements, and responsibility for leaving behind a system someone else can operate. We need AI challenging people, and people challenging AI.

In olden days — last year, say — employees using unsanctioned AI tools might copy-and-paste sensitive data that could end up in the AI company’s training data set.

Today, an unsanctioned AI can hack into another company for an employee even if they didn’t explicitly ask it to.

This doesn’t just mean the latest unreleased frontier models undergoing security testing. Claude, ChatGPT, and Gemini have all evolved from being mere chatbots, answering questions and helping people write emails. They now have agentic capabilities and are able to carry out complex tasks on behalf of users.

And they do, sometimes to dangerous effect.

In August, ABC News in Australia interviewed a man identified only as “Andrew” who asked an AI agent to sign him up for a gym class. The agent hacked into the gym’s system and deleted someone else’s wait list reservation.

The AI was Anthropic’s Claude, and the agentic framework was OpenClaw.

Now imagine an employee asking their agentic AI assistant to help them make a sale. The request might inadvertently inspire the agent to hack into the prospect’s company.

To keep this — and other worst-case scenarios — from taking place, enterprises are building guardrails around their AI systems, restricting what data the AI has access to and what tools it’s allowed to use.

But none of those guardrails will work if the employee uses a tool that their company doesn’t know about.

“This is a problem we’ve long had,” says Matt Butkovic, technical director for cyber risk and resilience in the CERT division at Carnegie Mellon University’s Software Engineering Institute. “People will find ways to purchase or get access to things they think are useful, even when an organization says you probably shouldn’t do that.”

Ten years ago it was personal email and unauthorized cloud storage.

“The stakes are higher in some ways now,” adds Butkovic, who also teaches in CMU’s CISO program.

Verizon’s 2026 Data Breach Investigations report, released in May, shows that 67% of employees access AI services through non-corporate accounts on corporate devices. Shadow AI was the third most common non-malicious insider action detected in Verizon’s 2025 data loss prevention dataset.

And a May analysis of 1.9 million AI session minutes conducted by Harmonic Security found that when employees accessed personal accounts, 65% of their activity was related to business. They used personal accounts to write work emails and debug code, and even used it for legal work.

In a separate report, released in July, Harmonic reported that every organization the company monitored in the first half of 2026 had at least one employee sending data to a China-based AI tool. The uploaded data included M&A plans, source code, financial projections, and legal material.

To address this problem, enterprises are taking a fourfold approach:

• Figure out what employees want to use AI for and give them sanctioned, safe alternatives.
• Use security tools to monitor activity and keep employees from sharing sensitive data with unsafe systems, or even accessing them at all.
• Educate employees on the risks of AI and how to use it safely, because you can’t solve this problem with technology alone.
• Hold employees accountable when they violate AI policies.

Blocking DeepSeek at a financial services firm

BitGo, a Fortune 500 financial services firm with over $100 billion in digital assets under custody, uses a combination of strategies to combat unsanctioned AI.

“We have enterprise versions of Grok, ChatGPT, Claude and Gemini,” says Manny Khan, the company’s deputy CISO. “We are an AI-first organization. We encourage all of our people to use AI in their work, to try to automate as much of it as possible while keeping the human in the loop to avoid any slop.”

Unsanctioned AI is an industry-wide concern, he says, and having a sanctioned alternative is key.

“We encourage folks to use what is approved and has guardrails and harnesses and trust boundaries and safety checks,” he says.

To make the sanctioned alternatives easier and more appealing, employees use single sign-on, provided by Okta, to log into systems, and the enterprise-grade models also connect to the company’s MCP servers.

Once employees have a safe AI option to use, the next step is to get a handle on the unsafe ones.

For example, BitGo uses a data loss prevention tool from Cyberhaven. DLP was a useful security tool long before AI came along, but today it also helps ensure that sensitive data isn’t copied-and-pasted into untrusted chatbots.

“All traffic is proxied and analyzed by our security tools to identify anything potentially malicious, shut it down, and not allow the connection if it’s a site known to be malicious,” Khan says.

For example, the company blocks DeepSeek, a Chinese AI model. “We don’t want their models to train on our data,” Khan says.

But there’s only so much technology can do.

“Every site has AI now, and we cannot block every single site,” Khan says. “We might as well block the internet at that point.”

That’s where human awareness and education come in, says Khan.

“We do train people,” he says. “And we have an AI governance policy that we share company-wide and enforce this policy by tracking and measuring against it.”

It’s important for a company to have a single voice on AI use, a central figure with authority and ownership who can provide guidance, he adds. “Otherwise, you’ve got a lot of people who try to figure it out on their own. And that’s what you don’t want.”

Docusign on guard against agentic AI

“We want to educate users to do the right things, but people still want to experiment,” says Shivi Verma, senior manager of engineering at electronic signature firm Docusign.

That’s where it helps to have approved, secure tools for people to use, as well as systems in place to block the insecure ones.

“Some of the websites, like DeepSeek, we have blocked,” he says. “But we want to block in a way that focuses on education and focuses people on the right processes and tooling, which will drive people automatically to use approved tools.”

The company is also working on creating an allow list, he says, focusing on tools that employees can use without any concern.

And the company has network management tools like Zscaler, says Verma. “If people are posting confidential data in an external tool, it will give a popup, like a deterrent.”

Now, personal AI agents like OpenClaw are yet another evolution of the shadow AI problem, he says.

“We do monitor and people are using it, but we want to do it in a way that’s under security policies,” he says.

And with OpenClaw in particular, the danger is too high for just a warning.

“If it’s for personal use, that’s one thing,” Verma says. “But if you’re using it at work, your user has to be stopped immediately.”

Nonprofit builds routing system for approved AI

“Simply blocking AI tools is not a sustainable solution,” says Boris Kolev, global head of technology at JA Worldwide, a global educational nonprofit with almost 5,000 employees that serves more than 20 million people a year.

For JA Worldwide in particular, the problem was exacerbated by the fact that there was no approved solution until three months ago. As a result, employees got into the habit of using personal AI platforms.

“It was totally uncontrolled,” Kolev says. “Everyone who wanted to explore AI was using public models.”

At the beginning, people didn’t worry about what they shared and uploaded. “We tried to implement some policies, like ‘don’t upload corporate information.’ But it was hard to know what people were doing.”

Plus, AI was being embedded everywhere. On Windows. In people’s phones. “A user cannot avoid it,” says Kolev.

Then, earlier this year, the organization built a routing system, with enterprise-safe versions of Claude and ChatGPT running in private environments on AWS and Azure, in addition to some open-source models.

“Our colleagues can choose which model to use,” he says. “And sometimes they do a prompt two different times and choose which one works better.”

The system went into production in June, after a couple of months of testing and development.

“Now, after all the policies and rules are implemented, we have our own closed AI system, hosted on our own servers, so no risk of leaking corporate data,” he says. “But still, some projects are using public models, and we are trying to solve this problem.”

Another hitch: individual employees were often invested in the personal AI tools they’d grown comfortable with and reluctant to change to the corporate tools.

“Employees were saying, ‘I have so much history. It knows me, I cannot just switch,'” Kolev says.

And employees still have all the AI tools that come with their devices.

“This is hard to manage, and it’s getting even harder,” he says. There are monitoring and blocking tools available, but they’re too expensive. “We’re a nonprofit, and for us it’s almost impossible to afford monitoring tools. So we do a lot of educational sessions.”

The organization is also trying to make the sanctioned tools more appealing. That includes a mechanism to import the history and context from other platforms, he says. “And we’re trying to convince them that our tool works better and has more functionality, so we’re adding MCPs.”

MCP — model context protocol — allows an AI system to access data and tools directly. That includes connecting to corporate email and calendars, SharePoint, Monday.com, CRM, and all the other software that employees use for work, he says.

Kolev says that it’s a mistake to assume that employees use shadow AI because they don’t respect IT policies. It’s because IT didn’t move quickly enough to meet their needs.

“They find the AI faster than you can produce tools and governance and rules,” he says. “So my advice is that you start with simple rules that employees can understand, provide sanctioned tools, and continuously adapt governance.”

Holding employees accountable

According to an April survey of more than 1,200 employees conducted by Wakefield Research on behalf of PagerDuty, 66% of employees have used unsanctioned AI tools — and of those, 48% faced formal consequences, such as a warning or disciplinary action.

Holding people accountable is critical to a successful AI use policy, says Carnegie Mellon’s Butkovic. “We have to speak definitely about this in organizations,” he says. “If this behavior cannot be tolerated, then it shouldn’t be tolerated.”

Allowing the use of unsanctioned AI doesn’t just create risks but also opens up an organization to legal liability if the AI agents, acting on behalf of employees, harmed other companies or individuals.

“There could be consequential actions,” he says. Even if the employee responsible gets fired, “external parties that have been affected are still going to sue the company.”

The organization needs to be able to show that it has policies in place and enforces them when employees deliberately circumvent the policies.

“If you as an employee make a good-faith effort to comply with the policy, we’ll show you latitude if you’re not malicious,” Butkovic says. “But if you’re actively circumventing the system of controls in your organizations, that’s the case where there have to be swift and profound consequences.”

Related reading:

• 6 ways to make AI accountability stick
• AI policies work better when employees help write them
• Why AI adoption keeps outrunning governance — and what to do about it
• 5 ways to curb AI sprawl without stifling innovation

This series lays out a practical framework for taking generative AI (GenAI) from pilots to dependable production systems in the enterprise. It focuses on four disciplines that determine long-term success: engineering for scale and reliability, designing agentic systems with clear constraints, embedding governance directly into build and runtime controls, and measuring ROI at the workflow level with full cost and outcome visibility. The throughline is operational discipline—treating GenAI as a service with contracts, evaluation, ownership, and measurable business impact.

Post 1: Enterprise GenAI at scale

The first article in the series, “How to run enterprise generative AI like a production service,” focuses on operations. It explains why reliability, retrieval quality, latency control, cost routing, observability, and evaluation harnesses determine success at scale. The article lays out a practical architecture and operational checklist so teams can move from promising demos to stable, supportable systems.

Post 2: Agentic AI in the enterprise

The second article, “Agentic AI in the enterprise: How to balance autonomy with constraints,” defines what an agentic system is and how to operate one safely. It introduces the agent loop (plan, act, verify, commit), tool contracts, policy enforcement, durable state, and verification gates. The emphasis is on constrained autonomy, traceability, and operational ownership so agents can execute real workflows under enterprise controls.

Post 3: Governance by design

The third article, “Governance by design: Turning AI policy into executable controls,” treats AI governance as engineering work. It describes how to translate policy into executable controls in continuous integration pipelines and runtime enforcement layers. Topics include threat modeling, policy-as-code, lineage, audit evidence, and feedback loops. The goal is steady delivery under measurable guardrails.

Post 4: AI ROI beyond pilots

The final article, “AI ROI beyond pilots: Measuring outcomes in production,” addresses how to measure real business value from GenAI. It defines ROI at the workflow level, accounts for full life-cycle costs, and connects usage metrics to operational outcomes. It provides a metrics stack, cost equation, cohort rollout strategy, and a 90-day plan to produce credible, production-grade ROI signals.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

For most of the history of enterprise software, accountability has been relatively easy to understand. A person logs in, a person has a set of permissions, and a person takes an action. If something goes wrong, you can usually work backwards from there.

Agentic AI changes that. We are moving from systems that suggest what someone should do to systems that can actually do it. Agents can access tools, call other systems, make decisions across multiple steps, and increasingly operate without a human approving every move. That is the point, of course. An autonomous system that needs someone hovering over every decision is not particularly autonomous.

But the more action we hand over, the more important one deceptively simple question becomes: When an agent does something, who did it?

Not philosophically. Operationally. Whose authority was it using? What was it allowed to touch? Who granted those permissions? And if something goes wrong, who owns the outcome?

Accountability starts with identity

The first question is what an agent actually is inside your organization. Should it always be treated as a delegate of a human, acting on that person’s behalf and inheriting some version of their permissions?

That model makes accountability relatively straightforward. If my agent does something, the action can be traced back to me. But it becomes harder to sustain as agents become more persistent and autonomous.

An agent might run continuously or serve an entire team rather than one person. It might perform a business function that continues long after whoever originally configured it has moved on. In those cases, should the agent have an identity of its own? And if it does, who creates that identity, who owns it, who grants its permissions, and how long should those permissions last?

Identity is where accountability starts because if you cannot reliably answer who the agent is, everything that follows becomes harder to reason about.

Identity and permissions are closely related, but they are not the same thing. Consider an agent designed to conduct research using public information. It might be perfectly reasonable for that agent to use a public model, external tools, or public Model Context Protocol (MCP) servers. Now point that same capability at internal finance data.

The agent has not fundamentally changed. Its environment has.

Suddenly, sending information to an external model may be unacceptable. Certain tools may need to disappear from its reach. Data that could previously move freely now sits inside a very different compliance boundary. So permissions cannot simply be a static list attached to an agent. They need to reflect who the agent is, what it is trying to do, and the context in which it is operating.

That becomes even more important when agents can choose different tools and paths through a problem rather than following a completely predictable workflow.

Delegation gets complicated quickly

Now add sub-agents.

An agent receives a goal and creates several others to complete pieces of the work. Do those sub-agents inherit the parent’s identity? Do they inherit its permissions? Should their authority be narrower based on the task they have been given? And who ultimately owns what they do?

There may not be one universal answer, but there does need to be an answer inside the enterprise. More importantly, there has to be a through line.

An agent can delegate execution to another agent, which delegates part of that task again. That cannot mean accountability disappears somewhere along the way. Autonomy can branch. Accountability cannot disappear.

Enterprises need to retain the relationship between the original authority, every agent involved, the permissions each one carried, and the actions they ultimately took. Otherwise, when something goes wrong, everyone gets to participate in a very expensive game of “whose agent was this?”

The same problem appears over time, not just across agent chains. Consider a long-running agent that constantly monitors tickets and takes action. Eventually, it becomes part of normal operations. Then the person who created it leaves the company.

The agent stays.

Who owns it now? Did responsibility automatically transfer to the person’s manager? Was a successor assigned? Does the team own it? Does the enterprise? And what happens to permissions that were originally linked to someone who no longer exists in the organization?

We already manage life cycles for employees, service accounts, and enterprise applications. Agents need the same seriousness. They need an ownership life cycle, not simply a deployment life cycle.

Accountability has to exist in the system

Defining ownership is only useful if you can reconstruct what actually happened. That means connecting an agent’s identity to its permissions, actions, tools, sub-agents, and eventual outcome.

If something fails, the organization should be able to understand what happened, why the agent was allowed to do it, which permissions enabled the action, which agent actually performed it, and where the control failed. That is what makes remediation possible.

This is why identity, permissioning, and execution tracing cannot live only in policy documents. Writing down who owns an agent is not the same as encoding that ownership into the systems governing it. Telling an agent not to access something is not the same as preventing access. And asking teams to piece together an incident afterwards is not the same as tracing execution while the system is running.

The goal is not to put a human approval step in front of every agent action. That would defeat much of the value of autonomy. The goal is to move humans up a level, from making every individual decision to defining the boundaries within which autonomous systems can make them.

As agents take on more work, enterprises need to know what they can do, who owns them, how authority is delegated, and how every action can be traced.

Because the question is no longer simply whether an agent can act. It is whether, when it does, the organization can still answer who.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.