If you’ve deployed Onyx as your enterprise AI platform, you’ve centralized something powerful: assistants, connectors to your data, LLM routing, agentic actions, and — increasingly — MCP tool integrations, all in one place. That concentration is exactly why it deserves deliberate governance. Onyx becomes a single, high-value pathway between your organization’s data and the models and tools that consume it.

The mistake I see most often is trying to jump straight to sophisticated controls before the fundamentals are in place. Governance maturity is cumulative: you earn the right to advanced detection and automation only after identity, least privilege, and permission integrity are solid.

So here’s how I structure it — a three-tier maturity model, each tier covering the four things Onyx governs: AI assistants (your “copilot”), agentic AI, SaaS connectors, and MCP.

The control surface these policies map to

Every policy below maps to something you actually configure in Onyx: RBAC and SSO/OIDC, connectors and permission sync, LLM provider routing (external vs self-hosted), assistants/personas (their tools and document-set scope), actions/tools including MCP servers, token rate limits, and query/chat logging. Some are Enterprise-Edition features — validate against your deployed version.

The three tiers

  • Tier 1 — Foundational: get identity, least privilege, permission integrity, and logging right. Prevent worst-case data egress before anything else.
  • Tier 2 — Managed: approval workflows, per-object policy, DLP-style guardrails, and a review cadence. Governance becomes deliberate.
  • Tier 3 — Optimized: detection, automated response, red-teaming, and metrics. Policy adapts to risk and evidence is continuous.

Use the tabs to focus on a single tier, or view the full matrix.

DomainTier 1FoundationalTier 2ManagedTier 3Optimized
Copilot / Assistants
  • Enforce SSO/OIDC for all access; assign RBAC (Admin / Curator / Basic) on a least-privilege basis.
  • Default to an approved LLM provider; if no enterprise-approved external model exists, route to a self-hosted model so documents and queries do not egress.
  • Enable query and chat logging; retain per records policy.
  • Every assistant has a named owner, a defined document-set scope, and a reviewed system prompt.
  • Apply input/output guardrails: PII redaction, sensitive-data filtering, prompt-injection protection.
  • Set token rate limits per user/group to bound abuse and cost.
  • Behavioural/anomaly monitoring on queries and responses (data-leakage patterns, anomalous access) with alerting into SIEM / insider risk.
  • Track metrics/KRIs (sensitive-data hits, blocked events, assistant sprawl).
  • Run periodic red-team testing for oversharing and prompt injection.
Agentic AI
  • Disable agents and tool use by default; enable only for named owners.
  • No code execution, web browsing, or external tool calls unless explicitly turned on.
  • Restrict assistant creation and sharing to Curators and above.
  • Least-privilege tool access — each agent’s enabled actions are explicitly listed and approved.
  • Autonomous or high-impact actions require human-in-the-loop approval.
  • Agents run against scoped document sets, not the full corpus.
  • Automated response to anomalous agent behaviour (quarantine / disable).
  • Continuous tool-chain validation and drift detection on prompts and actions.
  • Full lifecycle governance — agents reviewed, re-certified, and retired on a schedule.
SaaS
  • Connectors added only by Admins/Curators; maintain an inventory of connected SaaS sources.
  • Require permission-syncing connectors for any private source; ban public connectors against sensitive data.
  • Store connector credentials in the approved secret store.
  • Connector approval workflow — new connectors are reviewed before sync.
  • Verify permission sync honours source ACLs (access is mapped, not flattened).
  • Identify unsanctioned/shadow GenAI SaaS and steer users to sanctioned Onyx assistants; run periodic access reviews.
  • Continuous DLP/egress monitoring across connectors; automated de-sanctioning of risky sources.
  • Re-assess connector/third-party risk on a cadence; feed findings to the risk register.
MCP
  • No MCP servers or tools enabled by default; unregistered MCP integrations are prohibited.
  • Require Admin registration for any MCP server; document each server and its owner.
  • Maintain an allow-list of approved MCP servers/tools, each scoped to least-privilege capabilities with documented data egress.
  • Rotate and least-privilege MCP credentials.
  • Tools that can reach private data or take external action require explicit approval.
  • Continuous monitoring of MCP tool invocations with anomaly detection and a kill-switch.
  • New MCP servers pass a security review gate (scopes, egress, provider) before allow-listing.
  • Integrate MCP telemetry with the SOC.

Tier 1 is a prerequisite for Tier 2, and Tier 2 for Tier 3 — maturity is cumulative. Validate Onyx feature names / Enterprise-Edition gating against your deployment.

Why cumulative maturity matters

It’s tempting to buy the anomaly detection and skip the permission hygiene. Don’t. If your connectors flatten source permissions or your agents run against the full corpus, no amount of Tier 3 monitoring saves you — you’re just watching a breach happen in high resolution. Tier 1 is the foundation the rest stands on; Tier 2 makes governance intentional; Tier 3 makes it continuous.

This maps cleanly onto The AI-Native Security Framework — Tier 1 aligns to Discover/Reduce, Tier 2 to Constrain/Govern, and Tier 3 to Instrument/Assure — and onto ISO 27001/42001 and the NIST AI RMF the same way.

Not to be confused with Onyx Security

A March 2026 startup called Onyx Security shares the name but is a different company and a different product — an outside-the-tenant agent discovery and runtime-supervision layer. I compare it against Microsoft Agent 365 in Two “AI Control Planes”, Six Surfaces.

Take the policy set

I’ve packaged the full three-tier set as a free, editable template you can drop into your ISMS and adapt to your Onyx deployment — see Resources. And if you want help operationalizing agentic-AI governance in Onyx, let’s talk.