Why security will not sign off your AI pilot, and what is actually missing

A reviewer cannot approve what nobody has described. 47% of CISOs say they can identify every AI agent in their environment, 46% can control what those agents access, and 45% can say what an individual agent is permitted to do. The refusal is a missing document, not an objection.

The pilot works. The demo landed. Security has not approved it, and the project has been waiting for weeks on something nobody can quite name.

Something specific is missing, and it is a document rather than a control.

What a sign-off actually requires

The three things a sign-off needs, and who can answer them

A reviewer cannot approve what cannot be described. Roughly half of security leaders report being unable to answer each question about their own estate.

81% of CISOs report concern about excessive AI access. The review is not obstruction. It is a reviewer being asked to sign a description that does not exist yet.

Source: Okta Global CISO Insights 2026, fielded by Apprize360 Intelligence with data finalised June 2026, n=306 CISOs, cybersecurity heads and senior security executives across the UK, Japan, the US, France, Canada and Germany. Vendor-commissioned.

An approval rests on three things being establishable. Which AI agents exist in the environment. What each one is able to reach. What each one is permitted to do.

Okta's Global CISO Insights 2026, fielded by Apprize360 Intelligence with data finalised in June 2026 across 306 CISOs, cybersecurity heads and senior security executives in the UK, Japan, the US, France, Canada and Germany, asked security leaders whether they could do those things in their own estates. 47% said they can identify all agents. 46% said they can control what agents access. 45% said they can authorise what an individual agent does.

It is vendor-commissioned and should be read that way. The shape is still the point: on each of the three questions an approval depends on, roughly half of security leaders report that they cannot answer it.

So when the answer comes back as no, the reviewer is not rejecting the system. They are declining to sign a description that has not been written.

Why refusal is the rational answer, not the political one

A reviewer who approves an unbounded system owns the consequence personally. Given a scope they cannot bound, no is the defensible position, and it stays defensible for as long as the scope stays unwritten.

The surrounding numbers make that worse rather than better. The same survey found 81% of CISOs concerned about excessive AI access, only 31% feeling fully aligned with their C-suite and board on what level of AI risk is acceptable, 46% feeling their board views AI security as a business enabler, and 39% citing budget and headcount as a barrier.

What security leaders are working with

The same survey. Read the bottom two together: the mandate is contested and the resourcing is short.

• Concerned about excessive AI access
• See at least some unsanctioned AI use
• Feel their board views AI security as a business enabler
• Cite budget and headcount as a barrier
• Feel fully aligned with the C-suite and board on acceptable AI risk

Source: Okta Global CISO Insights 2026, fielded by Apprize360 Intelligence, data finalised June 2026, n=306 security executives across six markets. Vendor-commissioned.

Read the last three together and the review meeting looks different. The person being asked to approve has a contested mandate, a board that may not see their function as an enabler, and no spare capacity to do the scoping work on your behalf. That work has to arrive with the request.

Agent identity is usually the actual blocker

One finding in that survey explains more refusals than any other: 21% of organisations govern AI agent access with shared credentials or broad-permission service accounts.

An agent authenticating as a shared service account inherits everything that account can reach, which is almost always far more than the use case needs. Two consequences follow, and both are fatal to an approval. The blast radius cannot be stated, because it is the service account's radius rather than the agent's. And no log can attribute an action to a specific agent afterwards, so there is no post-incident account.

A reviewer who asks what the agent authenticates as and hears the name of a shared integration account has finished the review. Everything after that is negotiation.

The risk the industry is now naming

What OWASP changed for LLM applications in 2026

Published 4 August 2026. The ranking was weighted 75% community vote and 25% real-world incident data, which is worth knowing before quoting a position as an incident frequency.

Excessive agency moving from sixth to third is the part to put in front of a reviewer, because it names the gap as a permissions problem rather than a model problem.

Source: OWASP Top 10 for LLM Applications, 2026 edition, published 4 August 2026.

OWASP published the 2026 edition of its Top 10 for LLM Applications on 4 August 2026. Prompt injection held first place and sensitive information disclosure second. The significant move was excessive agency, from sixth to third. Improper output handling fell from fifth to tenth, and system prompt leakage was renamed hidden context exposure.

One methodological note before anyone quotes a position as an incident frequency: the ranking was weighted 75% community vote and 25% real-world incident data, and OWASP itself observes that prompt injection held first despite a thin incident record, which it attributes to heavy investment keeping successful attacks out of public databases. A list position is a judgement about risk, not a count of breaches.

The direction is the useful part, and it matches the access findings exactly. Attention has moved from what the model says to what the model is allowed to touch. That reframes the review from a model-quality question, which you cannot settle, to a permissions question, which you can.

What the comparison actually is

The instinct is to argue that the pilot is safe. The stronger argument is about the alternative.

68% of CISOs in the Okta survey see at least some unsanctioned AI use in their organisation. So the real comparison is not your reviewed pilot against nothing. It is your reviewed pilot, with a written scope and a named owner, against tools already in use with neither.

That argues for making the sanctioned path cheap to approve rather than for relaxing the review, and it is a more honest case to put to a CISO than an assurance that your pilot is fine.

What getting through looks like

The governance engagements in our case library ran 12 to 22 weeks, and six of them published a zero-findings outcome at the next audit, exam or review.

An enterprise SaaS company that had grown to four product lines through acquisition cut SOC 2 audit preparation from eight weeks to five days, freed roughly seven engineer-weeks per audit, had no auditor findings in the first audit afterwards, and shortened enterprise sales cycles by three weeks because the same evidence answered the security questionnaires. See the SOC 2 governance engagement.

A university system had $6.8M of federal research funding conditional on certifying its research data infrastructure within 16 weeks across 14 departments, with 31 identified gaps. Cataloguing, access controls, lineage tracking and reproducibility documentation closed all 31 by week 14. See the research data certification engagement.

A regional bank went into a regulatory exam having had four data quality issues flagged at the previous one, and came out with zero matters requiring attention.

In each case the evidence existed before the reviewer asked for it, which is the whole difference.

What we would do first

Write the scope on one page, before the next review meeting. Every data source the system may read, named. Every action it may take, split into read and write. What it explicitly may not reach. What identity it authenticates as and whose permissions it inherits.

Most teams find they cannot answer the identity question. That is not a setback, it is the finding, and it is the thing to fix first.

Which of the two remedies to fund, and in what order, is in scope the permissions or add guardrails. What a reviewer needs in front of them is in what an AI security review needs from you. If the pilot is stalled for reasons that turn out not to be security at all, the triage is in fix data, integration or governance first.

Delivery sits in AI security consulting for the scope and the adversarial testing, AI governance managed operations for running the controls afterwards, MLOps consulting for the logging and monitoring layer, and EU AI Act compliance where the obligation is regulatory. The full set of work in this area sits under AI is too risky to approve.

Frequently asked questions

Why will security not approve an AI pilot that works?

Because working and reviewable are different properties, and the reviewer is being asked to sign a description that does not exist. An approval requires three things to be establishable: which AI agents exist, what each can reach, and what each is permitted to do. Okta's Global CISO Insights 2026, fielded by Apprize360 Intelligence with data finalised June 2026 across 306 security executives, found 47% saying they can identify all agents in their environment, 46% that they can control what agents access, and 45% that they can authorise what an individual agent does. With roughly half unable to answer, the defensible response to a request for approval is no.

Is the review being obstructive?

No, and treating it that way lengthens it. A reviewer who approves an unbounded system owns the consequence personally, so the absence of a written scope makes refusal the rational choice rather than the political one. The same survey found 81% of CISOs concerned about excessive AI access and only 31% feeling fully aligned with their C-suite and board on what level of AI risk is acceptable. The disagreement is upstream of the review meeting.

What specifically is missing?

A written scope: every data source the system may read, named; every action it may take, split into read and write; what it explicitly may not reach; what identity it authenticates as and whose permissions it inherits; what happens to the data it reads, including retention and whether it leaves your tenancy; the human review step with a named signer; and adversarial test results against that scope. One page covers most pilots. Without it there is nothing concrete to assess.

Why is agent identity such a problem?

Because many deployments never gave the agent one. In the Okta survey, 21% of organisations govern AI agent access with shared credentials or broad-permission service accounts. An agent that authenticates as a shared service account inherits whatever that account can reach, which is usually far more than the use case needs, and no log can attribute an action to a specific agent afterwards. That single fact often accounts for the whole refusal.

Has the industry view of the main risk changed?

It has shifted from what the model says to what the model is allowed to touch. OWASP published the 2026 edition of its Top 10 for LLM Applications on 4 August 2026, keeping prompt injection first and sensitive information disclosure second, promoting excessive agency from sixth to third, and dropping improper output handling from fifth to tenth. Worth knowing before quoting a position as a frequency: the ranking was weighted 75% community vote and 25% real-world incident data.

Does shadow AI make this worse?

It changes what the refusal is protecting against. 68% of CISOs in the Okta survey see at least some unsanctioned AI use, so the realistic comparison is not your reviewed pilot against nothing, it is your reviewed pilot against tools already in use with no scope at all. That is an argument for making the sanctioned path easy to approve rather than for relaxing the review.

How long does it take to get to a signature?

The governance engagements in our case library ran 12 to 22 weeks, and six of them published a zero-findings outcome at the next audit, exam or review. A SaaS company cut SOC 2 preparation from eight weeks to five days with zero auditor findings in the first audit afterwards. A university system closed 31 identified infrastructure gaps across 14 departments by week 14 of a 16-week deadline, which released $6.8M of conditional federal funding.

What should we do first?

Write the scope before the next review meeting, on one page. Name the sources, the actions split into read and write, the explicit exclusions, and what the agent authenticates as. Most teams discover while writing it that they cannot answer the identity question, which is the finding. Taking that page to the reviewer converts the conversation from a request for trust into an assessment of a described system.

The work behind this

Eighteen engagements in the case library carry governance, privacy and security. Six of them published a zero-findings outcome at the next audit, exam or review, including a SOC 2 audit that went from eight weeks of preparation to five days.

Governance, privacy and security, 18 engagements.