Design an action-guardrail layer (policy engine) for agents that operate on business systems.

30-second answerSay your answer out loud first, then reveal.

Put a policy enforcement point between the agent and every tool. Each tool call is checked against declarative policies: who is acting (user identity and role), what action on which resource, with what parameters, in what context (risk score, data sensitivity, time, rate). The outcome is allow, deny, require approval, or modify (e.g. cap the amount). Policies live in a policy engine (e.g. OPA/Rego or Cedar-style), are versioned and tested, and every decision is logged for audit.

An agent's proposed tool call goes to a policy enforcement point, which logs to an audit log and asks a policy decision point that uses session identity and context; the decision is allow, deny with a reason, require approval, or modify parameters.

Policy examples

text

- refund.create: allow if amount ≤ 2,000 AND order.owner == session.user
                 require_approval if 2,000 < amount ≤ 20,000; deny otherwise
- email.send:    allow if all recipients in company domain; else require_approval
- records.delete: deny for agents (soft-archive only via archive tool)
- any tool:      deny if session.risk_score > threshold; rate-limit 20 calls/min/user

Design considerations

Identity from the session, not the model: the agent cannot claim to be another user.
Deterministic and testable: unit tests for policies; policy changes go through review.
Explainable denials returned to the agent so it can adjust or inform the user.
Performance: in-process or sidecar policy evaluation (milliseconds).
Defaults: deny by default for new tools until policies are written.

PreviousHow do you evaluate quality for multilingual and Indic-language users?

You understood something today that you didn't yesterday.

Design an action-guardrail layer (policy engine) for agents that operate on business systems.

Policy examples

Design considerations

Related