The agent as an untrusted client: OPA before every tool call

When an agent works across several systems, the security team needs to know why it would receive a shared key to all of them. Model instructions do not answer that question. An instruction not to modify HR data remains a request rather than an enforceable permission.

The permissions therefore live outside the agent, in a policy engine that decides before every tool call. This applies a familiar service-to-service authorization pattern and treats the agent as an untrusted client.

What it looks like in practice

In the policy layer we built, an action request carries identity, organizational unit, data class, action type, reversibility, and the required number of approvals. Before any tool is invoked, a separate OPA policy service returns one of three answers: permit, deny, or require a second human approval. Each decision includes its reason and policy version.

The controlled case uses fictional systems and generated data. The measurements below cover local adapters; a client's environment requires its own checks.

The rules are code in Rego: readable, testable, and versioned outside the agent's application. A policy change touches no agent code, and policy tests run in CI like any others.

A denial that leaves nothing to act with

The architecture's most important detail happens after a denial. The system does not hand the agent a message saying forbidden and hope it obeys. After a denial, the target system's credential is never issued. The forbidden action has nothing to execute with, regardless of what the model thinks about its task.

Each of the three target systems also has a separate tool identity and a different authentication mechanism. The agent carries no shared key: it receives, one action at a time, exactly the credential the policy granted. Irreversible actions and sensitive data classes require a human's second signature.

An audit that answers the auditor's question

Every decision goes into an append-only log: who, which tool, in which system, what decision, for which reason, under which policy version. An auditor can answer why a past action passed from that record, without reconstructing it from model logs. An integrity check detects log tampering.

Begin with an action catalog

A policy layer needs precise inputs. For every tool, define the target system, action, data class, organizational unit, reversibility, and business effect. A general permission such as “CRM access” is too broad. Reading contact details, changing an opportunity owner, and deleting a record should be separate actions.

The next artifact is a matrix: who may perform each action, on which data, in what context, and with how many approvals. The policy needs a safe default for new actions and an explicit response when the decision point is unavailable.

A staged rollout

1. Inventory tools, credentials, and actions currently performed by people.
2. Classify actions by risk, reversibility, and data class.
3. Build a decision matrix with denial and second-approval cases.
4. Place enforcement before the credential broker and target system.
5. Test policies in CI across the full matrix and regression cases.
6. Run in observation mode and compare proposed decisions with operator choices.
7. Enforce read-only actions first, followed by reversible writes.

This sequence exposes broad rules and missing context before automation can modify production data.

Failure modes

Policy cannot protect a target if the agent holds a permanent credential that bypasses enforcement. Incomplete context is another risk: a wrong data class or organizational unit produces a valid decision for invalid inputs. Attributes should come from trusted systems, and their provenance belongs in the audit record.

Plan for outages of OPA, the credential broker, and target services. Sensitive operations should fail safely into a human queue. Approval should also expire and bind to one action, preventing an old decision from authorizing a later request in a changed context.

The measurement

The full policy matrix produced the expected decision for all 640 identity, action, and data-class combinations. Across 647 evaluated requests, unauthorized executions remained at zero, and the prepared audit-tampering attempt was detected. The local policy service had a 95th-percentile response time of 19.021 ms. A separate small-model action request using gpt-5-mini cost about PLN 0.0032; OPA still made the binding decision.

These figures cover a closed matrix of fictional systems. They do not establish the completeness of a client's policies or latency across its integrations. A pilot should track permit, deny, and escalation rates; false denials; second-approval time; expired approvals; and actions for which no rule exists.

Architecture checklist

• The agent stores no permanent target-system credentials.
• Every action has a type, data class, and reversibility flag.
• Unknown actions deny or route to review.
• Policy decides before a short-lived credential is issued.
• Approval binds to one action and expires.
• Audit records context, attribute sources, and policy version.
• Tests cover permits, denials, escalations, and dependency failures.
• Operators have a queue of held cases with readable reasons.

If an agent at your company is meant to touch the ERP, CRM, or DMS, and security stops the project at the key question, start with the case page or a free process scan: we show a live policy denial with the rule quoted.