REPEL: Define the policy, then test the controls
REPEL means Rule-based Enterprise Policy Enforcement Lock. It is our approach to setting policy and control requirements around AI workflows. Start with what information may be used, which actions are allowed and where a person must review an exception. The deployment needs to implement and test those requirements.
Security, roles and approvals
Define the data boundary, approved models, user roles and exception reviewers. Pre-prompt checks can be one part of that design, but they can miss sensitive content or new attack patterns. Role-based access control belongs within Security: permissions and approval gates need implementation evidence, not only a written policy.
Eval – test representative cases
Define what is being evaluated and what a passing result means. Use non-sensitive allowed, blocked, redacted and escalated examples. Record the test cases, results and limits so a reviewer can see what was checked. A passed test set is not a guarantee about every future request.
Validation – check the result or action
Input checks do not establish that an output is accurate or safe to share. Define separate checks for business-critical results, permissions and outward actions. Name the reviewer for uncertain or high-risk cases. Evaluation tests the defined cases; validation checks the particular result or action against its acceptance rules.
Observability – define the evidence needed
Decide which run events, decisions, exceptions and approvals need to be visible, who may inspect them and what must be retained. Confirm which evidence the deployment actually records. A logging requirement is not proof that complete records or a monitoring dashboard already exist.
Review one workflow and its limits
Choose one workflow, its data and its required approvals. Test the controls with redacted or non-sensitive examples before relying on them in production. REPEL does not guarantee compliance, safe outputs or successful execution.