Strategic PartnersIssue 026 records
Red Hat
Red Hat's AI messaging this week centered on agents acting through governed layers, and this edition's evidence is almost entirely Red Hat-authored. An architect argues that AI recommendations only pay off when they trigger reviewed Ansible automation, and Red Hat's documentation confirms the Ansible MCP server has been generally available since June, though same-day coverage called it a preview. The documentation also warns that read-write mode risks hallucinated commands and that tool results go to external LLM providers unfiltered. A proof of concept tests role-based agent data access from written policy. A Red Hat-commissioned EMEA survey finds governance confidence outrunning visibility. Partner Atos reports that small models tuned on OpenShift AI matched a frontier teacher for a German public-sector customer, with undisclosed evaluation details. Red Hat also joined an NSF-backed UC Berkeley agent-efficiency project. No new US SLED deployment or independent evaluation was found.
- Evidence records
- 6
- Cross-source patterns
- 2
- Evidence classes
- 6 vendor claim
- Outcomes
- 4 emerging2 cautionary
- Source freshness
- 5 new this fortnight1 undated
- Research completed
- 2026-10-31
Choose a role to see its takeaway beside every record in the ledger.
Patterns across the evidence
Synthesis · Lighthouse Advisory interpretation
Red Hat's agent story is shifting from what agents can do to which governed layer they act through
Three Red Hat sources from this week converge on the same design rule: agents and AI recommendations should reach production systems and data only through an existing, permission-scoped layer. The ITOps post routes AI signals into reviewed Ansible job templates; the AAP documentation limits MCP actions to a user's RBAC with a read-only default; the asago proof of concept generates and tests role-based data-access rules. All three are vendor sources with little or no measured outcome data, and the MCP documentation itself warns of hallucinated commands and data sent to external LLM providers.
Operating questionFor each proposed agent, what governed layer does it act through, what token or role scopes it, and what negative test proves it cannot exceed that scope?
Supporting evidenceRed Hat (Ansible Automation Platform)Red Hat (Ansible Automation Platform documentation)Red Hat (OpenShift AI and AI safety teams)
Confidence in AI governance is running ahead of verification
Red Hat's EMEA CIO survey finds 86.7% confident in governing AI agents but only about a third with full open source dependency visibility or continuous AI-provider monitoring. Red Hat's agent-security engineers make the same point from the platform side: no systematic validation checks that configured enforcement matches governance intent. The MCP documentation adds that its gateway applies no extra filtering, so verification falls to token scoping and data hygiene. The survey is non-US and vendor-commissioned.
Operating questionWhat evidence, beyond policy documents and vendor assessments at onboarding, shows that AI data access, dependencies and providers are being verified continuously?
Supporting evidenceRed Hat (survey conducted by Censuswide)Red Hat (OpenShift AI and AI safety teams)Red Hat (Ansible Automation Platform documentation)
Evidence ledger
Full record · every source keeps its link and limitations
Atos proof of value for a German public-sector customer: fine-tuned small models on OpenShift AI for structured extraction from social media
Vendor and partner claim: in a proof of value for a German public-sector customer that required self-hosted models only, Atos used OpenShift AI (workbenches, Kubeflow Trainer) to fine-tune Phi-4 Mini 3.8B, Qwen 2.5 1.5B and Qwen 2.5 7B on synthetic data generated by an API-hosted teacher model, to extract 14 features from German social media comments into JSON and detect calls to violence. Training used 3 NVIDIA L40 GPUs. On a custom 34-point rubric across 39 evaluation runs, fine-tuned Qwen 2.5 7B scored 30.8 versus 30.5 for the teacher with a detailed prompt, and fine-tuned Phi-4 Mini about 30. Phi-4 Mini JSON validity rose from 1% (base) to about 99%, against 96% for the teacher. The companion Red Hat blog says fine-tuned Qwen 2.5 7B outperformed GPT-4.1 and Phi-4 Mini came very close; neither page explicitly states that GPT-4.1 was the teacher. Production deployment is described as a next step, not achieved.
Why it matters, evidence and limitations
- Why it matters
- Directly relevant to state and local agencies, fusion and public-safety analysts, and university research groups that cannot send sensitive text to hosted frontier APIs. It shows a pattern (synthetic data plus small-model fine-tuning on a self-hosted platform) for high-volume structured extraction. The customer is German and the use case is content monitoring, which in US SLED raises civil-liberties and First Amendment questions that the source does not address.
- Evidence and measured results
- Read the full developer article and the companion blog. The article reports the rubric design (28 points extraction, 3 JSON, 3 violence detection), 27 fine-tuned variants and 12 baselines, and headline scores read from figures. It does not report the size of the evaluation set, who graded the extraction answers, inter-rater agreement, confidence intervals, or whether evaluation data was independent of the teacher that produced training data. The article's lead says a 1-billion-parameter model beat the teacher, but the smallest model listed is 1.5B and the reported top score is the 7B model, so that claim is internally inconsistent.
- Limitations and uncertainty
- Vendor and partner self-report of a proof of value; unnamed customer; non-US context; no independent replication; evaluation set size and grading method not disclosed; internal inconsistency about a '1-billion parameter' model; production deployment not yet achieved.
Why ITOps needs a governed automation foundation for AI: Red Hat architect on separating AI recommendations from governed execution
Vendor practitioner claim: a Red Hat Ansible automation architect reports that customers adding AI copilots, AIOps or agents often see no operational change because execution still runs through the same handoffs and approvals. In one unnamed engagement, AIOps reduced duplicate alerts and improved grouping, but incidents on the same fault types took as long to resolve and needed the same number of manual production changes. The change came from wiring trusted signals into Event-Driven Ansible rulebooks that launched reviewed job templates. The post recommends one governed execution path for people, events and agents, review of AI-generated playbooks before promotion, and agent access only through the MCP server on Ansible Automation Platform tied to a user's token and RBAC.
Why it matters, evidence and limitations
- Why it matters
- Relevant to state and county IT operations, university central IT and K-12 district IT teams being pitched AIOps or agentic operations. It gives a test that suits public-sector accountability: count production work closed through the AI path with an auditable record, not dashboard confidence.
- Evidence and measured results
- Read the full blog post. It is an anecdotal practitioner account with one unnamed engagement and no quantitative before-and-after data, sample, baseline or timeframe. The recommendations are architectural guidance from a Red Hat employee promoting Red Hat products.
- Limitations and uncertainty
- Vendor blog by a Red Hat employee; one unnamed engagement; no measured outcomes; promotes Red Hat products. Third-party coverage of this post on Oct. 29 described the MCP server as a Technology Preview, but Red Hat documentation says it has been generally available since June 3, 2026.
Red Hat Ansible Automation Platform 2.7 documentation: MCP server is GA, read-only by default, and passes tool results to external LLM providers without added filtering
Vendor documentation states that the MCP server for Ansible Automation Platform has been generally available and fully supported in AAP 2.6 and later since the June 3, 2026 release. It uses a dual-layer model: a global read-only default that blocks job launches and configuration changes regardless of user rights, and an optional read-write mode limited by the RBAC of the user's API token. Red Hat warns that LLMs can misinterpret prompts or hallucinate commands, so read-write mode may cause unintended changes. With an external LLM provider, all tool call results (job details, inventory contents, host variables, IP addresses, DNS names, configuration) are sent to that provider. The MCP server adds no filtering or redaction beyond the AAP API; secret credential fields are masked, but credential names, types and usernames are visible. Red Hat collects anonymized telemetry from the MCP server.
Why it matters, evidence and limitations
- Why it matters
- Newly relevant because Red Hat's Oct. 29 blog directs customers to start agentic operations with this MCP server, and same-day third-party coverage misdescribed it as a Technology Preview. For state, county, university and district IT teams, the documented data flow matters: connecting a hosted AI assistant to AAP exposes infrastructure inventory to that provider, which may conflict with state security policy, CJIS or FERPA-related system rules.
- Evidence and measured results
- Read the AAP 2.7 MCP server overview page in full and the AAP 2.7 Extend guide PDF, which repeats the read-write risk warning. The page is vendor documentation with no publication date; it reports design and support status, not field results. The original Feb. 2, 2026 Red Hat blog introducing the server as a Technology Preview in AAP 2.6.4 was also opened to confirm the status change.
- Limitations and uncertainty
- Vendor documentation, undated page; describes intended controls, not tested behavior; no independent security assessment of the MCP server was found.
AI agent security with policy-driven access control: Red Hat proof of concept turns governance documents into tested data-access rules with asago
Vendor claim and proof of concept: Red Hat engineers argue that production agent deployments default to over-permissioning because data-access policies must be configured separately across vector databases, feature stores, catalogs, object storage and MCP tool servers, with no systematic check that configurations match governance intent. They describe a three-stage approach (extract rules from governance documents, generate enforcement configurations, validate with should-succeed and should-fail tests). In a proof of concept with a read-only RAG insurance assistant, the open source asago project generated risk scenarios; the baseline returned claims data to an underwriter, the evaluation flagged it, a permission recommender proposed changes for a data registry and Feast, and a rerun showed claims retrieval denied while authorized access remained. The authors say field-level (PII) control is not yet handled and that no single tool solves the problem.
Why it matters, evidence and limitations
- Why it matters
- Relevant to HHS, public safety and higher-education agents that must respect role-based data boundaries (caseworker vs. auditor, registrar vs. advisor). The test-driven idea of generating should-fail access scenarios from written policy maps to how agencies document data-sharing agreements. The example is from private insurance, so SLED applicability is inferred.
- Evidence and measured results
- Read the full blog. The PoC is a single scenario with one baseline violation and one remediation rerun; no scale, false-positive rate, coverage of policies or timing is reported. Opening statistics (70% with AI in production, 82% lacking runtime visibility, 21% with an agent inventory, 65% with an agentic AI incident) are linked to Cloud Security Alliance material that was not opened; a later 97% figure about security leaders expecting an incident has no visible source. asago is a Red Hat-led open source project.
- Limitations and uncertainty
- Vendor engineering blog; single proof-of-concept scenario; private-sector example; asago is early-stage and Red Hat-led; field-level control not addressed; cited industry statistics not verified and one (97%) unsourced.
Red Hat survey of 1,400 EMEA CIOs: high confidence in AI agent governance, low visibility into data flows, open source dependencies and AI provider risk
Vendor-commissioned survey: Censuswide surveyed 1,400 CIOs in 14 EMEA countries for Red Hat between Aug. 24 and Sept. 1, 2026. 86.7% said they were confident they could govern deployed AI agents securely and compliantly, but only 39.6% expressed complete confidence in total data visibility and 45.2% acknowledged minor blind spots in tracking data flows. 76% said they deploy critical security fixes within 24 hours, yet only 32.9% keep a complete, continuously updated view of their open source supply chain including nested dependencies, and 43.0% see only primary components. Only 34.4% set formal, measurable criteria to monitor AI provider risk continuously, and 19.7% do no continuous monitoring after onboarding.
Why it matters, evidence and limitations
- Why it matters
- Limited and indirect: the sample is EMEA enterprise CIOs, not US state, local or education leaders, and sector breakdown is not given. It is useful as a framing for SLED governance reviews, which often focus on procurement-time AI vendor assessment and patch speed, while the survey points to continuous AI-provider monitoring, SBOM depth and data-flow visibility as the weaker controls.
- Evidence and measured results
- Read the full blog including the methodology note (Censuswide, 1,400 CIOs aged 25+, 14 named countries, fieldwork dates; Censuswide is an MRS member). Self-reported survey with no published questionnaire, sector split, weighting or margin of error in the post. Commissioned and interpreted by Red Hat, which sells the platforms recommended in the conclusions.
- Limitations and uncertainty
- Vendor-commissioned, self-reported survey; EMEA enterprise sample, not US SLED; no questionnaire, sector breakdown or error margins published; conclusions promote Red Hat's open hybrid approach.
Red Hat joins UC Berkeley's Auto-Optimized Agents team in the NSF-supported STRIDE AI Efficiency Challenge
Red Hat says it, IBM Research and other partners will work with UC Berkeley's Auto-Optimized Agents team, which is building an open source stack that uses real usage traces to optimize deployed coding and enterprise agents end to end, in the NSF-supported STRIDE AI Efficiency Challenge run by Start2 Group. Nine teams can each receive up to $3.5 million; work began in September 2026 and the cohort met on Oct. 20. The Start2/STRIDE announcement lists Red Hat among the 'Problem Owners' committed to deploying technologies and reporting measured efficiency gains, and says teams pass three go/no-go stages toward preliminary deployments within 12 months and at-scale deployments within two years.
Why it matters, evidence and limitations
- Why it matters
- Relevant to research universities and research computing centers: it is an NSF-backed, university-led effort in which Red Hat is a named deployment partner, and it may produce open source agent-optimization tooling that runs on platforms universities already operate. No results exist yet, and the Red Hat-specific funding or deployment scope is not stated.
- Evidence and measured results
- Read the Red Hat Research post and the Start2 Group/STRIDE team-selection page. Both are announcements; no measurements, deliverables or Red Hat-specific funding amounts are given. The Start2 page describes the program structure and lists Problem Owners. The NSF page was not opened separately.
- Limitations and uncertainty
- Announcement only; no results; Red Hat's specific role and funding not quantified; program milestones are plans, not outcomes.
How to read this edition
Source findings, measured results and limitations come from the cited publications. Patterns, operating questions, role takeaways and implementation considerations are Lighthouse Advisory interpretation, stated as questions to validate locally rather than guaranteed outcomes. Vendor and operator claims are labeled as claims. Full research method.
- Vendor claim
- A supplier-provided assertion that has not been upgraded to independent evidence.