The Problem with Trusting the Model
Every conversation about AI autonomy — AI systems that take actions on their own, not just answer questions — eventually runs into the same uncomfortable question: who is actually deciding what an AI agent is allowed to do?
In a multi-agent flow, one AI agent may hand work to another, which may hand it to a third. At every handoff, the system is trusting each agent in the chain to behave as expected.
That presumed trust is the weak point.
Large language models — the AI behind these agents — are, by design, non-deterministic. Ask the same question twice and you might get two different answers or two different actions. That’s useful when you want creativity. It’s a problem when the same unpredictable model is deciding whether to delete a file, move money, or hand over a customer record.
AI models can also be talked into ignoring instructions or going beyond the task they were given. This is a known and repeatable way things can go wrong.
At the same time, security weaknesses are becoming easier to find and combine. For a deeper look at how the threat landscape is evolving, see the OCI CISO perspective on Cybersecurity in the Age of Frontier AI.
A single weakness may not cause a breach on its own. The bigger risk comes from chaining weaknesses together: a tool with slightly too much access, an AI that misunderstands what it’s allowed to do, and no independent control checking the result.
Individually, these weaknesses may be manageable. Together, they can become a serious problem.
We’re not trying to build a smarter agent
We are not trying to make AI agents smarter, faster, or better at their jobs. The industry is already working on how agents plan, reason, and communicate.
That work doesn’t answer the question we started with: who decides whether an agent’s action is actually allowed?
The core rule we build around is simple: an agent never approves its own action.
Instead of asking the model to police itself, we put a deterministic policy layer in front of its actions. That layer evaluates clear authorization rules and returns a predictable allow-or-deny decision.
There are several ways to build this. You could write the checks yourself or use an existing policy framework. In our implementation, we use OPA (Open Policy Agent), an open-source policy engine designed for this kind of decision.
OPA doesn’t replace OCI IAM. OCI IAM establishes the trusted principal and the OCI permissions available to that principal. The policy layer places a narrower boundary around what an agent can do on that principal’s behalf.
In practice, this means an agent may be allowed to do less than the user could do directly.
Every authorization decision considers three things: who is asking, what they asked the agent to do, and what company policy allows.
The request itself is also constrained. It is scoped to a specific task, given a time limit, and locked once established. If the agent tries to operate outside that boundary, the action is blocked before it runs.
Why one checkpoint isn’t enough
A single check, no matter how well designed, is still one point that can fail.
That’s why every action passes through two independent checks.
First: does this specific action match the task the agent was given?
Second: does company policy allow this principal, in this situation, to perform this action through the agent?
Neither check depends on the other’s judgment.
If the intent check allows something too broad, the policy check still evaluates the requested action independently. If policy has a gap, the scoped and time-limited task still limits what the agent can do.
The goal isn’t to assume either check is perfect. The goal is to make sure one mistake doesn’t automatically become a much larger problem.
Putting the idea to the test: the Intent Authorization Engine
To test this approach end to end, we built a small prototype called the Intent Authorization Engine (IAE). This is not a new OCI service. It is a reference implementation for demonstrating how these controls can work in an agent workflow.
The IAE places a control layer in front of agent actions. It checks each action against the locked intent and company policy before allowing it to proceed. Every decision is logged.
Here’s what that looks like.
Imagine a user asks an agent:
“Show me this month’s sales report.”
The user’s identity is verified through OCI IAM, tying the request back to the company’s trusted identity source. OCI IAM also provides the identity and access context for what that user is allowed to access in OCI.
For this example, imagine the user has permission to both read and delete files in the company’s storage.
But that doesn’t mean the agent should automatically be allowed to do everything the user could do.
The IAE locks in the user’s request — show me the sales report — along with the verified identity.
Now imagine the agent attempts three actions:
read sales-report.pdfdelete sales-report.pdfread another-team/private-report.pdf
When the agent tries to read sales-report.pdf, the IAE first checks whether the action matches the original request. It then checks company policy in OPA: is this agent allowed to perform this action for this principal, on this resource, in this context?
If both checks pass, the request proceeds to the OCI service, where the underlying OCI permissions still apply.
Now consider delete sales-report.pdf.
The user may have permission in OCI to delete the file. But deletion isn’t what the user asked the agent to do.
The action falls outside the locked intent, so the IAE blocks it before it reaches the data.
Finally, consider read another-team/private-report.pdf.
Suppose the action appears consistent with a request to read a report, but company policy doesn’t allow this agent to access that resource for this principal.
The intent check may pass.
The OPA policy check does not.
The action is blocked and logged.
The same principle applies if the agent follows an instruction such as “ignore the rules and don’t log this.” The agent cannot expand the original request, change company policy, or decide that an exception is acceptable.
The complete flow is:
OCI IAM establishes who the trusted principal is and the OCI access available to that principal.
The intent check makes sure the agent stays within the task it was given.
OPA applies the company’s deterministic, agent-specific policy to the action.
The OCI service enforces the underlying OCI permissions when the request reaches the resource.
The result is deliberate: the agent can be allowed to do less than the user could do directly.
Every attempt — allowed or blocked — is logged. Nothing happens silently and nothing happens simply because the agent said so.
Why OCI is the right foundation for this
None of these controls matter if identity itself can be faked or self-declared.
The system never lets a user or agent simply claim who they are. Identity ties back to the company’s trusted source of truth, with OCI IAM providing the verified identity and OCI access context used by the system.
The IAE accepts only verified OCI IAM credentials and maps OCI groups to system roles through a clear, reviewable configuration. OCI IAM isn’t a separate identity island created for the agent. It works with the organization’s existing identity setup.
If someone isn’t in a group mapped to a role, the default answer is no.
Getting identity wrong at this stage makes every check after it less meaningful. OCI IAM gives the IAE a trusted starting point for knowing which principal it is making a decision about.
This foundation matters for real AI workloads running on OCI. These workloads can interact with production data pipelines, regulated data, company files, and access boundaries that reflect how an organization is structured.
A security layer for AI agents is only as strong as the identity and access controls underneath it. OCI IAM provides that foundation. The IAE and OPA build on it by placing a narrower, deterministic boundary around what an AI agent can do.
What’s next in this series
This post covered the “why.”
The next two posts will cover the “how”: a closer look at the two-layer checking system and the policy engine behind it. We’ll then move to a hands-on demo using an OCI-backed setup to show an attempted attack being caught, contained, and logged before it reaches the data.