version: "1.0.1" name: mcp-engine-security-governance description: 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.

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 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 — 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. Prefer deny rules over require_confirm for high-risk operations; require_confirm is best-effort UX, not a portable control.
• Masking: pii-masking-guide for sensitive-value redaction and masking behavior.
• Audit: audit-logging-guide 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.