Decide what AI may do in your systems, team by team

An MCP Policy decides which tools each person’s AI client may use, by directory group and by risk level. A blocked tool is hidden from the AI client, and a call that reaches Oriant anyway is refused and recorded.

Different rules for different teams

MCP Policies attach to the directory groups from your identity provider (SCIM), so adding someone to a group gives them its policies with no work in Oriant. Policies sit in one order that you set, and the first policy that says anything about a tool decides it. The Default policy sits at the bottom and applies to every member, including people in no directory group. Until an admin chooses a default, it is Everything. Policies are decided per member, so two people in the same team can get different tools if one of them is also in a group with an earlier policy.

Read-only access for AI agents

Every policy sets a level per connection: Read only, Read and write, Everything or Off. With Read only, an AI client can read an issue in Linear but cannot create, change or delete anything. Oriant ships Read only, Read and write and Everything as presets. Presets cannot be edited, so you duplicate one and name the copy after the team. The same policy can give a different level on another connection, such as Slack. Read only is the answer for a team that may look things up and must not change anything.

Read, write and destructive tool labels

Levels use the labels the MCP server gives its own tools: Read, Write or Destructive. Oriant never labels a tool itself. One rule blocks every destructive tool on a connection, including tools the server adds later. A tool with no label is allowed only under Everything. Because the labels come from the server, a policy that allows Read and Write keeps every Destructive tool out of reach without a list of tool names that you have to maintain.

Tool exceptions and argument rules

A tool exception sets Allow or Block on one named tool and beats the policy’s levels, Off included. A team on Read only can still get save_comment this way. An argument rule limits the values one tool may be called with on one connection, such as one Linear team or one Slack channel. Oriant adds each rule to the tool’s description, checks the call before forwarding it, and refuses a call that breaks the rule. Rules check what a call asks for, not what the server returns.

What happens to a blocked call

Oriant hides tools a member may not use, so their AI client never lists them. If a call reaches Oriant anyway, it is refused and recorded with the policy that decided it, and it is never sent to the MCP server. A member whose directory account is deactivated gets no tools on any connection. No Role bypasses MCP Policies: Owners and Admins are governed like everyone else, and their Permissions decide only who may edit policies.

Check what a member gets with View as

View as shows exactly which tools one member gets on each connection, tool by tool. Use it after you change a policy or reorder the list, and before you tell a team that the new rules apply. A policy change reaches connected AI clients as a changed tool list.

Sanction states for AI Providers

Each AI tool the agent finds on your machines has one sanction state. Unsanctioned is the default, and its use is recorded and counted. Sanctioned means you trust the tool and nothing else happens. Blocked means the agent rejects connections to it on every machine, so it works on any network. Sanctioning a tool grants nothing on your MCP Connections, because MCP Policies decide that separately. Blocking runs through the endpoint agent, and a call to an MCP server that does not go through an Oriant connection is not covered by MCP Policies. The agent shows that connection instead.

Read the docs

More of Oriant

What can your AI reach today?

Oriant lists the AI clients, MCP servers, API keys and Skills on your machines, and it governs what AI does in your systems.