Why blocking AI agents is not the answer

The default enterprise response to AI agent risk in 2026 is to block. Block Copilot. Block ChatGPT. Disable the AI features in Salesforce. Turn off the AI in SAP. The reasoning is straightforward: these agents can do real damage with valid credentials, the controls to govern them do not yet exist as named categories, the safest position is no agents.

The reasoning is wrong. Not on the risk picture — the risk picture is real — but on the response. Blocking is not a control. It is the absence of a control, and it produces three measurable harms that compound while the block is in place.

Harm one: opportunity foregone, on the EBITDA line

The productivity uplift from AI in knowledge work is now reasonably well measured. Multiple credible studies and enterprise reports put the uplift between five and fifteen percent across roles in marketing, finance, HR, legal, customer support, and engineering. In a 7,000-person organisation, the midpoint of that range is tens of millions of euros in EBITDA annually. The number compounds quarter on quarter.

Blocking does not leave that money on the table once. It leaves it on the table every quarter the block remains in place. A two-year block is two years of compounding productivity foregone, and competitors who did not block spend those two years getting better at the same workflows.

This is not a soft argument about modernisation. It is the kind of number that appears in board-level discussions of margin and growth, and in private-equity-owned businesses, in conversations about exit value. A buyer in 2027 looking at a company that still blocks AI in the back office will discount that company against an AI-native peer. The discount is real money.

Harm two: shadow AI is now the dominant deployment pattern in blocking enterprises

Every observed pattern shows the same thing. The moment an enterprise blocks sanctioned AI, employees route around the block. Marketing pastes campaign briefs into personal ChatGPT. Finance opens spreadsheets in home environments and uses Claude or Gemini to summarise. Engineers run Copilot on personal accounts on personal laptops. HR uses public LLMs to draft job descriptions including salary bands. Legal pastes contract clauses into chatbots to summarise.

In every case the data leaves the building, often without the controls that would have applied to a sanctioned tool. The block produces worse risk than allowing controlled access would have produced. The CISO is buying the same risk plus zero productivity plus zero visibility.

The argument that this is a workforce-discipline problem misunderstands the dynamics. The pressure to use AI is structural. Once one team’s quarterly results improve because they discovered a shadow workflow, every adjacent team copies the pattern. The block becomes a fiction maintained for the security review while the actual workload moves to whatever channel is closest to hand.

Harm three: regulatory exposure to “we did not have visibility” is asymmetric

Two emerging regulations make the blocking position particularly dangerous over the next eighteen months. The EU AI Act post-market monitoring obligations require organisations to detect, log, and respond to AI system behaviour. The Product Liability Directive 2024/2853 extends strict liability to AI-driven defects in products on the EU market and reduces the plaintiff’s burden of proof.

In both regimes, an organisation that blocked sanctioned AI and discovered after the fact that shadow AI was operating in marketing, customer support, or product is in a worse position than an organisation that allowed AI under controls and can produce a record. The block does not absolve the organisation; the obligation is to know what AI is doing, not to claim none was deployed.

A regulator’s question is the same in both cases: “what controls did you have over AI behaviour in your organisation?” The answer “we forbade it” is not a defence. The answer “we permitted it under runtime authorization, here is the log” is.

The alternative is not “allow everything”

The argument is not to remove controls. The argument is that the wrong shape of control is being deployed. Blocking is binary. The work an organisation actually needs is conditional: allow this action by this agent in this context with this audit record; refuse that action by that agent in that context with this audit record.

That is the function of a runtime authorization layer — IntentGate. It does for AI agents what privileged access management did for human admins: it lets the work happen, on terms the organisation can articulate, with the audit trail the regulator will ask for.

Concretely in a Versuni-style enterprise, that looks like:

Today the block: Copilot disabled for engineering. Engineers route through personal accounts. Source code leaks anyway, no record.
With runtime authorization: Copilot allowed. Each action — commit to repo, push to production branch, modify infrastructure — evaluated against policy at the moment of execution. In-scope actions execute. Out-of-scope actions refused with structured reason. Engineering gets the productivity. Security gets the record. The shadow channel closes because the sanctioned channel works.

The same pattern applies across SAP and Salesforce, customer-facing chatbots, embedded AI in connected products, supplier-facing AI workflows. Every workload moves from “blocked or invisible” to “allowed under runtime authorization, with audit.”

What changes inside the security organisation

Moving from blocking to controlled-allow changes the work of the security organisation in three concrete ways.

It changes the budget allocation. Less spend on tools that detect unauthorised AI use after the fact, more spend on tools that authorise individual actions at runtime. The category of spend shifts from monitoring to enforcement.

It changes the conversation with the business. The security organisation stops being the team that says no to AI projects and becomes the team that ships AI projects safely. That is a different professional identity for security teams, and it tends to be a more durable one because the business stops routing around it.

It changes the conversation with the board. A report saying “we blocked 4,500 unauthorized AI attempts last quarter” is a vanity metric. A report saying “we authorized 2.3 million AI agent actions last quarter, refused 18,000 out-of-scope attempts, and produced an audit trail conforming to NIST AI RMF and EU AI Act post-market monitoring” is a substantive report. Boards prefer substantive reports.

For CISOs in the blocking position today

The transition from blocking to controlled-allow is not a single decision; it is a programme. The programme runs in three phases.

Phase one is visibility. Before any policy changes, instrument the environment to measure what AI is actually happening today. Shadow AI baseline measurement across the back office. Volume of public-LLM traffic from corporate networks. Sanctioned tools being used outside sanctioned scope. The number tends to surprise the leadership team in a way that opens budget for phase two.

Phase two is one workload, controlled. Pick the workload with the cleanest risk picture and the strongest productivity argument. Run a 90-day controlled-allow pilot. Measure: incidents prevented, audit completeness, user adoption, productivity uplift. The pilot proves the model. Expansion to the rest of the estate becomes a budget question, not a philosophy question.

Phase three is the rest of the estate. Each subsequent workload follows the same pattern. Adoption compounds. By month twenty-four, the organisation has moved from blocking to controlled-allow across the entire AI surface, and the audit position is materially stronger than the blocking position ever was.

The CISO line for the board

“Blocking is not a control. It is the absence of a control, and the visibility our organisation needs is not produced by it. We are moving to runtime authorization for AI agent actions, which permits AI use under conditions we can defend in front of a regulator and produces the audit trail the EU AI Act and PLD 2024 require. The first workload pilots in Q3.”

That is what the board hears. That is the position that survives both the productivity conversation and the regulatory conversation. The blocking position survives neither.

Further reading on this site: What is IntentGate? defines the category. The Replit incident shows what happens when the runtime-authorization layer is absent. Standards Alignment maps the eight-domain framework to NIST, ISO, EU AI Act, OWASP.