What the operator controls

Default-permissive systems require the IT admin to de-permission what they do not want. A Yig deployment arrives empty and requires explicit installation of what they do want.

The principle: explicit installation, not default permissiveness. A new deployment has no surfaces enabled, no workflows installed, no reviewers authorised, and no audit destination configured. The operator turns each one on, with a named accountability for the choice. Capabilities that were never granted cannot leak in later through a misconfiguration.

The operator is the upper bound on what Yig can do in a given deployment. If a surface is not enabled, the agent cannot be reached through it. If a workflow is not installed, the agent cannot run it. If a reviewer is not authorised, the agent cannot ship to them.

The six control dimensions

1 · Surfaces

Disabling a surface is immediate. The operator selects which surfaces the agent is accessible from. Available surfaces are CLI, Slack, Teams, Feishu, Google Chat, Excel add-in, Word add-in, and the REST/WebSocket API gateway.

Enabling a surface does not expose all capabilities. Each surface is independently scoped: the Slack integration can be configured to respond only to specific channels or only to specific users.

A controller cannot enable the API gateway; only the operator can. A revoked surface stops responding to the bot the moment the revocation lands — the next message sent to the workspace bot receives no response.

2 · Workflows

The agent runs no workflow that the operator has not installed. Templates in the library are unavailable in a deployment until the operator installs them — installation is the line at which finance judgement applies, not after.

Workflow installation is explicit. The operator reviews the template, confirms the input shape and output shape, and installs it.

An FP&A lead cannot enable a new workflow because they need it on Friday; they request it, and the operator installs it. Installed workflows can be paused or removed at any time. A paused workflow is visible to the agent as unavailable until the operator restores it.

3 · Model provider

The agent uses exactly the model the operator configured — no other. See The BYOK model for the full implication.

The operator can switch providers at any time. The audit log records which model was in use for each run. A controller cannot switch from a frontier provider to a self-hosted endpoint mid-cycle; the change is the operator’s, recorded and dated.

4 · Audit log destination

The audit log is written where the operator says, and Yig does not retain a copy. Object storage, a log pipeline, or the local file system — the operator chooses.

The destination is set at deployment time and can be changed. When the destination changes, new records go to the new destination; historical records remain where they were written.

The operator is responsible for retention, backup, and access control on the audit log. An internal audit lead can request a log export, but the IT admin running the deployment owns where it lives.

5 · Reviewer authorisation

Running and reviewing are separate permissions. A user who can run a workflow is not automatically authorised to approve its output.

The operator assigns which users are authorised reviewers for which workflows. The separation is intentional: it allows an organisation to require that a controller approves outputs from a workflow a junior analyst can trigger.

Reviewer authorisation can be updated at any time. Removing a reviewer does not affect historical audit records — records that name a reviewer who has since been deauthorised remain valid.

6 · Deployment topology

Topology is the operator’s call, not the vendor’s. Local, customer cloud, or single-tenant managed — see Deployment topologies in practice for the tradeoffs.

A security reviewer can ask for a topology change as part of a posture review; the operator executes the change, and it is recorded.

What the operator cannot change

The following are structural and not configurable:

• The reviewer gate. The requirement that an output be approved by an authorised reviewer before shipping cannot be disabled.
• The audit log format. The fields recorded in the audit log are fixed. The operator can choose the destination; the operator cannot choose what is omitted.
• Cross-namespace isolation. In Enterprise deployments, namespace isolation between teams cannot be relaxed. Team A’s agents and logs are not accessible from Team B’s namespace regardless of configuration.
• The BYOK requirement. The agent will not make inference calls without an operator-provided API key. There is no shared Yig inference credential that the agent can fall back to.

The principle, restated

The six dimensions all enforce the same principle: explicit installation, not default permissiveness. The bet behind it is that an agent which can only do what was explicitly granted is an agent a security reviewer can defend — and an agent a regulator can hold to. The model’s capability is upstream; the discipline of the control surface is downstream. The downstream is what makes the agent deployable in regulated environments. Not the sophistication of the model. The shape of what the operator did and did not turn on.