Company policies

What a policy is

A policy has three parts, each optional — a policy can be pure prose, pure enforcement, or both:

Prose

Markdown injected into every employee's system prompt, in a ## Company policies section. "Never discuss pricing over email," "always disclose that you are an AI" — the rules a human handbook would carry.

Blocked domains

Recipient domains no email may go to — a competitor, a regulator, a litigation counterparty. Enforced at the same mail-send choke point as the suppression list, for every sender, human or AI. Subdomains are covered; lookalike domains (notacme.com for acme.com) are not false-matched. The error names the policy that blocked the send.

Forbidden tools

Genosyn catalogue tool names no employee may call — refused at AI tool dispatch with a policy.violation audit event. find_tools and call_tool cannot be forbidden, so an employee can always discover that a refusal came from policy rather than a broken tool.

Policies frame the Soul

The ## Company policies section sits above the Soul in every employee's prompt, and that ordering is the point: policies bind the whole company, and each employee's Soul is read inside their frame — never the reverse. A Soul describes one employee's character and judgement; a policy is the boundary that judgement operates within. The injected section says so explicitly: the rules bind every employee, and the mechanical clauses are enforced by the platform either way.

Managing policies

• Open Settings → Policies. Creating, editing, disabling, and deleting a policy is admin-only; reading is member-level, because everyone in the company — human and AI — is bound by them.
• Each policy has a title, optional prose, and the two optional mechanical lists — blocked recipient domains and forbidden tools, one entry per line.
• A disabled policy stops binding immediately — it is neither injected nor enforced until re-enabled.

Every enforcement is on the record. A blocked send or a refused tool call writes a policy.violation audit event naming the policy, the actor, and what was refused — so drift between what the rules say and what employees attempt is legible in the audit log, not silent.

Ad-spend budgets

A Budget is a monthly envelope over authorized ad-spend increases — the company-wide layer above the per-Connection caps. Where a cap says "no single change, day, or rolling month may exceed this on this Connection," a Budget says "this scope authorizes at most this much this calendar month," measured over the UTC calendar month and reset when it rolls over.

A Budget scopes to the whole company, one Connection, or one AI Employee, and a spend increase must fit inside every applicable envelope — the tightest binds. Enforcement runs at the same seam as the caps, on every spend-increasing mutation on every path, including approval replays: an envelope that ran dry between an Approval queueing and a human's ✓ still binds when the replay fires.

• Exhaustion refuses, names, and redirects. The mutation fails with the budget named and its remaining headroom, and the employee is told to raise a Decision or wait for the month — not to retry.
• Owners and admins are paged once per budget per month on first exhaustion — a retrying employee cannot ring the bell on every attempt.
• Spend-decreasing actions are never blocked. Pausing a runaway campaign or lowering a budget is the emergency action; an exhausted envelope must never delay it.

Budgets are managed from the Budgets page — writes admin-only, reads member-level, since an envelope is spend authority. Each row shows the month's authorized spend against the envelope, so headroom is visible at a glance.

The taint policy

The open web is where hostile content meets side effects: a page an employee fetched can address the model directly, and what an injected instruction most wants is an outbound email or a persistent foothold. So Genosyn tracks taint per turn, on by default. A turn that uses the web tools — search_web, fetch_web_page, download_web_file — is marked tainted for the rest of that turn. There is no untainting: the model has already read whatever the page said.

A tainted turn calling a high-risk sink — send_mail, or create_routine / update_routine / delete_routine, the tools an injection would use to persist itself on a schedule — does not execute it. The verbatim call is held as an Approval (kind tainted_tool) in the same Approvals inbox as everything else, and the employee is told to carry on with its unheld work. Reads are never gated — a tainted turn can keep researching freely.

• Approving replays the exact call server-side with a fresh employee-authority token — the same handler, grant checks, and audits the original call would have hit, minus the taint.
• Rejecting writes a warning to the employee's journal about the page's content, so the next run starts suspicious of it.

The gate is configured by agent.taintPolicy in config.ts — "web" (the default) arms it, "off" disables it.