Rule security mode

Use the pyRuleExecutionMessagesLogged activity to generate warning messages that the system writes to the PegaRULES log when privileges are missing for user roles.

Before changing the Rule Security Mode, allocate sufficient time and resources to perform a system-wide test that includes all expected users.

The default setting is Allow, which permits rules to run without explicit privileges, unless the rule specifies privilege requirements.

To enforce strict privilege checking in production applications that handle sensitive data, set the mode to Deny. Do not switch directly from Allow to Deny in production. Instead, use Warn mode as an intermediate step. Warn mode logs security violations without blocking rule runs, helping you to identify necessary privilege assignments before enforcing restrictions.

Key behavior

When Deny or Warn mode is active, the system performs the following checks:

• Checks for an explicit privilege on the rule.
• If missing, checks for an auto-generated privilege.
• If neither exists:
  • Deny mode blocks the run.
  • Warn mode logs the violation.

Use the PegaRULES log as your primary diagnostic tool when implementing and troubleshooting Rule Security Mode.

Monitor for the SECU0007 message, which appears when a rule cannot be run because Rule Security Mode is set to Warn or Deny and the rule was not implicitly allowed. The log entry includes:

• The blocked rule
• The user who attempted access
• The context of the access attempt
• The complete stack trace showing the rule execution chain

When you encounter a SECU0007 message:

• Analyze the full context before deciding on remediation.
• Determine whether the blocked access represents legitimate business functionality or unauthorized access.
• Review message frequency:
  • A single occurrence might be a test-related issue.
  • Repeated occurrences indicate a genuine business need.

Configure log monitoring to aggregate SECU0007 messages and identify patterns. You might discover:

• Rules frequently blocked across multiple users, indicating gaps in privilege assignment.
• Specific users attempting to access rules outside their job responsibilities, which may signal insufficient role definition or potential security concerns.

Use a structured approach to minimize business disruption while resolving security issues.

If users report that they cannot complete work after security mode changes:

1. Review the PegaRULES log for SECU0007 messages associated with the user's Operator ID at the time of the issue.
2. If the access is legitimate:
   • For immediate relief, temporarily switch the affected Access Group to Warn mode.
   • For a permanent fix, create the necessary privilege and assign it to the appropriate role through an Access Role Object (ARO) rule.

Always follow your organization's change management procedures when assigning privileges in production. These changes directly affect your application's security posture.

Avoid the following pitfalls:

• Granting overly broad privileges that compromise security
• Assigning privileges to individual Operator IDs instead of roles
• Failing to document the business justification for privilege assignments, which creates compliance risks during audits

Start with Warn mode during development to identify missing privileges. Then switch to Deny mode for production environments that require strict compliance. Always review logs and validate privileges before changing modes.

Check your knowledge with the following interaction: