{"id":4960,"date":"2026-04-06T17:33:16","date_gmt":"2026-04-06T15:33:16","guid":{"rendered":"https:\/\/gokhan-gokalp.com\/?p=4960"},"modified":"2026-04-06T17:45:28","modified_gmt":"2026-04-06T15:45:28","slug":"runtime-governance-for-ai-agents-policy-as-code-with-opa","status":"publish","type":"post","link":"https:\/\/gokhan-gokalp.com\/tr\/runtime-governance-for-ai-agents-policy-as-code-with-opa\/","title":{"rendered":"Runtime Governance for AI Agents: Policy-as-Code with OPA"},"content":{"rendered":"\n

In my previous article<\/a><\/em>, I tried to show how we can build a simple but practical AI Agent<\/strong><\/em> using Microsoft Agent Framework<\/strong><\/em> (MAF<\/em>) with deterministic routing and intelligent search.<\/p>\n\n\n\n

I also mentioned that I kept things simple on purpose and that in a production scenario there are other concerns that need to be addressed. Building the agent itself is really just the beginning. Once we start thinking about putting an agentic system in front of real users, one of these concerns is governance.<\/strong><\/p>\n\n\n\n

By governance I mean things like controlling which tools an agent is allowed to call, enforcing access policies based on user roles and having a centralized<\/strong> and auditable<\/strong> way to manage these rules. With growing regulatory attention around AI<\/em>, frameworks like the EU AI Act<\/strong><\/em>, I think having a predictable and auditable way to enforce these policies is going to become more and more important, especially when agents access data or perform actions on behalf of users.<\/p>\n\n\n\n

One approach to enforce these rules is embedding them in the system prompt, telling the agent what it should or should not do. But this relies on the LLM <\/em>interpreting those instructions correctly every time and prompts on their own are too fragile to rely on in production systems. Prompts can suggest behavior but they cannot enforce governance. <\/p>\n\n\n\n

So in scope of this article, I wanted to explore a more deterministic approach using Open Policy Agent<\/em><\/strong> (OPA<\/em>), where rules are enforced <\/strong>outside the LLM <\/em>and evaluated reliably every time.<\/p>\n\n\n\n

In one of my previous articles on supply chain security<\/em><\/a>, I had used OPA Gatekeeper<\/em><\/strong> to enforce policies at the infrastructure level in Kubernetes<\/em>. The idea here is very similar. Instead of governing what gets deployed, we focus on what an agent is allowed to do at runtime. <\/p>\n\n\n\n

There are several approaches to governance depending on how the agent is built. Enterprise platforms like Microsoft Foundry<\/em> already provide features such as RBAC <\/em>and content filters. Developer first frameworks like MAF <\/em>or LangChain <\/em>give us full control over the execution flow, which makes it straightforward to integrate OPA <\/em>as a centralized policy enforcement point. <\/p>\n\n\n\n

The nice thing about OPA <\/em>is that it is platform agnostic<\/strong> by design, so the same policies could potentially apply regardless of how the agent is built. OPA <\/em>can sit at an API <\/em>gateway or MCP <\/em>gateway which makes it a natural fit for enterprises looking to adopt Agentic AI<\/strong><\/em> without skipping their existing API <\/em>security and governance layers.<\/p>\n\n\n\n

In this article, I will try to show how we can extend the product search agent from the previous article by integrating OPA <\/em>as a policy-as-code<\/strong> layer to enforce tool level access control.<\/p>\n\n\n\n

Where Does OPA Fit In<\/h1>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

As I mentioned in my supply chain security article, OPA <\/em>is a general purpose policy engine<\/strong> that uses a declarative language called Rego <\/em>to define policies as code. In that article, I used it at the infrastructure level through OPA Gatekeeper<\/em> to intercept admission requests in Kubernetes <\/em>and enforce policies before containerized applications could run.<\/p>\n\n\n\n

Here, the idea is also very similar, but the layer is different. Instead of intercepting deployments, we intercept agent actions. When our agent decides to call a tool, we evaluate that decision against an OPA <\/em>policy before the tool actually executes. <\/p>\n\n\n\n

The flow looks something like this:<\/p>\n\n\n\n

<\/circle><\/circle><\/circle><\/g><\/svg><\/span>