{"resourceId":"redhat-policy-driven-agent-data-access-control-asago-poc-20261027","versions":[{"version":"external-61384c947475d54a4e0f4324629ab04595144eecdb3de53a683da0915bff878f","resource":{"id":"redhat-policy-driven-agent-data-access-control-asago-poc-20261027","title":"AI agent security with policy-driven access control: Red Hat proof of concept turns governance documents into tested data-access rules with asago","organization":"Red Hat (OpenShift AI and AI safety teams)","sector":"Strategic partner platform: agent data-access governance","geography":"Global (vendor engineering blog; insurance example)","publishedAt":"Red Hat blog, Oct. 27, 2026","publicationDate":"2026-10-27","eventDate":null,"sourceName":"Red Hat Blog","sourceLabel":"AI agent security with policy-driven access control","sourceUrl":"https://www.redhat.com/en/blog/ai-agent-security-policy-driven-access-control","evidenceClass":"vendor-claim","outcomeClass":"emerging","topics":["data-security","developers-agents","governance-procurement"],"finding":"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.","sledRelevance":"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":"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.","architectureImplications":"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.","governanceImplications":"Turns governance policies into testable artifacts and supports re-validation when policies change, which could support continuous compliance evidence for audits.","securityPrivacyImplications":"Scoping agent data access by role limits the impact of prompt injection or exfiltration. Field-level PII masking remains unsolved in this approach.","caveats":"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.","streamIds":["red-hat"],"roles":{"sales":"Sales framing: this addresses a real SLED worry, agents seeing data outside a user's role, but it is early-stage. Position it as a design conversation and a limited proof of concept for agencies building RAG assistants over mixed-sensitivity data, such as HHS case records or student records. Emphasize that the method tests whether access rules match written policy. Do not present asago as a finished product or claim field-level PII protection.","engineering":"Engineering framing: the approach extracts rules from governance text, generates configurations for existing enforcement points (vector database ACLs, feature store permissions, bucket policies, MCP allowlists) and validates them with positive and negative scenarios. In a pilot, check that generated rules are reviewed by people before being applied, that negative tests cover cross-role requests, and that each data store in the RAG path actually enforces per-user identity rather than a shared service account.","delivery":"Delivery framing: run this as a proof of concept on one assistant with two or three roles. Deliverables are a machine-readable policy, generated test scenarios, a baseline evaluation, permission changes and a rerun showing violations closed. Governance owns the policy text; the platform team owns enforcement configuration. Schedule re-validation whenever policies or data sources change, and record field-level PII as a known gap."},"roleDetails":{"sales":{"customerProblem":"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"],"discoveryQuestions":["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?"],"valueHypothesis":"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.","potentialEngagement":"A proof of concept on one RAG assistant with two or three roles, producing tests, a baseline violation report and verified remediation.","unsupportedClaims":["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"]},"engineering":{"fit":"Fits teams on OpenShift AI building RAG or agent workloads with feature stores, vector databases and MCP tools that support fine-grained authorization.","architectureIntegration":"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.","proofOfValue":["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":{"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.","skillsAdoption":"Teach governance staff to write policy that can be tested and platform staff to read and act on evaluation reports.","governanceCheckpoints":["Human review of extracted rules","Approval of permission changes","Re-validation after any policy change"],"acceptanceCriteria":["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"]}},"retrievedAt":"2026-10-31T03:11:43Z","enrichedAt":"2026-10-31T03:19:23Z","enrichmentBasis":"retrieved source","accessibilityWorkforceImplications":"Requires governance, data and platform teams to collaborate on machine-readable policy; few SLED agencies have this capacity today.","procurementImplications":"Buyers can ask agent vendors how data-access policies are tested and re-validated, not only how tools are authorized.","operatingModelImplications":"Suggests a recurring policy-to-test pipeline owned jointly by governance and platform teams.","sourceVerification":{"openedUrl":"https://www.redhat.com/en/blog/ai-agent-security-policy-driven-access-control","referenceExcerpt":"In the baseline configuration, the assistant could return claims information alongside permitted underwriting content.","promptVersion":"sled-research-v4.0","model":null,"basis":"agent-reported inspection"}}}]}