OPA for AI agents: decide before a tool call

An instruction inside a model prompt can describe a permission. It cannot enforce one when the application already holds a broad credential. A safer arrangement gives the agent a narrow request interface and asks a policy service for a decision before the tool adapter runs.

What OPA contributes

Open Policy Agent is an open-source, general-purpose policy engine. It separates the policy decision from the service that enforces it. A caller sends structured input, policies written in Rego evaluate that input, and OPA returns a decision that the application can interpret.

OPA does not issue a CRM key or change an ERP record. The application, gateway, or credential broker still has to enforce the result. That separation is useful because the security team can review policy code while the product team owns the agent workflow.

Define the request before writing rules

Create an action catalogue first. Each entry should state:

• actor identity and organisation;
• target system, resource, and record scope;
• requested action and reversibility;
• data classification;
• reason and source of the request;
• required approval and its expiry;
• credential or service identity used after approval.

For example, crm.ticket.update_status can carry a ticket identifier and an allowed status transition. A request that asks for an arbitrary database query has a much larger review surface. Specific actions make both policy and monitoring clearer.

Put the decision before the credential

A practical request path is:

1. The agent proposes an action in a typed tool format.
2. The application validates the shape and resolves the current user and tenant.
3. The policy input is sent to OPA.
4. OPA returns allow, deny, or approval_required, with a reason and policy version.
5. The application obtains a short-lived service credential only for an allowed action.
6. The adapter validates the target again and records the result.

The action adapter should fail closed when OPA is unavailable, the policy version is unknown, the request is missing a required field, or the approval has expired. A denial should return a useful reason to the operator while withholding the target-system credential.

Keep human approval meaningful

Approval should cover a specific action, resource, and time window. Display the data the reviewer needs, preserve the approving identity, and prevent the agent from silently changing the request after approval. For bulk changes, show the affected set and offer a reversible operation where the target system supports one.

Avoid asking a person to approve every low-risk read. Reserve review for irreversible changes, external messages, sensitive data access, and actions outside the normal process. The policy catalogue should make that choice visible to security and process owners.

Logging and operations

A useful decision record includes request identifier, actor, tenant, action, resource, input classification, policy version, result, approval reference, credential scope, adapter result, and timestamp. Protect logs against alteration and restrict their content to what the incident and audit process needs.

Treat policy as production code. Review changes, test representative allowed and denied cases, check policy coverage when a tool changes, and keep a rollback version. Monitor denials, approval volume, policy errors, adapter errors, and requests that repeatedly fail validation. Those signals show whether the workflow is usable and whether an integration is trying to exceed its contract.

Acceptance checklist

• Does every tool map to a named action in the catalogue?
• Does the request identify actor, tenant, target, data class, and reversibility?
• Can the application enforce a denial before it obtains a target credential?
• Does an approval expire and bind to the original request?
• What happens when OPA is unavailable or returns malformed output?
• Can an operator explain a decision from the recorded inputs and policy version?
• Are policy changes reviewed and tested in a separate environment?
• Can a tool be disabled without changing the model prompt?

OPA is a strong fit when several applications need consistent policy decisions and the team can maintain a policy lifecycle. A small workflow with one well-scoped tool may need a simpler application check first. Compare the action catalogue, approval rules, and audit requirements in an AI process scan before choosing the policy layer.