Require a minimum operator level

A policy can say that its members’ agents should only use platforms and MCP servers whose operator has been verified to a minimum level, and only the version of each MCP server that an admin approved. For what the levels and approved versions mean, see Operator verification.

Enterprise. This section appears on the Enterprise plan. On other plans the policy editor shows an Enterprise upgrade note in its place.

The requirement applies when an agent calls a platform. It never applies to adding a platform or MCP server, which is never blocked or delayed by verification. Existing policies have no requirement until you set one.

Set the requirement

1. Go to Governance → Policies and open the policy (or create one with + New policy).
2. Find the section Operator verification.
3. Under Minimum level, choose Domain verified or Listed in MCP Registry. No requirement switches it off.
4. Tick Require the approved version of each MCP server to hold or refuse calls to a server whose operator identity or tool definitions changed since an admin approved it. You can use it with or without a minimum level.
5. Under When the requirement is not met, choose what happens:
   • Observe only (record, never block) (the default)
   • Require approval
   • Deny the call
6. Under Not yet checked / not approved yet, choose how a platform with no result counts:
   • Treat as unverified (the default): it is below any minimum level, and a server with no approved version (or whose approved version has no identity to compare yet) fails the approved-version requirement.
   • Allow: it passes until a check gives it a level, or an admin approves a version.
7. Save the policy.

The requirement covers every agent owned by a member the policy is assigned to, on every platform they use.

Observe first

Observe only records, on each call, what would have happened under the requirement, and blocks nothing. It lets you find out how many of your platforms fall below the level before you enforce anything. Check the audit log (or the operator verification report), then switch to Require approval or Deny the call when you are ready.

Not to be confused with Observe Mode, the no-signup trial relay. This is a setting on one policy requirement.

What agents see when you enforce

When a platform is below the minimum level, or a server is not the approved version:

• Require approval. The call is held and an approval is queued with reason approval_required_by_counterparty. It runs if a person approves it, the same as any other held call. The approval screen (mobile and desktop) shows the operator verification result as it was when the call was held, and the minimum level the policy asked for, or that the server changed since it was approved. Approving a held call lets that one call through; it does not approve the new version of the server. When the approved call runs, the requirement is checked again against the server as it is at that moment. If it would now be refused, or held on a result the approver was not shown (for example, a tool changed after the call was held), the call does not run, and the approval records counterparty_changed.
• Deny the call. The call is refused with HTTP 403 and reason denied_by_counterparty_level, or denied_by_counterparty_pin for the approved-version requirement. The 403 body includes pin_state and, for a tool change, changed_tools.

When only tools changed, the approved-version requirement applies to the changed and new tools alone: calls to unchanged tools carry on. When the operator identity changed, it applies to every tool. If both a minimum level and the approved version are required and both fail, the level is reported.

The requirement is checked after the grant, endpoint and constraint checks, and before the policy’s own approval rules. So an enforcing Deny cannot be turned into an approvable hold by an approval rule elsewhere in the policy.

First use waits up to 6 seconds

The first time an agent uses a platform under an enforcing requirement, there may be no result yet. AgentValet waits up to 6 seconds for the first check to finish before deciding. If it still has no result, the Not yet checked / check unavailable setting decides.

That setting covers a server with no check result. It does not cover AgentValet failing to read its own records: if the verification status, or the policy’s requirement, cannot be read when a call is made, an enforcing requirement holds or refuses the call as its mode says (a requirement that cannot be read at all refuses it, with reason counterparty_check_unavailable). Nothing changes for organisations without operator verification.

An approval taken before the server’s first check or first tool listing is not bound to anything yet, so under the approved-version requirement it is held or refused until the first check or listing binds it. The Not yet checked setting does not apply to it.

Agents can see the level before they call

list_platforms gives each platform a read-only counterparty object: state, level, host, checkedAt, pinState, changedTools (only when some changed), operatorIdentityPublished, and sources (each with source and status). It is part of the list’s version hash, so a change in level shows up as a new permissions version.

It does not say whether a call will be held or refused. Neither does the policy preview. That is decided at call time.

What the audit log records

With operator verification on, every governed call in your organisation carries a counterparty object in its audit metadata:

When the agent’s policy has a requirement, it also carries:

The signed governance receipt for the call carries decision.counterparty: state, level, pin_state, identity_sha256, manifest_sha256, pin_id and outcome.

An approval request keeps the snapshot taken when the call was held, so an approver sees what the request was based on, even if the level has changed since.

Next

• Operator verification
• Operator verification report and badges
• Manage user policies
• How pending approvals work