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

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

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

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

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

Permission is not proof

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

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

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

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

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

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

What verified completion looks like

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

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

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

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

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

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

Keeping delegated work accountable

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

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

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

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

What CIOs can do now

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

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

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

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

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

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

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

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

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

Adoption has outrun control

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

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

Vipin Jain

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

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

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

Vipin Jain

Four controls were never applied

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

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

The failure sits between functions, and attackers have found it

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

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

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

Regulators already treat this as third-party risk

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

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

Standards and vendors have moved; procurement has not

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

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

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

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

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

5 moves for the next 90 days

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

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

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

The takeaway

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

Put three questions to your team this week.

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

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

On November 1, 2026, Grok Bot users gave IT buyers a live example. Subscribers reported that their weekly usage allowance ran out sooner than expected, and Elon Musk wrote on X that the cost of serving Grok Bot was “unsustainably high relative to revenue.” He confirmed it was not a glitch, but he did not say how the limits would change.

The cost of running the service is the seller’s problem. The allowance that a buyer thinks they bought is the buyer’s.

Grok Bot is a consumer product, but any team that buys metered AI plans faces the same exposure. The allowance can shrink or run out early, and the overrun lands in a department budget. This example shows what a price page does not tell a budget owner: the rules and limits behind the allowance can matter more than the price. Your AI bill will not look like your last software bill. Seats are no longer the whole story, and the line item that finance approved in January may not describe what you are actually buying in June.

The price page is also a poor guide. Stanford’s 2025 AI Index found that the cost of inference at GPT-3.5 level fell more than 280-fold between November 2022 and October 2024. Yet the FinOps Foundation’s State of FinOps 2026 survey found that 98 percent of respondents now manage AI spend, up from 31 percent two years earlier. Cheaper units have not made the bill easier to predict.

I recently published research on how AI companies publish their prices. I read the public pricing pages and documentation of the Forbes AI 50 and a set of cloud platforms that sell AI services, captured in mid-September 2026. The goal was to describe what is on the page, not to judge whether any price is fair. The finding that matters most for a budget is not the pricing model. There are four rules attached to the credit allowance: expiry, rollover, minimums and recharge.

What the pricing pages show

Classic software charged per seat because serving one more user cost almost nothing. Model inference is different. Every request has a real cost, and usage can differ by orders of magnitude from one customer to the next. Pricing has moved to follow that cost.

The most common model among AI-native companies is a subscription with a usage credit allowance. Sixteen of the 29 companies whose pricing I could observe use it. The allowance is usually counted in credits, compute units or generation time. The flat tier price is the headline. The credit balance is where the real limit lives.

Many companies publish nothing at all. Twenty-three of the 52 AI-native companies in the sample show no pricing, and about half of those show a call to contact sales instead. Every cloud platform in the sample did publish its prices.

Model APIs split on when you pay. Of eight model API and inference providers, two require prepaid credits that draw down as you use them. The other six bill after the fact. Established products tend to keep the per-user price and add a meter on top, with an allowance for AI use and a higher rate once you pass it. Pricing by outcome appeared only in customer service, where a resolved conversation is easy to observe and agree on.

Four rules that decide what an allowance is worth

Most budgeting advice stops at the pricing model. The part that changes your bill sits one level below, in the rules attached to the credit allowance. In my sample, plans with the same shape differed on four rules.

1. Expiry. Some free credits expire every month, and prepaid balances on a model API can carry an expiration too. Unused allowance is not an asset. A quiet month does not bank value for a busy one.
2. Rollover. One media tool lets unused time carry over and a comparable one does not. Two plans at the same price cost a team with uneven demand very different amounts.
3. Minimums. A customer service product that charges per resolved conversation also sets a monthly minimum of 50 resolutions. A vector database service sets a minimum of $50 per month. The unit price is not your floor. The minimum is.
4. Recharge. A prepaid balance can top itself up when it runs low. That protects the service and removes a natural pause point. A cap in your spreadsheet is not a cap in the billing system.

These are illustrative cases from the pricing pages. Others have seen part of this. Flexera warns that credit expiration, reset, and rollover rules “can silently create overages or strand value”. Zuora notes that prepaid credit packs give the seller working capital. Read from the buyer’s side, a prepaid pack is money you advance to a supplier, subject to expiry rules. The pricing pages show how widely those rules differ, and the difference is where a budget goes wrong.

What I would do with this as an IT leader

The rest of this article is my own personal, practical view. It is not a finding from the study. It comes from building and running billing systems.

• Split every AI line into fixed and variable. A single line called “AI tools” hides what you need to see. Put the subscription in one line, the usage allowance in a second and the overage you might incur in a third. When someone asks why the cost rose, you should be able to say which of the three moved.
• Ask what the allowance is counted in, then ask four more questions. Tokens, requests, credits and compute time are not interchangeable, and one supplier’s credit is not another’s. Ask what one unit buys. Then ask what expires, what rolls over, what minimum applies and what recharges automatically. Get the answers in writing next to the contract. If the supplier cannot state them, treat that as a risk you must price in.
• Budget a range with a ceiling, not a single number. Heavy users can use far more than typical users, so the average is a poor guide. Pick one typical user and one heavy user for each workflow and estimate the cost of each. That gives you a low case, an expected case and a ceiling. Rework recommends setting a monthly cap and alerts at 50, 75 and 100 percent of it before anyone starts using a metered feature. I agree with the order. Then check whether the supplier enforces your cap or only sends an email. With auto-recharge on, the cap in your budget may not exist in the system.
• Give each workflow a named owner. Apu Pavithran calls AI credits that the company pays for, but decision makers cannot see “shadow tokens”. An owner per workflow is the plainest fix. Keep the fixed subscription apart from the extra usage charges. Where you must estimate how to share a cost, say that it is an estimate and write down the method. A central AI budget can also be the right choice, as long as finance can see which teams depend on the work before anyone cuts it.
• Plan for prices to change. Public pricing in the AI era has moved quickly. One widely used developer tool changed its pricing in June 2025 and clarified the change two weeks later. Put a review date on every AI contract and ask what happens to your terms if the supplier reprices.
• Insist on usage data that matches the invoice. When the dashboard says one number and the invoice says another, someone has to explain the gap, and it will be you. Before you sign, ask for a sample invoice and the usage export that goes with it. Check that you can reconcile the two on a small account.
• Be careful with outcome pricing. Paying only when the work succeeds is fair only when both sides agree on what success means. Write down the definition of an outcome, the edge cases and how a dispute will be settled. If you cannot define it in a sentence your own team can check, you are handing the definition to the supplier.
• If there is no published price, ask for the rate card first. Nearly half of the AI-native companies in my sample publish no pricing. That is not a reason to avoid them. It is a reason to ask for the rate card, the allowance rules and a sample invoice before the conversation about discounts.

A short checklist for your next review

✓ Fixed, allowance and overage are separate lines.

✓ Every allowance is stated in units you understand.

✓ Expiry, rollover, minimum and recharge rules are written down for each plan.

✓ Each workflow has an owner and a typical, heavy and ceiling case.

✓ Every contract has a review date and a repricing clause.

✓ Invoices and usage data reconcile on a small account.

AI pricing will keep changing. Your budget does not need to predict every change. It needs to show which parts are fixed, which parts move with use and who is watching them.

Claude Code has quickly become one of the most widely adopted AI agents in the enterprise. Developers use it to write and refactor code, troubleshoot builds, run tests, and manage infrastructure, often by describing an objective and letting the agent determine the steps required to accomplish it.

That autonomy is the point. It is also why Claude Code is a governance decision for CIOs, not just a developer tooling choice. Claude Code runs locally on employee workstations, executes commands with the developer’s permissions, and can reach source code, credentials, cloud environments, and connected services as it works.

Anthropic has given enterprises meaningful controls to govern how Claude Code behaves, including centrally managed settings and hooks. These controls are essential. But controls that evaluate what an agent intends to do are not the same as visibility into what it actually does.

Here are five things CIOs need to understand to secure and govern Claude Code at enterprise scale.

1. Claude Code acts with your developers’ authority

Consider a developer who asks Claude Code to fix a failing build. The agent might read the codebase, install a dependency, run a setup script, edit a configuration file, query a cloud environment, and validate the result. One human instruction becomes a sequence of actions across multiple systems, all conducted with the developer’s level of access.

And it happens at machine speed. CrowdStrike internal usage data found that endpoint AI agents consumed roughly 700 times more tokens than humans using AI chatbots via the browser. Every one of those interactions is an opportunity for the agent to read, write, or execute something.

For CIOs, the question is no longer whether Claude Code makes developers more productive. It is whether the organization can account for what the agent does on its behalf.

2. Claude Code hooks are a strong first line of governance

Claude Code includes native governance capabilities that every enterprise deployment should use. Managed settings let IT define policies that individual developers cannot override. Permission rules determine which tools and commands the agent can use. And hooks give organizations programmable checkpoints throughout the agent’s life cycle.

Hooks run automatically at defined moments: when a session starts, when a user submits a prompt, before the agent uses a tool, and after that tool completes. At each checkpoint, a hook can inspect the proposed action and allow it, block it, log it, or require human approval. Organizations use hooks to stop commands that touch production credentials, prevent edits to sensitive directories, and send a record of agent activity to security teams.

If your organization is deploying Claude Code without centrally managed settings and hooks, start there. Treat hook configurations like any other security policy: version them, enforce them centrally, and review them as your use of agents matures.

But it is equally important to understand what hooks were designed to do, and what they were not.

3. Hooks see the checkpoint, not what happens next

A hook evaluates the action an agent is about to take: the command text, the file path, the tool being called. It does not follow that action into the operating system to see what it actually causes.

That distinction matters. A command such as “npm install” or “python setup.py” looks routine, so the hook approves it. The script that runs may then spawn additional processes, read cloud credentials from the developer’s machine, and open an outbound connection to an unknown destination. None of that activity passes back through the checkpoint.

The same applies to Model Context Protocol (MCP) servers, package install scripts, and other processes the agent launches. A hook can see that the agent requested an MCP tool. It cannot see what that server then does on the endpoint or the network.

Hooks are also rule-based. A rule that blocks a known-dangerous command will not necessarily catch an encoded payload, a script the agent writes and then runs, or a chain of steps that each look harmless on their own. Hooks are a policy enforcement point, not a detection and response system.

4. The most consequential decisions happen between checkpoints

Agents reason continuously. Between tool calls, Claude Code is reading files, documentation, web content, and tool output, and deciding what to do next. This is where risk often takes shape.

It is where indirect prompt injection lands, when instructions hidden in a README file, a third-party dependency, a web page, or an issue ticket redirect the agent’s behavior. It is also where agentic misalignment emerges, when an agent pursues a legitimate objective in an unsafe way, such as uploading sensitive data to a public service because it is the fastest way to finish the task.

Hooks do not observe that reasoning. They see only the next proposed action, which may look entirely normal. A manipulated or misaligned agent does not need to break a rule at any checkpoint to cause a breach.

This is not a theoretical concern. According to the CrowdStrike 2026 Threat Hunting Report, CrowdStrike is seeing AI agent-triggered detection leads at 2.5 times the rate of human-triggered leads.

There is also a scope challenge. Hooks govern Claude Code on the machine where they are configured. Most development teams use several AI agents, including Claude Code, OpenAI Codex, GitHub Copilot, and Cursor, and security teams need a consistent, fleet-wide view across all of them.

5. Runtime execution visibility closes the gap

If hooks govern what an agent intends to do, runtime execution visibility verifies what it actually did.

Runtime visibility means observing the activity an agent causes on the endpoint, including the processes it launches, the files it accesses, the network connections it makes, and the credentials it touches, and connecting that activity back to the prompt and agent session that initiated it. This creates a causal chain from prompt to agent activity to runtime impact.

That chain is what allows security teams to answer the questions that matter during an incident: What did the agent do? What did it touch? Was that behavior intended? And how do we stop it?

There is a useful precedent. A decade ago, signature-based antivirus checked files at the door, and attackers learned to walk past it. Endpoint detection and response (EDR) changed security by watching behavior at runtime. Agents require the same shift. AI executes on the endpoint, so that is where it must be secured.

CIOs can use five questions to assess where their organization stands:

• Which AI agents are running on our endpoints today, and who is using them?
• Are our Claude Code policies centrally managed, or configured by individual developers?
• If an agent ran a malicious script that passed our hooks, would we see it?
• Can we trace an incident from the prompt that started it to its impact on our systems?
• Who is alerted when agent behavior moves outside intended boundaries, and how quickly can they respond?

Hooks and runtime visibility are not competing approaches. They are complementary layers. Hooks enforce policy at the points where an agent asks to act. Runtime visibility watches everything that happens as a result. Hooks tell you what the agent asked to do. Runtime visibility tells you what it actually did.

CrowdStrike helps organizations secure AI agents with AI detection and response (AIDR) in the CrowdStrike Falcon® platform. CrowdStrike Falcon® Guardian integrates with Claude Code hooks to bring agent activity into the Falcon platform, connects that activity with runtime behavior on the endpoint, and gives security teams the context to investigate and respond when agent activity creates risk.

Learn more: Explore CrowdStrike’s AI security to see how organizations can secure AI agents across the agentic lifecycle.

Meta has hit pause on new terms of service for its business customers that would have granted it the right to grab any content from their websites. Not only that, but it would also have shifted the blame for every error produced through faulty AI to its customers.

The new terms of service were revealed on October 19 and initially due to take effect on October 30, though Meta later pushed the start date back to November 20.

But that small delay wasn’t enough to calm customer pushback, and now Meta has posted a note on Facebook’s business help center saying that the update had now been paused indefinitely.

Given the strength of feeling, Meta’s U-turn will not have come as a surprise. The terms would have been seen as far too onerous for customers, as well as exposing them to a legal minefield of the sort that UK regulators recently warned about.

In a statement to Harvard’s Nieman Lab, the company said that “We’re pausing the changes as we continue to engage with stakeholders and take our time to get this right.”

Meta has had a troubled time recently. Two weeks ago, it was fined for illegal use of customers’ data and in May, the company laid off 8,000 employees.

The UK’s digital watchdogs have warned enterprises that they can’t evade their legal responsibilities by blaming errors on AI agents that they have deployed.

“By taking action on behalf of users, such as making purchases and communicating with businesses, these agents could transform how people use digital services, engage with markets and unlock wider innovation,” said the Digital Regulation Cooperation Forum (DRCF), a body comprising the UK’s Competition and Markets Authority (CMA), Financial Conduct Authority (FCA), Information Commissioner’s Office (ICO), and communications regulator Ofcom, in a joint statement.

While the DRCF welcomed such uses it advised, “firms developing or deploying personal agents should think carefully about how consumers can understand when and how an agent acts on their behalf, how authority to act is given and how their personal data is used.”

The DRCF didn’t pull its punches. “We want to be explicit that existing legal and regulatory frameworks apply to personal AI agents, including competition, consumer and data protection law, online safety, financial services, payments and cyber security requirements,” it said, adding, “An AI agent’s autonomy does not diminish the responsibility of organisations that deploy it to comply with applicable law and relevant regulation.”

There is certainly a degree of uncertainty over the legal position of autonomous AI agents. Gartner has warned that companies are increasingly facing legal challenges over “AI-induced” decisions, while attorneys have weighed in over gray areas in AI governance.

The four UK regulators aren’t immune to that doubt: Only a few weeks earlier, they issued a Call for Input on their 2027-27 work plan to help them avoid overlap and uncertainty about the interplay between their respective regulatory regimes.

OpenAI is buying Pierre Computer Company in order to incorporate the San Francisco-based software developer’s Code.Storage infrastructure layer for Git into its Codex AI-powered programming tool.

Pierre Computer, whose employees number just barely in the double digits, has got plenty of clout for its small size. It’s well-known for Code.Storage offering, as well as for its open-source software libraries, Trees and Diffs, which OpenAI already uses in Codex.

OpenAI has experienced some of the limitations of Git itself, and its in-house engineering teams are already working to improve its support for human coders and AI agents working in parallel. Earlier this week the company described how it built a new back end for Git repositories, Pando, to enable concurrent working at scale.

The AI developer has been pushing Codex more aggressively this year: offering it to Mac users and expanding it to Windows. It cited Pierre Computer’s ability to help developers review code as one of the reasons for the acquisition. OpenAI highlighted the Diffs’ Edit mode and the recently released Highlights as components that were particularly helpful to development teams.

Announcing the deal on its news page, OpenAI set out how it would integrate the company into its existing offerings. “With the Pierre team, we wish to set the standard for modern software development: from the first branch an agent creates to that magic moment when code is deployed to the world. We want to make Codex the place where developers and agents take on their most ambitious projects.”

Neither company disclosed details of the acquisition price. OpenAI said that Code.Storage customers will be able to continue using the product until it brings the features into Codex, while Pierre Computer’s open-source projects will remain open, and OpenAI will continue to contribute to them.

This article first appeared on InfoWorld.

As a leader, you’ve probably spent years nudging your managers to create psychological safety. After all, organizations benefit greatly when it feels safe to challenge the boss, surface bad news early, and say the uncomfortable thing before it becomes the expensive thing.

The Space Shuttle Challenger disaster of 1986 has become the canonical warning. Engineers raised concerns about the O-rings used in the solid rocket booster before launch. Their warnings were overruled by managers under schedule pressure. Seventy-three seconds after liftoff, seven astronauts were dead. The lesson still holds: When people are afraid to speak or are pressured to comply, organizations miss what they already know.

AI, however, is introducing a complication most leaders haven’t accounted for. Your employees now have another place to speak, and emerging research suggests they may be more willing to challenge a machine than a human leader, while another body of research challenges our assumptions about psychological safety itself.

Put those together, and you’re no longer managing psychological safety only between people. You’re managing it across people and machines, and the two may tell you very different things about your organization’s health.

Safety needs accountability

Psychological safety became popular for good reason: Teams perform better when people can admit mistakes, question assumptions, and challenge authority without fear of it following them into a performance review. But here’s the misconception: Psychological safety and accountability sit at opposite ends of the same dial. Turn safety up, the thinking goes, and standards come down. They don’t. The strongest teams have both; people feel safe enough to challenge one another and accountable enough to deliver.

Researchers studying five workplace settings, from hospital nurses to knowledge workers to four years of sales data across 229 retail stores, found that the relationship between psychological safety and performance wasn’t simply linear. At high levels of psychological safety without matching accountability, performance on routine work could decline; collective accountability substantially buffered that decline. The problem wasn’t that people felt too safe; it was safety operating without another ingredient the team needed.

A newer conceptual paper helps explain why. Psychological safety lowers the interpersonal risk of speaking up, which is what you want, but safety alone doesn’t create the discipline that keeps a team sharp: preparing for meetings, thinking carefully before weighing in, and taking shared norms seriously. That discipline comes from accountability.

Aviation offers a useful analogy. Sterile cockpit rules eliminate nonessential conversation during critical phases of flight, not safety-critical challenge. If something is wrong, you still speak. What changes isn’t how much psychological safety is allowed. It’s how tightly decision rights, operating discipline, and accountability are enforced.

Your AI pilots and early experiments need maximum candor. A junior engineer questioning a model or vendor claim should have every opportunity to be heard. Once a decision moves into production, incident response, or customer-facing execution, accountability tightens. Psychological safety doesn’t go down; accountability goes up.

Culture won’t automatically make people trust AI

Here is another set of assumptions in this area for IT leaders to challenge: that inclusive leadership, meaning leaders who stay approachable and treat employees’ input as worth acting on, builds psychological safety, that psychological safety makes people comfortable with AI, and that comfort with AI drives adoption. The evidence is messier.

One recent study found that inclusive leadership did improve psychological safety, but psychological safety itself did not significantly predict trust in AI. What mattered more was an individual’s ability to tolerate uncertainty. That matters because AI adoption is an uncertainty event: Capabilities shift every few months, outputs can be confidently right and impressively wrong, and the impact on jobs, workflows, and careers remains unclear. Employees are being asked to exercise judgment around systems whose behavior is probabilistic, not deterministic.

Another study of employees in South Korea found that AI adoption was associated with lower psychological safety, which in turn was associated with greater employee depression. Ethical leadership, meaning leaders who are transparent and fair about what’s changing, softened that relationship but didn’t eliminate it. Neither study is universal proof — different countries, samples, and methodologies matter — but together they raise an important question for CIOs.

A healthy culture may help people absorb the disruption AI creates without necessarily making them trust the technology itself. Those are two different problems. One is organizational: Do employees believe they can question what is happening around them? The other is psychological and technical: Can they work productively when the tool is probabilistic, and do they know when to trust it, challenge it, verify it, or ignore it? That requires more than another culture initiative. It requires AI literacy, judgment, and comfort operating under uncertainty.

Your people may be honest. Just not with you.

A 2026 series of scenario-based experiments with participants in China found that employees were more willing to voice concerns to an algorithmic leader than a human leader during cognitive tasks. Perceived fairness and psychological safety helped explain the difference. That doesn’t mean employees want robots for bosses — the effect didn’t hold in the same way for emotionally charged situations — but for analytical work the finding is worth paying attention to. One possible explanation feels remarkably human: An algorithm can’t embarrass you at the next staff meeting, downgrade your reputation with the executive team, or remember that you challenged its favorite project six months ago.

Now think about what happens as generative and agentic AI become embedded in everyday work. Somewhere in your company, an engineer may tell an AI assistant that the proposed architecture is flawed, explain why, work through three alternatives with the model, then walk into a meeting an hour later and nod along while a senior leader advocates for the original design.

The concern existed. The organization just never received it. AI didn’t suppress the dissent; your management system did.

You’ve created a psychologically safe chatbot sitting inside a psychologically unsafe org chart, and your AI adoption dashboard will never show you the difference. Both employees look like successful AI users, one using AI to accelerate work, the other using it as the only place they feel comfortable saying what they really think. Usage looks identical. Organizational health doesn’t.

We spend a lot of time asking whether employees trust AI. We may need to spend just as much time asking whether they trust people enough to repeat what they already told it.

What only you can fix

First, keep psychological safety constant and let accountability flex by phase. Push for aggressive challenge during strategy sessions, architecture discussions, AI pilots, and early experiments, and make disagreement cheap before decisions get expensive. Once execution starts, tighten decision rights and expectations without closing the channel for legitimate safety, ethical, or operational concerns.

Second, stop measuring psychological safety only through sentiment. Ask whether dissent changes decisions: what major initiative was redesigned because someone challenged an assumption; what AI pilot was narrowed, delayed, or killed because someone surfaced a risk early; what executive decision changed because somebody several layers down challenged the prevailing view. If nobody can remember one, another engagement survey isn’t going to tell you much.

Third, build a path for concerns raised to AI to reach the human decision system. That doesn’t mean reading employees’ private AI conversations; doing that would create exactly the surveillance problem that destroys candor. Instead, design mechanisms that let employees elevate a concern without reconstructing it from scratch: an anonymized escalation channel, a prompt-to-retrospective workflow, a mechanism to flag questionable AI outputs, or a structured path from an AI conversation into an architecture or investment review.

The design question is simple: Can an employee move a concern discovered in an AI conversation into the organization’s decision process with one deliberate action? Increasingly, that’s where the concern may show up first.

None of this argues against psychological safety. It argues against assuming psychological safety works in isolation, or that human trust and AI trust are the same problem. AI is creating a second conversation inside your organization, one that happens in meetings, reviews, and Teams calls, and one that happens quietly between an employee and a machine.

The real question isn’t whether your employees trust the AI. It’s whether AI has quietly become the place where they say the things your organization most needs to hear.

Second Opinion offers technology leaders an evidence-based perspective on their most consequential decisions. Khalid Kark brings 25 years as a trusted advisor, researcher, and operator. In an enterprise technology market crowded with noise, this column separates signal from spectacle.