From the Red Hat edition of October 30, 2026
AI agent security with policy-driven access control: Red Hat proof of concept turns governance documents into tested data-access rules with asago
Red Hat (OpenShift AI and AI safety teams) · Strategic partner platform: agent data-access governance · Global (vendor engineering blog; insurance example)
- Publisher
- Red Hat Blog
- Original publication
- Red Hat blog, Oct. 27, 2026
- Source retrieved
- 2026-10-31
What happened
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
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.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-31; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Agencies building AI assistants over sensitive records cannot easily prove that each user role sees only the data its policy allows.
- Stakeholders
- Chief data officer or data governance lead
- CISO
- Program owners for case or student records
- Platform engineering lead
- Compliance and audit
- Discovery questions
- Which AI assistants touch data with role-based restrictions?
- Are data-access policies written down, and how often do they change?
- Do retrieval systems enforce per-user identity or a shared service account?
- How would you show an auditor that an agent respects policy?
- Value hypothesis
- Policy-derived negative tests may expose over-permissioned agent data access before production and give auditors repeatable evidence, if enforcement points support per-user identity.
- Potential engagement
- A proof of concept on one RAG assistant with two or three roles, producing tests, a baseline violation report and verified remediation.
- Unsupported claims
- Field-level PII masking
- Coverage of all enforcement points
- A production-ready product (asago is an early open source project)
- Any measured reduction in incidents
Pre-sales engineering
Role takeaway
- Fit
- Fits teams on OpenShift AI building RAG or agent workloads with feature stores, vector databases and MCP tools that support fine-grained authorization.
- Architecture and integration
- A translation and validation layer that reads governance documents, emits configurations for existing authorization engines and data stores, and runs scenario tests through an evaluation workflow.
- Prerequisites
- Written governance policy for the data domains
- Data stores that support per-user or per-role authorization
- An evaluation harness to run scenarios against the live assistant
- People to review generated rules
- Constraints
- Dataset-level control only in the PoC
- Each data store has its own identity model
- LLM-based policy extraction can misread policy text
- Security
- Reduces blast radius of prompt injection by scoping data access per role; relies on correct identity propagation from the user through the agent to each data store.
- Proof of value
- Run should-fail cross-role requests on the baseline and confirm detection
- Apply changes and confirm denial without breaking authorized access
- Have a person review generated rules against the policy text
- Change one policy and confirm re-validation catches drift
Delivery
Role takeaway
- Work
- Codify policy, generate scenarios, evaluate baseline, apply reviewed permission changes, rerun evaluation and document results and gaps.
- Dependencies
- Governance team availability
- Access to data store configuration
- Evaluation tooling
- Identity propagation through the agent stack
- Ownership
- Data governance owns policy content; the platform team owns enforcement configuration and test execution.
- Skills and adoption
- Teach governance staff to write policy that can be tested and platform staff to read and act on evaluation reports.
- Governance checkpoints
- Human review of extracted rules
- Approval of permission changes
- Re-validation after any policy change
- Acceptance criteria
- Proposed: all defined cross-role violations detected at baseline
- Proposed: zero violations on rerun with authorized access intact
- Proposed: re-validation completed within one change cycle of a policy update
- Risks
- False confidence from limited scenarios
- Shared service accounts defeating role scoping
- PII exposure at the field level
- Early-stage tooling changing quickly
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Adds a translation and validation layer between governance documents and existing enforcement points rather than a new runtime proxy. Needs integration with each data store's authorization model.
Governance
Who approves, reviews and stays accountable for outcomes?
Turns governance policies into testable artifacts and supports re-validation when policies change, which could support continuous compliance evidence for audits.
Security and privacy
What data, permissions and controls need testing?
Scoping agent data access by role limits the impact of prompt injection or exfiltration. Field-level PII masking remains unsolved in this approach.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Requires governance, data and platform teams to collaborate on machine-readable policy; few SLED agencies have this capacity today.
Procurement
What should contracts, pricing and exit terms secure?
Buyers can ask agent vendors how data-access policies are tested and re-validated, not only how tools are authorized.
Operating model
Which teams own the service once it runs?
Suggests a recurring policy-to-test pipeline owned jointly by governance and platform teams.
Publication history
- 2026-10-30Red Hat · Issue 026 resources
Stable resource ID: redhat-policy-driven-agent-data-access-control-asago-poc-20261027