Configuring VibeCop for your organization

What can an organization configure in VibeCop?

An organization controls VibeCop from one screen, Settings → Access. It is a tree of on/off levers — product features, the detector agents that run in every scan, and the plan-review skills your coding agents can call over MCP. Each project can further narrow which agents run, and a separate privacy switch stops all automatic model calls. Changes are stored server-side, audited, and enforced everywhere the product runs.

There is no configuration file to commit. Everything below is edited in the product and read by the server on every request, scan, and MCP call, so the settings you see are the settings being enforced.

Who can change Feature Access?

A governor — the organization's owner, or anyone holding a role with can manage members switched on. Roles are defined per organization under project settings (Node Configuration → Roles) and assigned per project; whichever of your roles carries the highest weight decides. Everyone else can open the Access screen and read the tree, but every switch is disabled and the write endpoint refuses them.

Governors are also exempt from access levers: turning off Code Graph hides it from members but never from the people who can turn it back on. They are not exempt from agent or skill levers — see below.

What is in the Feature Access tree?

Six groups, each with a master switch and a count. Turning a group off hard-disables every lever under it; under a group that is on, levers toggle one by one. Hover the ? on any group or lever for its description.

The six declared only levers are an honest boundary, not a promise: toggling one writes an audit record and changes nothing in the product yet. The UI labels them so nobody mistakes them for a control.

How do access levers and agent levers differ?

Two things live in one tree and behave differently on purpose.Access levers govern what a person may do, so governors are exempt. Agent and skill levers govern what runs in the organization's shared scans and what its coding agents may call — a scan belongs to the organization, not to a user, so there is nobody to exempt. A disabled agent runs for no one, governors included.

How does a change reach my team?

The stored policy is the single source of truth. A governor's toggle is written once, with an audit record of who changed what and the before/after state, and every enforcement point re-reads it: REST gates within about thirty seconds, scans at the moment they start, MCP skill surfaces on every call, and your team's browsers on mount, on window focus, roughly every minute, and immediately after any blocked request. A stale tab can briefly show a feature the server already blocks; clicking it returns a refusal and the view reconciles.

What decides which agents run on a scan?

Three inputs, combined with AND. The organization policy is the ceiling. Each project's Agents screen is the floor underneath it — a project can switch off agents the organization allows, but can never switch on an agent the organization disabled. The AI-analysis switch in Settings → Billing is a privacy control: off means no automatic model call touches your data, which drops the three agents that send source to a model and the narrative judge. Infrastructure agents (stack profile, repo context, graph facts, history, pattern fingerprint, system topology) always run — other agents depend on them, so they are not levers.

Why does my Integrity Index show “—” with an ⓘ?

Because a deep agent did not run. The index is the sum of four axis tiles and each tile is fed by specific deep agents; an agent that is switched off cannot report findings, and an empty axis would score a perfect 25. Rather than let a disabled agent raise the index, VibeCop records no index at all for that scan — the findings the other agents produced are still there. The gauge dims to “—” and the ⓘ explains which switch is responsible: “Deep agents need to be enabled for integrity score” when the organization policy or a project toggle disabled one, or “AI analysis needs to be enabled for integrity score” when the privacy switch is off. Turn the agents back on and the next scan restores the score. A bare “—” without an ⓘ still means no scan has completed yet.

How do project-level agent toggles work?

Open Agents with a project selected. The sixteen static and deep agents show a switch each; infrastructure agents and the judge are taggedalways runs. A project toggle is enforced on that project's scans from the next run, is audited, and can only narrow the organization policy. Only governors can change it. The Overview for that project reflects it: switch off a deep agent and the project's score surfaces show the dimmed gauge and ⓘ, while the org-wide dashboard hero does the same whenever any project has narrowed its deep set.

What happens to skills and webhooks when they are off?

A disabled skill disappears from list_skills and the prompt palette, and get_skill, prompts/get, and vibecop_check refuse it with skill_disabled_by_org. A coding agent that already has the skill cached cannot run it. Webhook auto-review off stops members minting new hook tokens and stops the organization's pull-request webhooks from queuing reviews.

Is there an API?

Yes — the same endpoints the screen uses, authenticated with your session token.

What if the screen says read-only, or that the policy could not be read?

Read-only means you are not a governor — ask the owner, or a role with can manage members, to make the change or to grant the role. “The policy could not be read just now” means the server hit a transient error reading the policy and fell open: everything is treated as enabled, the banner and the API's policyDegraded flag say so, and no lever silently tightens or loosens. Reload in a moment. If a toggle seems slow to bite, remember the propagation window: up to thirty seconds for REST, the next scan for agents.