AI-agent confidence is running ahead of operational evidence

A Red Hat survey presents a sharp mismatch in UK enterprises: 97% of CIO respondents said they were confident that their AI agents operated securely and in compliance with regulation, but only 43% reported a precise understanding of where organizational data was stored and processed.

The result is not evidence that 97% of deployments are secure. It is evidence about executive confidence—and the same survey says the operational records needed to test that confidence are incomplete.

Three inventories, not one dashboard

Red Hat commissioned Censuswide to survey 1,400 CIOs across 14 countries between August 24 and September 1, 2026. All of the UK businesses surveyed said they had agents in production. Forty-one percent said they could fully rely on tested guardrails, continuous monitoring and automated intervention, while another 56% acknowledged minor gaps.

The visibility figures expose what those controls may not cover. Only 31% of UK respondents said they had a complete, continuously updated view of open-source components, versions, origins and direct and indirect dependencies. Although 83% reported that they could deploy a critical vulnerability fix within 24 hours, patch speed is useful only after a team can locate the affected component and identify the systems and data it can reach.

The third gap is external change. Thirty-eight percent said they use measurable, continuously monitored criteria for third-party AI providers. Another 36% assess providers before adoption but struggle to monitor them afterward, and 22% rely only on an initial evaluation. Models, endpoints, terms and data-processing paths can change after a procurement review has passed.

What platform teams need before deployment

For platform engineering teams, the survey points to three connected records that should exist before an agent receives production authority:

• Data lineage: log which datasets, retrieval stores, model endpoints and tools an agent accessed, including where processing occurred and which identity authorized it.
• Software provenance: maintain a current software bill of materials for the agent runtime and its transitive dependencies, linked to deployed workloads rather than kept as a build-time artifact alone.
• Provider evidence: continuously record the model and service version, policy evaluation, endpoint location and material vendor changes instead of treating the initial supplier assessment as permanent.

Those records need a common workload identity and timestamps so an incident can be reconstructed across the model gateway, retrieval layer, tool calls and underlying applications. Guardrail outcomes should be retained alongside the request path, not summarized only as pass/fail rates.

Confidence needs a falsifiable test

A useful governance claim is one that an operations team can disprove. “This agent cannot send regulated data outside an approved region,” for example, requires traceable egress, model-endpoint and data-classification evidence. “This agent is patched” requires a dependency inventory tied to the running image. “This provider remains acceptable” requires recurring checks against measurable criteria.

Red Hat’s survey does not independently audit any respondent’s controls, and its UK percentages come from self-reporting. Its value is the contradiction inside those responses: confidence is already high, while the evidence needed to verify it is not. Platform teams should treat traceability as a deployment gate rather than a compliance report produced afterward.