# MCP Engine Security Governance

> Use when creating or changing RLS roles, role filters, OLS permissions, perspectives, allow/deny/confirm policy rules, PII or numeric masking, or audit logging and evidence export, and when deciding whether a request needs security enforcement or only curation. For first-time guided setup of policies, masking, and guardrails, use mcp-engine-onboarding.

- Skill: `maxanatsko/mcp-engine-security-governance` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add maxanatsko/mcp-engine-security-governance`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maxanatsko/mcp-engine-security-governance/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: maxanatsko (https://skillmd.com/u/maxanatsko)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/maxanatsko/mcp-engine-security-governance

---


# PBI Security Governance

Security enforcement and governance through `manage_security`, `manage_policy`, and `manage_audit`. Keep curation separate from access control.

## Start with the right category

- Perspectives (`create_perspective`, `update_perspective`) are curation — they change what users see, not what they can access.
- Roles, OLS, policies, masking, and audit are enforcement — fail closed by default unless the user explicitly changes that posture.
- Confirm the current model with `manage_model_connection` `{ "operation": "get_current" }` and state the intended scope before modifying anything security-sensitive.

## Branch by workflow

- RLS and OLS: `manage_security` (`create_role`, `set_role_filters`, `set_role_permissions`) — read [security-roles-guide](references/security-roles-guide.md) first. For RLS, validate each affected role with `run_query` `{ "operation": "test_access", "query": "<small aggregate over the filtered data>", "spec": { "roles": ["<role>"] } }` (both `query` and `spec.roles` are required). For OLS, exercise every changed table or column directly under the affected principals and verify each expected allow or denial; use targeted `test_access` queries or a `manage_tests` `ols_validation` matrix. An unrelated aggregate is not OLS evidence.
- Perspectives: [perspectives-guide](references/perspectives-guide.md) — when the user wants curated field visibility, not restricted access.
- Policy rules and packs: `manage_policy` (`status`, `evaluate`, `put`, `packs_apply` with `dry_run: true` first) — [policy-guide](references/policy-guide.md). Prefer deny rules over `require_confirm` for high-risk operations; `require_confirm` is best-effort UX, not a portable control.
- Masking: [pii-masking-guide](references/pii-masking-guide.md) for sensitive-value redaction and masking behavior.
- Audit: [audit-logging-guide](references/audit-logging-guide.md) for durable trails, export verification, and integrity checks. Treat auditability as part of correctness for write and governance flows.

## Guardrails

- Confirm intent with the user before destructive or broad security changes.
- Never present a perspective as protection; say explicitly when a request needs RLS or OLS instead.
- Do not echo sensitive values, filter expressions over PII, or masked data in summaries, examples, or logs.

## Report results

After security or governance work, report:

1. Roles, permissions, policies, or masking rules created or changed.
2. `test_access` or `ols_validation` results for each affected role, principal, and protected object.
3. Policy evaluation or dry-run outcomes before application.
4. The enforcement posture after the change — what is now denied, confirmed, masked, or audited.