Rules Aren’t Enough to Control AI Agents

Do you think rules-based enforcement is enough for Agentic AI? For autonomous operation and real-time inferencing by agents? Are policy engines, AI/MCP gateways and firewalls really enough to understand the situations your LLMs and autonomous agents are operating in?

I was asked a simple, but fundamentally important question by someone on our team recently about policy-based enforcement for AI agents: are we really just talking about rules? My answer was no. Or at least, not entirely.

Rules are absolutely part of the equation, and enterprises obviously need rules. Regulations by their very nature create rules, even if we don’t always understand them. Contracts create rules. Security teams create rules. Boards, managers and supervisors create rules, and the list goes on. Credit agreements, privacy requirements, internal policies and operating procedures all create boundaries around what people and systems are allowed to do. The world is filled with rules.

The problem is that rules alone don’t tell you how those boundaries apply to the situation happening right now.

That distinction matters a lot as enterprises move from traditional software and workflow automation into autonomous AI agents. Most of the policy infrastructure we have today was designed around a relatively predictable human-workforce world. Something happens, the system evaluates a set of conditions, and an action is either permitted or denied. Humans are very much plugged into that loop, and those humans are trained, aware of the situation, and ultimately held accountable.

Agentic AI changes that equation because it is autonomously processing, interacting and acting. An agent may be acting on behalf of a person, operating across multiple systems, working with different kinds of information, invoking other agents and tools, and changing the situation as it proceeds. What that agent, or group of agents, is permitted to do can change from one step to the next.

That requires something more than rule enforcement. It requires intelligent, situationally aware Decisioning.

The Rule Versus Understanding the Situation

Traditional policy enforcement in tech is generally structured. We describe the conditions we expect to encounter and then tell the system what to do when those conditions occur. It’s very if-then-else rules oriented, with different syntaxes for describing those rules.

• If the user has this role, allow access.

• If the transaction exceeds this amount, require approval.

• If this data is classified as confidential, prevent it from leaving this environment.

These are obviously simple examples, and there is nothing inherently wrong with these types of rules. The problem is assuming that defining them means we’ve solved the control problem … and we haven’t. In today’s business world, we still rely heavily on human gatekeepers to catch the exceptions and keep things on track. Be forewarned … without the right Decisioning infrastructure, it gets a lot harder when autonomous agents start acting on their own.

Consider something as ordinary as signing authority in a company. This is the world I, and many others, live in, and keeping track of all these rules is massively headache inducing. So much so that we surround ourselves with more people to keep track of them and keep us honest.

On paper, it can look quite simple. A Board resolution might authorize the CEO to execute an agreement on behalf of the company. I’m actually looking at such a case right now. In a traditional rules-based permissions model, you could reasonably translate that into something such as

Kevin → authorized signer → agreement

The Board signed a resolution, so that should be enough. Except that’s not how the real world works.

My authority to sign is dependent on many factors that even the Board might not be aware of, including the specifics of the transaction. A shareholder agreement may place limits on that authority. An investor side letter may create additional restrictions and, in a particular circumstance, may effectively override what otherwise looks like general authority. A financing round may introduce new consent rights. A transaction above a certain value may require additional approval. A change-of-control provision may require creditor consent.

I may therefore have a valid Board resolution authorizing me to execute an agreement and still not have the authority to execute that particular agreement at that particular moment.

Nothing about my title has changed. The Board resolution may not have changed. But the situation has changed. That is situational authority … and I did say it was headache inducing.

Authority Is Not a Static Permission

Let’s get one thing straight. Authority has never really been a static permission. We just deal with it in a very human way. That becomes much more important when we start delegating authority to AI agents.

Suppose I authorize an agent to negotiate or execute certain commercial activities on my behalf. A conventional system may record that delegation and conclude that the agent has the necessary authority. But delegated authority can’t be greater than the authority I actually possess.

If a transaction crosses a threshold that requires creditor approval, the agent shouldn’t be able to proceed simply because I previously delegated authority to it. If a change-of-control provision is triggered, the situation changes. If a required approval hasn’t yet occurred, the situation changes again. If the underlying data doesn’t meet certain conditions, the permissible action may change even though every other aspect of the transaction remains the same.

So the real question isn’t whether the agent has permission. The real question is much closer to this …

Given the authority that has been delegated, the transaction being contemplated, the agreements currently in force, the approvals that have occurred, the conditions that remain outstanding, the information involved and the state of the workflow right now, what is this agent permitted to do next?

That isn’t a lookup against a permissions table. It’s a decision humans make all the time, usually by pulling together context, experience, policy, agreements and whatever else matters in the situation. If we’re going to delegate real authority to autonomous agents, we need to translate that same kind of situational decisioning into the world of Agentic AI.

Policy Engines May Not Understand the Situation

This is where the discussion becomes important for the current generation of policy tools being considered for Agentic AI. Technologies such as OPA, Cedar and other policy engines are useful, and we actually like some of them for their Infrastructure-as-Code approach. They can allow enterprises to describe policies and evaluate them efficiently. They can incorporate attributes and structurally limited context into a decision, and more sophisticated implementations can handle highly granular authorization logic.

But there is an important difference between evaluating the structured rules and context you’ve been given and understanding the actual situation you are operating in.

The same issue applies to the endless wave of AI/MCP gateways and firewalls. They can be useful for inspecting prompts, responses, tool calls and data moving across specific boundaries. But inspecting what is crossing the boundary isn’t the same thing as understanding why it is crossing, what authority sits behind it, what happened three steps earlier in the workflow, or what that action changes next. Their natural view is the interaction crossing the boundary, not the broader situation around it.

A policy engine might be told that a transaction is worth $5 million, that the user has signing authority and that the transaction is being executed in Germany. It can evaluate those facts against a policy if that policy is well constructed and there is a match between the elements of the transaction and the policy as it was defined.

That’s a pretty big IF … because the harder question is whether those are actually the right facts.

Does the transaction trigger a creditor consent provision? Does an investor side letter modify the authority granted somewhere else? Does the transaction constitute a change of control under one agreement but not another? Does the presence of a particular customer, entity or type of data introduce another jurisdiction? Did something earlier in the workflow change which approval regime now applies?

And did you even get all the right facts to begin with?

A policy engine can perfectly evaluate the wrong situation if the information provided to it is incomplete, incorrectly understood or simply missing something that matters.

That is one of the central problems with applying traditional policy enforcement to Agentic AI. The hard part is increasingly not evaluating the rule. Computers are already very good at that. The harder problem is determining which rules matter, how they interact, what takes precedence and how they apply to what is actually happening right now.

That requires situational awareness, not just better rule syntax.

The Problem with Cross-Jurisdictional Rules

As alluded to earlier, regulated industries already live with this problem every day. That’s one of the reasons there are so many people involved in managing regulation and compliance. Even if you’re operating primarily in the United States, you may still have to deal with European rules and regulations, Canadian requirements, and then state-level requirements in places such as New York and California.

And this isn’t just a financial services problem. If you’re in manufacturing and managing a cross-border supply chain, you can run into many of the same jurisdictional issues around data, products, suppliers, customers, trade requirements and contractual obligations.

A global financial institution may operate under privacy law, banking regulation, contractual restrictions, data residency requirements, internal risk policies, customer agreements and regulatory guidance across multiple jurisdictions. No individual policy necessarily has to be particularly difficult to understand. The complexity comes from the interaction between all of them.

A customer may be in the United States. A counterparty may be in Asia. Processing may occur in Europe. The underlying contract may contain a data residency provision. One type of information may be permitted to move while another may need to be protected. A particular transaction may trigger additional reporting requirements. An internal risk policy may be more restrictive than the regulation itself.

And of course, the situation can change halfway through the workflow.

Humans have difficulty navigating these environments today. That’s one of the reasons highly regulated organizations employ armies of legal, security, privacy, compliance and risk professionals. Even with all of those people involved, mistakes happen and interpretations differ.

Now imagine autonomous agents making thousands or millions of decisions across those same boundaries at machine speed.

Trying to solve that problem by simply writing more rules eventually becomes its own problem. The rule base gets larger, the number of possible combinations expands, exceptions and conflicts accumulate, jurisdictions overlap and the cost of maintaining all that policy logic starts to climb.

More importantly, no human policy team can realistically anticipate every permutation of every situation an autonomous system may encounter. You can keep writing more rules, adding more exceptions and creating more conditions, but at some point you’re trying to describe a changing world in advance. The answer can’t simply be better rule writing.

Decisioning Is Situational

The team in CharliAI Labs already understood a lot of the complexity in rules-based processing because they’ve come from highly regulated industries, including aerospace and energy. This wasn’t a theoretical problem for us. It was one of the things that had to be solved if autonomous agents were actually going to operate inside real enterprises. That’s where Decisioning starts from a different premise.

Before the system can determine how a policy should apply, it needs to understand the situation. Who is acting? On whose behalf? What authority has been delegated? What are they trying to accomplish? What entities are involved? Which relationships actually matter? What policies, agreements or restrictions apply? Where are we in the workflow and what has already happened?

The important word in all of that is situational.

The same action may be perfectly acceptable in one situation and prohibited in another. The same person may have authority in one transaction and not another. The same information may be fine to provide to an agent in one workflow but need to be protected in another. A customer record used for customer service may carry very different obligations when it suddenly becomes part of a credit decision, an investigation or a cross-border transaction.

That’s why Decisioning isn’t simply another way of writing a more complicated rule. It’s about understanding enough of the situation to determine which rules matter, how they apply and what the agent should be permitted to do next. The rule may not have changed … but the situation most certainly has.

The Importance of Ontology and Entities

Before getting too far into solutioning, it’s important to understand the data. This is where ontology becomes far more important in agentic systems than it has been in many traditional enterprise applications, especially those that have been built in silos.

Ontology is often described as a formal model of things and their relationships. That definition is fine, but it can also be misleading when you look at how it gets implemented in the enterprise. These models can become relatively static, rigid and brittle. We define a customer, an account, an employee, a contract, a supplier, a transaction … and then define the relationships between them.

That can be useful for a particular case, but it’s not enough for autonomous operation because the relationships that actually matter are situational in nature.

A single agent operating on its own has limited utility and can generally be contained. But that’s not really what Agentic AI is about. It’s about automation across business workflows, not unlike what we tried to accomplish in the early days of RPA, except now the software can reason, adapt and decide what to do next. In the RPA world, it was still us humans handling the edge cases, exceptions and day-to-day changes that inevitably cropped up.

Consider the signing authority case mentioned earlier. The relationship and the rules might initially appear trivial. Kevin is an authorized signer. The Board approved the transaction. Done.

Except the situation we actually find ourselves in is much more complicated and nuanced. There are agreements, side letters, creditor rights, transaction thresholds, conditions and approvals that may all change what that signing authority means in this particular case. So the decision gets bandied about, discussed, checked and eventually made … by humans.

That is why Agentic AI systems need something closer to a situational ontology. The system needs to understand not only what an entity is, but what that entity means in the context of the current workflow and the current lay of the land in the business. In more common terms, it needs situational awareness.

This becomes particularly important with data moving throughout the enterprise. Autonomous agents don’t simply pass parameters or fields between applications. They trade data. Sometimes that is a complete customer record. Sometimes it is a contract, an account, a transaction or a document. Sometimes it is only a fragment of information pulled from somewhere else.

A simple person’s name may be harmless in one situation. Combine that name with an account, an investigation, a medical condition, a location or a financial transaction and the meaning changes dramatically. The data itself may not have changed, but what it represents in that situation has.

Entity relationships matter because meaning changes with context. If an AI control system isn’t entity-smart, it’s going to have a very difficult time being situationally aware.

Governance and Orchestration are Bedfellows

This leads to another area where I think traditional thinking and implementation breaks down in the world of Agentic AI. Even the frontier models argued with me on this point … at least initially.

Governance and orchestration are often treated as separate functions, separate systems and separate technologies. The orchestrator decides what happens next, either through a scripted workflow or something more dynamically adapted. Governance determines whether what is happening is acceptable according to the rules and policies that have been defined.

That separation becomes difficult (err, pretty much impossible) to maintain with autonomous systems. And to be clear, these functions are bedfellows in that they are not strangers to each other even though they operate as distinct functions.

If governance determines which agent is eligible to act, what information that agent may receive, which tools it may use, what authority it may inherit, whether another agent can be invoked and whether the workflow is allowed to continue, then governance is already directly shaping the orchestration.

Imagine an autonomous workflow where Agent A completes an analysis and the orchestrator wants to invoke Agent B. The governance decision can’t be divorced from that orchestration decision by simply checking whether Agent B is generally approved. In a real control plane, governance and orchestration become deeply intertwined because the permitted path through the workflow is itself part of what needs to be governed.

The control plane may need to determine whether Agent B is appropriate for this particular workflow, whether it can receive all of Agent A’s output, whether sensitive information needs to be protected first, whether the delegated authority extends to the next action, whether another approval is now required and whether that next step creates a new jurisdictional obligation.

And, oh by the way, the decision around Agent B is entirely situationally dependent on what happened before it. Agent A may have discovered something, changed something, created a new relationship between entities or pushed the workflow across a threshold that didn’t exist a moment earlier.

So the permitted path through the workflow is not separate from the governance decision. It is part of the governance decision itself.

LLMs Don’t Scale. Harsh But True

The obvious response from techies and scientists to all of this is going to be performance and latency, even before getting into the technicalities of adapting to different situations and use cases.

If Decisioning requires this much complexity and context, do we need to pass every agent action through an LLM and ask it what to do? For those that don’t really understand how LLMs work, that can seem like the obvious answer … they’re intelligent, aren’t they? That was sarcasm, and the answer is definitely no.

In fact, putting an LLM into every decision would create a whole new set of problems. You would be layering another probabilistic process on top of an already probabilistic agentic process. You’d add latency, massively increase cost and introduce unnecessary nondeterminism into an enforcement path that is supposed to provide deterministic control.

The challenge isn’t to use an LLM for every decision. The challenge is knowing when intelligence is actually required and when the situation has already been sufficiently understood to make a fast, deterministic decision.

An advanced Decisioning Infrastructure needs to establish the relevant guardrails, authority, entity relationships, jurisdictional conditions and workflow state, and then use that understanding to make large portions of the runtime path fast and deterministic. Some situations will require deeper interpretation. Many won’t. Once a decision boundary is understood, the control plane shouldn’t have to reconsider the entire world every time an agent invokes a tool, accesses data or hands work off to another agent. It should be able to apply what it already knows until something material in the situation changes.

And that last part is important.

This is where a lot of the innovation in agentic control will occur … not simply in making policy evaluation faster, but in understanding when the situation has changed enough that the decision itself needs to be reconsidered. That’s how you get intelligent Decisioning without putting an LLM in the middle of every transaction.

Rules Still Matter

Scientists and engineers will likely challenge the Decisioning premise and ask what’s really different from what we have today.

I’m not suggesting rules are disappearing. They’re table stakes, they’re necessary, and we use them inside our own Forensic Control Plane. In fact, we rely on rules for deterministic enforcement over Decisioning. It’s not one versus the other.

If you want to scale autonomous operation, you need intelligent, situationally aware Decisioning inside deterministic boundaries. That’s the basis of what we refer to as Policy-Constrained Decisioning.

Enterprises still need explicit policies, contractual restrictions, security controls and hard boundaries. There are plenty of situations where the answer should simply be no, and no amount of contextual reasoning should change it. The mistake is believing that the rule itself contains enough understanding to govern autonomous operation.

Rules define the boundaries. Situational awareness determines which boundaries matter right now and how they apply. Decisioning determines what is permitted. The Control Plane then enforces that decision as the workflow proceeds.

That is very different from taking traditional policy infrastructure, adding a perimeter control, attaching it to an AI agent and assuming the governance problem has been solved. Agentic AI is going to operate in a complex, cross-jurisdictional world where conditions can change quickly. Supply chains shift. Export controls change. Data restrictions change. Contracts, approvals and operating conditions change.

Humans already struggle to keep up with this today. They certainly won’t be able to manually review every decision made by autonomous agents operating at machine speed.

That’s where Decisioning matters. Not because it replaces rules, but because it understands how those rules apply to the situation happening right now.