Governance

Managed services. The governance engine is available with the Advanced and Ultra plans of Polyant managed services.

Governance applies policy gates to an agent’s input, output, and tool activity. It provides a shared policy catalogue and lets operators assign policies to individual agents.

Policy catalogue

The catalogue lists the policies available to the organization. It is org-scoped, not deployment-wide and not per-workspace: two organizations on the same engine keep separate catalogues, and every workspace inside one organization draws from its single catalogue. A policy records its name, description, category, severity, gate type, and level. Platform policies marked immutable cannot be edited or deleted.

It is addressed as the organization’s own resource (/api/organizations/{org}/governance/policies), which is why it is governed by the organization-tier permissions rather than the agent-level ones.

The catalogue supports these policy categories:

• input-safety
• output-safety
• data-protection
• tool-governance
• rate-limiting

Reading the catalogue requires org.governance:read - which a Viewer holds, since reading the organization’s policy list is consistent with a read-everything role. Creating, changing, or removing a mutable policy requires org.governance:write, which is Admin and above.

The agent-level agent.governance:read / agent.governance:write pair governs what an agent has assigned, not the organization’s catalogue. The two are separate keys on purpose: an org-addressed route has no workspace to resolve a workspace-tier permission against, so gating the organization’s catalogue on one agent’s rights would let a Member reach the whole tenant’s policy. See Roles and permissions.

Governance analytics

Two aggregate views exist, at two levels:

• Workspace - the sidebar’s Governance entry (/organizations/{org}/workspaces/{ws}/governance), aggregating the agents in front of you. Needs agent.governance:read.
• Organization - part of the organization dashboard, aggregating the whole tenant.

Assign policies to an agent

Open an agent’s Policy section, in its Governance group, to view its effective assignments. An assignment selects a catalogue policy and can set:

• Enabled - whether the policy participates in the agent’s pipeline.
• Enforcement - log, warn, or block.
• Configuration override - agent-specific configuration that supplements the catalogue policy.

Assignments and governance analytics use the same agent.governance:read and agent.governance:write permissions. A policy can also be assigned platform-wide, in which case it cannot be removed from an individual agent.

Where the events are

The record of which gate actually fired is not in this section: it is in the agent’s Log section, under Activity, together with the task and webhook runs. Both are a record of what happened rather than configuration, which is why they sit together and away from the rules they came from.

You open Policy to change a rule and Log to find out whether one fired - and the second is usually the question you arrive with when something looks wrong.

Narrowing the event list

An agent’s governance events can be filtered by conversation and, within it, by turn - the assistant message the event was raised on. Input, output and tool-phase events all carry that attribution, which is what makes “what did the gates do on this answer” a question with an answer rather than a scan of a timeline.

Two kinds of conversation are the exception: those driven by the Room and by webhook triggers. Those paths mint a fresh conversation per cycle and have no stable turn id to stamp on an event before the gates run - the assistant message is persisted, but the id is minted too late. Their events appear in the list and are attributable to the conversation, not to a turn.

How enforcement works

Each gate runs in one pipeline phase:

• Input gates inspect a message before the model is called. A blocking result stops generation.
• Tool gates inspect a requested tool call before the tool executes. A blocking result prevents the call.
• Output gates inspect the generated response before it is delivered. A blocking result replaces the response with the governance block message.

The gate returns an allow, warn, or block verdict. Assignment enforcement determines how that verdict is applied: log records the result while allowing the pipeline to continue, warn surfaces a warning, and block preserves a blocking verdict.

When the classifier itself fails

The three semantic gates - prompt injection, PII, topic guardrail - ask a model for a verdict, and they fail open on purpose: a broken classifier must not block legitimate traffic.

Failing open used to be indistinguishable from finding nothing. A timeout, a provider error and a model answering outside JSON all arrived as the same empty result, so the agent answered normally, no error was raised, the policy list still said enabled, and the only symptom was the absence of verdicts - which nothing counts.

Now the three causes are kept apart, and a gate that could not evaluate still allows but records the allow, marked as unevaluated and carrying its cause, beside the below-threshold verdicts already persisted. A policy that stopped working is therefore visible as rows rather than as a gap.

A policy that must never let unexamined content through can fail closed instead. Turn on Block when it cannot check on the policy’s assignment in the agent’s Policy section, or set failClosed: true in the policy’s configuration or the assignment’s override. With it on and the assignment’s enforcement at block, a message the classifier could not evaluate - a classifier error, an outage, or a refused provider admission - is blocked rather than let through, and the event says the policy failed closed. Under log or warn enforcement the setting changes nothing. It is off by default, so every existing policy keeps failing open; turn it on only where blocking during a classifier outage is the lesser harm, since it stops the agent answering for as long as the classifier is down.

The heavy tier these gates run on is worth knowing about for the same reason: on a deployment where that model is unavailable in the region, all three stop gating with a single warning line. See AI Gateway.

Output gates and streaming

An enabled output gate requires the engine to buffer the response before delivery. The agent is therefore served non-streamed for that turn, allowing the output gate to redact or block text before any token reaches the client.

Use output gates when a response must be checked before it reaches a channel; use input and tool gates when the risk is in the request or requested action instead.