AI agent security with policy-driven access control

Agentic AI deployments are accelerating across enterprises. Recent research from the Cloud Security Alliance shows 70% of organizations now have AI components in production, yet 82% lack real-time visibility into AI runtime behavior. Furthermore, only 21% of organizations maintain a real-time inventory of their deployed AI agents. Even more concerning, 65% of organizations have already experienced a security incident tied to agentic AI.

These statistics point to a fundamental gap in how we secure agentic AI systems. We have robust authentication and authorization frameworks. We understand identity and access management. We understand sandboxing and are applying that to AI agents as well. The missing piece is translating governance policy into runtime enforcement. This isn't a Red Hat challenge or an open source challenge—this is an industry-wide problem requiring new approaches.

The over-permissioning crisis

Despite powerful building blocks consisting of protocols like OAuth 2.0 and OpenID Connect (OIDC) for user authentication, and authorization engines like Open Policy Agent (OPA), the default pattern in production agent deployments is over-permissioning. AI agents receive broad access to data sources because configuring fine-grained policies is complex, error-prone, and disconnected from how governance teams think about data access.

Consider a property and casualty insurance company. An underwriting agent needs access to risk assessment data and property valuations to price new policies. A claims adjuster agent needs access to policy details, claim history, and fraud indicators to process claims. A compliance officer agent needs read-only access to audit logs and regulatory filings. These are distinct roles with distinct data needs, yet the current state of agent deployments often grants all 3 agents access to the same superset of data.

Why? Because the alternative is manually configuring authorization policies across multiple enforcement points: the vector database, the feature store, the data catalog, the Amazon Simple Storage Service (Amazon S3) buckets, and the Model Context Protocol (MCP) tool servers. Each system has its own policy syntax, its own identity model, and its own configuration interface. The cognitive load is overwhelming. As a result, users can prompt agents to request data outside their role because the data is technically accessible.

Bridging governance and runtime control

Current agent controls take it for granted that someone has already defined what an agent is actually allowed to do with data for a given task.

This is the missing translation layer between governance and runtime enforcement. Governance teams write policies in natural language documents describing roles, data classifications, access boundaries, and compliance requirements. Engineering teams then configure enforcement across multiple systems. Each enforcement point has its own syntax, identity model, and configuration interface.

No systematic validation verifies these configured enforcement points implement governance intent. When governance policies change, there's no automated way to regenerate enforcement configurations or verify existing configurations still comply. The gap between policy intent and runtime behavior grows over time.

A second challenge compounds this problem. MCP and similar agent-tool protocols answer a tool-authorization question: may this agent invoke this tool or connect to this service? Data access control answers a different question: when that tool runs, which assets, records, and fields may it return for this user and task? That decision still has to be enforced across feature stores, data catalogs, vector databases, and object storage. The agent accesses each of these directly, and each has its own identity model and authorization mechanism. Creating a unified policy layer spanning all enforcement points requires coordinating multiple policy engines, identity providers, and enforcement mechanisms. This isn't just a configuration challenge. It's an integration problem no single tool solves today.

A new open source approach

An emerging approach treats governance documents—the free text documents governance, legal, and compliance teams write—as the source of truth and automates the translation to enforcement configurations. This isn't a new runtime proxy or a replacement for existing authorization engines, it's translation and validation layer sitting between governance and enforcement.

The core workflow has 3 stages. First, policy extraction analyzes governance documents to extract structured access rules. Natural language processing identifies roles, data sources, allowed operations, and access conditions. The output is a machine-readable representation of governance intent.

Second, authorization rule generation maps these extracted policies to enforcement configurations for existing systems. Access control lists for vector databases, permission policies for feature stores, bucket policies for object storage, tool allowlists for MCP servers. The goal isn't to invent a new policy language but to generate correct configurations for the enforcement points already in use.

Third, data access validation verifies that the generated configurations enforce the intended policies. This is automated red-teaming for data access. Generate test scenarios that should succeed: an underwriter agent requesting risk assessment data. Generate test scenarios that should fail: an underwriter agent requesting claims information. Execute both sets of tests against the live enforcement layer. If authorized scenarios fail or unauthorized scenarios succeed, the configuration doesn't match the policy.

Open source building blocks

The industry already has many of the pieces needed to implement this approach, but they aren't yet composed into a complete solution.

Agent runtimes provide execution environments. OpenShell offers sandboxed execution with identity integration and credential scoping. OpenClaw is evolving into providing an orchestration framework for coordinating multiple agents with pluggable security policies. Policy frameworks handle extraction and evaluation. Asago, an open source framework for policy-driven agent security, provides policy extraction from governance documents and scenario generation for validation testing. Protocols like MCP standardize agent-tool interactions and provide protocol-level hooks, but still require policy-driven configuration to control what data agents can access through those tools. Testing frameworks like Garak and evaluation automation tools such as EvalHub automate red-teaming and security testing.

These are composable pieces. No single tool solves the entire problem, but the building blocks exist. What the industry needs now is collaboration to chain these components together, standardize the interfaces between them, and create reference implementations enterprises can adopt.

What we tested

We used and extended asago to test a policy-driven data access workflow for a read-only retrieval-augmented insurance assistant. The assistant served users with different responsibilities through the same chat interface. An underwriter could retrieve underwriting guidance and property-risk information, but couldn't retrieve claims data. A compliance reviewer could retrieve information from both domains for oversight and audit.

The test started with a governance policy and a short description of the assistant's role, data sources, and expected access boundaries in plain text. Asago used those inputs to identify relevant risks and generate harmful scenarios violating the organization’s boundaries to test and subsequently inform the agent's access policies. The resulting artifacts were executed through an evaluation workflow.

Based on asago’s output of a risk scenario, we tested a cross-domain request from an underwriter. In the baseline configuration, the assistant could return claims information alongside permitted underwriting content. The evaluation identified that behavior as a policy violation. A permission recommender then used the policy-derived artifacts, the evaluation finding, and the deployed data-asset configuration to propose permission changes for the data discovery and retrieval layers. In this proof of concept (PoC), those layers were implemented with a data registry for asset discovery and Feast for retrieval.

After applying the recommended permissions, we reran the evaluation workflow. The underwriter could still retrieve underwriting information, but the claims retrieval was denied. The compliance reviewer retained authorized access to both domains. The result demonstrated a policy-derived test can identify a data-access gap, drive a reviewable configuration change, and verify the intended behavior after remediation.

Figure 1: Example of end-to-end flow for policy-driven data access

Industry implications

For data leaders, this approach offers a path from reactive to proactive data governance. Instead of discovering access violations through audits or incidents, you can validate runtime behavior matches governance documents before agents go into production. Policy changes trigger automated regeneration and revalidation of enforcement configurations. Governance becomes continuous, not periodic.

For security teams, this reduces the attack surface. Over-permissioned agents represent a broad attack vector because an agent with access to all data can be prompt-injected to exfiltrate any data. An agent with access scoped to its role limits the potential impact of a successful attack, however, and  boundaries are continually verified through automated boundary testing. Finally, audit trails connect every data access back to a specific role, task, and governance policy.

For platform teams, the open source nature of these building blocks matters. You aren't locked into a single vendor's authorization model or policy language, and you can adopt components incrementally. You can start with policy extraction from governance documents, add scenario generation for validation later, then integrate with your existing authorization engines. The path forward is modular, not monolithic.

Red Hat is participating in this ecosystem alongside the asago and MCP communities, as well as OpenShell and the Open Agent Safety Platform. We're exploring how Red Hat OpenShift AI can surface policy-driven access controls for agent workloads. The goal isn't to own the solution but to contribute to industry standards and open source tooling so policy-driven agent security is accessible to all enterprises.

The path forward

Agentic AI deployments are accelerating faster than security maturity. The gap between governance intent and runtime enforcement is real and measurable. The 97% of security leaders expecting an incident aren't wrong. Over-permissioned agents are a security incident waiting to happen.

The emerging open source tools for policy-driven access control offer a path forward. Policy extraction, authorization rule generation, and automated validation can help close the translation gap. Combining existing building blocks like OpenShell, MCP, and asago can create a unified enforcement layer spanning agent data access points.

Current approaches handle dataset-level access control. An agent either has access to a data source or doesn't, but real-world governance requirements demand finer granularity. Consider personally identifiable information (PII) within a claims dataset. A compliance officer may need full access, including PII, for audit purposes. A claims adjuster needs the case narrative but shouldn't see redacted personal identifiers. An underwriter shouldn't access the claims data at all. This field-level access control, where agents can access a dataset but specific PII fields are masked or excluded based on role, represents the next frontier. The policy-driven approach must evolve to express and enforce these granular controls.

No single vendor solves this problem. Industry collaboration is essential. Standards for policy representation, interfaces between enforcement points, and validation frameworks need to converge. The open source model accelerates this convergence by making the building blocks visible, composable, and improvable by the entire community.

If you're deploying AI agents in production, start asking these critical questions now. What is this agent allowed to do with the data, based on its task? How do you validate runtime behavior matches governance intent? What happens when your governance policies change? These questions don't have perfect answers yet, but the industry is actively building them.

Learn how Red Hat AI approaches agent security and explore the asago framework for policy-driven access control. The conversation is happening in open source communities, and your enterprise's requirements will shape the solutions that emerge. Join us.