BUILDING A BULLETPROOF GRC PROGRAM — Part 7 of 8: Centralized Rule Management with OPA & AI/MCP…

The Enforcement Problem

Parts 3–6 defined policies, baselines, and controls in ServiceNow. But a policy document does not stop a developer from pasting customer data into ChatGPT at 2 AM. A control registered as "Effective" in ServiceNow does not technically prevent an AI agent from deleting a production database.

You need an enforcement engine that sits between your users/agents and AI services — evaluating every request against your rules in real-time.

That engine is OPA (Open Policy Agent), deployed within AI and MCP Gateways.

• ServiceNow = WHAT (defines rules in business language, manages lifecycle)

• OPA = HOW (enforces rules as code, makes real-time allow/deny decisions)

• Gateway = WHERE (the network point that intercepts requests and queries OPA)

Architecture: The Full Stack

• Layer 1: ServiceNow (Policy Authority)

• Defines rules in business language. Manages approval workflows. Tracks ownership and audit trail. Publishes rule changes to OPA.

• Layer 2: OPA (Policy Decision Point)

• Loads policy bundles from ServiceNow/bundle server. Evaluates every request against Rego policies in under 1 millisecond. Returns allow or deny with reasons. Logs every decision.

• Layer 3: AI Gateway (LLM Enforcement Point)

• Sits between developers and AI services. Intercepts all LLM requests. Queries OPA before forwarding. Inspects payloads for PII/secrets. Meters costs and tokens.

• Layer 4: MCP Gateway (Tool Enforcement Point)

• Sits between agents and MCP tools. Controls which tools each team/agent can access. Blocks destructive operations. Enforces data access limits.

• The flow: Developer or agent makes request → Gateway intercepts → Gateway asks OPA "is this allowed?" → OPA evaluates rules → Returns allow/deny → Gateway either forwards or blocks

Why Opa Specifically

• Decoupled from application code:

• Rules change without redeploying your gateway. Update a policy in ServiceNow, it propagates to OPA within 30 seconds. No code release needed.

• Sub-millisecond decisions:

• OPA evaluates policies entirely in memory. Adding it to the request path does not meaningfully increase latency.

• Unified policy language:

• The same Rego language and engine works for AI gateway rules, Kubernetes admission control, API gateway authorization, CI/CD decisions, and infrastructure policies. One skill, many enforcement points.

• Built-in decision logging:

• Every single evaluation is captured — who requested what, which rules applied, what the decision was, and why. This is your compliance evidence, generated automatically.

• Data-driven policies:

• Rego policies reference external data (team permissions, approved services, rate limits). You change behavior by updating the data file — not by editing policy logic. When the GRC team approves a new AI service, a data file updates. No engineering work.

• Battle-tested at scale:

• OPA is used at Netflix, Goldman Sachs, Pinterest, Atlassian, and hundreds of other companies for exactly this pattern: centralized policy enforcement across distributed systems.

Rule Categories Managed In Servicenow

All rules are defined, versioned, and approved in ServiceNow. They fall into four categories:

Category 1: Data Protection Rules

• AI-DPR-01: No production credentials in AI prompts

• Enforcement: Block the request immediately. Alert the security team.

• Detection: Regex patterns for AWS keys, API tokens, connection strings, private keys.

• AI-DPR-02: No customer PII sent to external AI models

• Enforcement: Detect PII (email, phone, SSN, credit card numbers), redact before forwarding OR block entirely.

• Detection: Pattern matching for known PII formats.

• AI-DPR-03: Source code from restricted repositories cannot reach external AI

• Enforcement: Block the request. Repository tags in CMDB determine which repos are restricted.

• Detection: Request metadata includes repo context.

• AI-DPR-04: Database query results limited to 100 rows in AI context

• Enforcement: Truncate payload if results exceed limit.

• Detection: Response size inspection on MCP database tool responses.

• AI-DPR-05: Internal architecture diagrams and design documents blocked from external prompts

• Enforcement: Block and notify the user with explanation.

• Detection: Content classification of attached files and context.

Category 2: Access And Authorization Rules

• AI-ACR-01: Only approved AI models accessible (allowlist)

• Enforcement: Block calls to any model/endpoint not on the approved list.

• Allowlist maintained in data file synced from ServiceNow.

• AI-ACR-02: Agents cannot access production systems without human approval

• Enforcement: Queue the request for human approval. Hold execution until approved.

• AI-ACR-03: AI tool access scoped to user's existing RBAC permissions

• Enforcement: Passthrough user's identity and permissions. Agent cannot exceed what the user could do manually.

• AI-ACR-04: MCP tools restricted by team and role

• Enforcement: Each team has a defined allowlist of MCP tools. Calls to tools not on their list are blocked.

• AI-ACR-05: Rate limits per user and team

• Enforcement: Throttle requests after threshold. Different limits for different teams/roles.

Category 3: Agent Behavior Rules

• AI-ABR-01: No destructive operations without human confirmation

• Enforcement: Intercept delete, drop, destroy, remove operations. Hold for explicit human approval.

• AI-ABR-02: No external network calls to unapproved endpoints

• Enforcement: Block outbound requests from agents to any endpoint not on the approved list.

• AI-ABR-03: Agent execution limited to N steps

• Enforcement: Terminate agent execution after reaching the step limit. Prevents runaway loops.

• AI-ABR-04: Cannot modify security controls or IAM policies

• Enforcement: Block any operation that would change security groups, IAM roles, branch protection, or firewall rules. Alert security team.

• AI-ABR-05: All tool invocations must be logged with full input and output

• Enforcement: Enforce logging at the gateway level. If logging fails, block the request.

Category 4: Content And Output Rules

• AI-COR-01: AI output must not contain hardcoded secrets

• Enforcement: Scan AI response before delivering to user. Redact if secrets detected.

• AI-COR-02: AI-generated infrastructure code must pass security scan before apply

• Enforcement: Hold IaC output for automated Checkov/tfsec scan. Only deliver if clean.

• AI-COR-03: AI cannot generate code that disables security controls

• Enforcement: Pattern detection for code that removes security headers, disables authentication, opens permissive firewall rules. Block and flag.

• AI-COR-04: SQL in AI responses must use parameterized queries

• Enforcement: Scan SQL patterns in responses. Flag or block if raw string concatenation detected.

Opa Rego Policy Examples

Here is what enforcement looks like in Rego (OPA's policy language):

• AI Gateway authorization policy:

• Default: deny all requests (fail-closed)

• Allow only if: user is authenticated AND target is an approved service AND prompt contains no PII AND request is within rate limit AND prompt contains no secrets

• If denied: return specific reason (which rule triggered, what was detected)

• MCP tool access control:

• Allow tool call only if: tool is in the team's allowed list AND tool is NOT in the team's blocked list AND the operation is not destructive

• Destructive operations: DROP, DELETE, TRUNCATE (database); delete_repo, force_push (GitHub); delete_namespace (Kubernetes)

• Agent behavior guardrails:

• Allow action only if: not a destructive operation OR human has explicitly approved AND current step count is within limit AND target environment is in the agent's allowed scope

• Require human approval for: any production environment action, any action in the high-risk operations list

The key insight: the policy LOGIC lives in Rego, but the DATA (approved services, team permissions, rate limits, PII patterns) comes from a JSON file synced from ServiceNow. When the GRC team approves a new AI service or changes a team's permissions, only the data file updates. The policy code never changes.

Mcp Gateway: Tool-Level Governance

For MCP (Model Context Protocol) tools, the gateway manages granular access:

• aws-docs-mcp:

• Allowed for: All teams

• Restrictions: None (read-only, accesses only public documentation)

• database-mcp:

• Allowed for: Backend engineering team only

• Restrictions: No DROP, DELETE, TRUNCATE, or ALTER operations. Query results capped at 100 rows. PII columns are automatically masked in results. Production database: read-only access only, and requires explicit approval for each session.

• kubernetes-mcp:

• Allowed for: Platform team only

• Restrictions: No modifications to production namespace. Scale operations require human approval. Secret values are never exposed — only secret names are visible.

• github-mcp:

• Allowed for: All engineering teams

• Restrictions: Cannot modify branch protection rules. Cannot delete repositories. Cannot disable required status checks. Force push is blocked.

Each restriction is implemented as a Rego rule evaluated by OPA on every tool invocation.

Ai Gateway: Request Flow

Every AI request passes through this seven-step evaluation:

Step 1: Authenticate

• Identify the caller. Which user or service account? What team? What role? Is authentication valid?

Step 2: Identify Applicable Rules

• Based on caller identity + target AI service + asset context, determine which rules from the policy bundle apply to this specific request.

Step 3: Inspect Payload

• Scan the prompt content for PII patterns, credential patterns, restricted data markers. This happens before the request leaves your network.

Step 4: Evaluate (Opa Query)

• Send request context to OPA. OPA evaluates all applicable rules. Returns allow or deny with specific rule ID and reason.

Step 5: Forward Or Block

• If all rules pass → forward request to the AI service

• If any rule fails → return error to the caller with the specific reason and the rule that triggered

• If rule says "modify" → apply modification (redact PII, truncate) and then forward

Step 6: Inspect Response

• When the AI service responds, scan the output against content rules. Redact any secrets detected. Flag unsafe code patterns.

Step 7: Log Everything

• Full audit record: timestamp, user, team, target service, rules evaluated, decision, reason, response metadata. Sent to ServiceNow as compliance evidence.

Servicenow To Opa Sync

Rules defined in ServiceNow must reach OPA for enforcement. The recommended approach is hybrid:

• On startup: OPA pulls the full rule set from a bundle server (S3 bucket or HTTP endpoint containing Rego files + data.json)

• On rule change: ServiceNow fires a webhook when a rule approval workflow completes. This triggers a build pipeline that packages new Rego bundle and publishes to the bundle server. OPA picks it up within 30 seconds.

• Safety net: OPA polls the bundle server every 30 seconds regardless, catching anything the webhook might have missed.

• Result: A rule approved in ServiceNow is enforced across all gateways within 30 seconds. No deployment. No restart. No human intervention beyond the initial approval.

Policy Translation: Business Language To Rego

The GRC team never touches Rego. They work in ServiceNow:

• TEMPLATE-BASED (for common rule patterns):

• GRC analyst fills out a form in ServiceNow:

• Rule ID: AI-DPR-02

• Type: Block Data Pattern

• Patterns: email, SSN, credit card number

• Scope: All teams

• Target: External AI services only

• Action: Block request

• System auto-generates the corresponding Rego rule and data configuration. No engineering involvement for standard patterns.

• CUSTOM (for complex logic):

• Security engineering writes Rego for rules that cannot be templated.

• Stored in a version-controlled Git repository.

• Referenced from the ServiceNow policy record (linked to the Git path).

• Goes through code review like any other code change.

Decision Logging: Closing The Loop

Every OPA evaluation generates a decision log entry containing:

• Timestamp (when the decision was made)

• Decision ID (unique identifier for audit trail)

• Policy path evaluated (which rules were checked)

• Caller identity (user, team, service account)

• Target (which AI service or MCP tool)

• Result (allow or deny)

• Reason (which specific rule triggered, if denied)

• Evaluation time (how long the decision took — typically under 1ms)

This data flows to ServiceNow and becomes:

• Compliance evidence — "Our AI data protection controls are actively enforcing"

• Enforcement metrics — "Rule AI-DPR-02 triggered 312 times this quarter"

• Risk indicators — "PII detection attempts trending up 40% in the payments team — training needed"

• Board metrics — "AI governance controls prevented 312 potential data leaks this quarter, zero incidents"

Key Design Decisions

• Where do rules live?

• ServiceNow is the single source of truth. OPA is the enforcement cache. You get central governance with fast enforcement.

• Inline versus async enforcement?

• Inline (blocking) for data protection and access control rules — these must prevent bad actions.

• Async (logging only) for informational rules — track but don't slow developers.

• Per-user or per-team rules?

• Start with per-team (simpler to manage at scale). Add per-user rules later for sensitive roles (contractors, departing employees).

• What if the gateway goes down?

• Fail-closed for production and sensitive assets (no access without verification).

• Fail-open for development environments (don't block developer productivity for dev-only work).

• Who can modify rules?

• Security team proposes changes → GRC team reviews and approves → Auto-syncs to OPA.

• Same governance workflow as any other control modification. Full audit trail.

⚠ REAL-WORLD: In 2024, a Microsoft AI research team accidentally exposed 38 terabytes of internal data through an overly permissive Azure SAS token generated while publishing AI training data. An OPA policy enforcing "no public access tokens for internal data repositories" would have blocked the token creation at the API level — preventing the exposure before it happened.

The Full Closed Loop

• GRC team defines rule in ServiceNow (business language, approved via workflow)

• ↓

• Translated to Rego (template auto-generation or custom engineering)

• ↓

• Published to OPA bundle server

• ↓

• OPA loads new policy within 30 seconds

• ↓

• Gateway queries OPA on every request

• ↓

• OPA returns allow or deny with reason

• ↓

• Decision logged and sent to ServiceNow

• ↓

• ServiceNow shows: control effective, metrics updated, evidence accumulated

• ↓

• Executive dashboard: "AI governance controls are working"

• ↓

• If patterns emerge (training needed, rules need tuning) → feeds back to policy updates

Key Takeaways

• OPA is the bridge between business-level policies and real-time enforcement. ServiceNow defines intent. OPA makes it technically impossible to violate.

• Rego is policy-as-code. Version-controlled, testable, auditable, and fast. You can unit test your security policies the same way you test application code.

• The GRC team never touches Rego. They define rules in ServiceNow using forms and templates. Engineering handles translation. This separation of concerns is critical for scaling.

• Decision logs automatically close the compliance loop. Every enforcement event is compliance evidence. You do not need to separately "collect evidence" — it generates as a byproduct of enforcement.

• One policy engine serves all enforcement points. AI gateway, MCP gateway, CI/CD pipeline, Kubernetes admission, API gateway — same OPA, same Rego, same governance model. Deploy once, enforce everywhere.

What Comes Next

In Part 8 (the final installment), we cover the observability and security operations layer — how telemetry from your AI systems flows through SIEM/SOAR for threat detection and automated response, and how aggregated business metrics reach ServiceNow for executive dashboards and board reporting.

Previous: Part 6 — AI Governance

Next: Part 8 — Observability, SIEM/SOAR & Executive Metrics