Governance & Control Center

Sally lets agents act, but never blindly. The Control Center is Sally's safe-autonomy layer: agents propose work, workspace trust policies decide what runs automatically and what waits, and humans approve anything risky — with normalized evidence and an append-only event ledger behind every decision. Safe, reversible work (memory, notes, tasks, drafts) can auto-run; risky actions (sends, publishes, deletions, deploys, exports, bulk updates) are quarantined for a person to approve.

This is the mechanism behind Sally's one permission model: an agent's reach is never broader than the credential behind it, and even inside that reach, trust policies and approvals govern what it can do without a human.

Proposals

A proposal is an agent's request to perform one or more actions. Instead of firing an action directly, an agent submits a proposal carrying the actions plus evidence for why they should happen. Sally evaluates it against the workspace trust policy and either auto-executes it, or parks it as pending for human review.

Each proposal has a status: PENDING, APPROVED, DENIED, AUTO_EXECUTED, EXECUTED, BLOCKED, or CANCELLED. A person can approve, deny, or execute a pending proposal from the Control Center; agents can watch their own proposals resolve.

MCP tools: proposal.create, proposal.list, proposal.get, proposal.resolve, proposal.execute.

A pending proposal in the Control Center showing its actions and evidence — A pending proposal, expanded — the typed actions it would run and the structured evidence behind it (context used, checks performed, decisions, risks, and outputs).

Trust policies

Trust policies are how you tune autonomy per brand. A policy is scoped to a workspace and a source — where the request comes from: HUMAN, MCP, CHATGPT, CODEX, CREWAI, PI, AGENT, or SYSTEM — and can optionally target a specific agent identity.

Each policy sets:

allowedActions — the action types this source may take.
requireEvidence — whether proposals must carry evidence (on by default).
maxActionsPerProposal — how many actions a single proposal may bundle (default 5).
maxActionsPerDay — a daily action cap for the source (default 50).
yolo — when set, this source's proposals auto-execute regardless of action type. Use with care.

When a proposal arrives, Sally evaluates it in order: check evidence, check the caps, then decide. If yolo is on, it auto-executes. Otherwise, it auto-executes only when every action is explicitly allowed and none is risky; anything else routes to human approval.

The Control Center trust policies panel and proposal inbox — A trust policy for a source — its allowed safe actions, the evidence requirement, and the per-proposal cap — sitting above the proposal inbox it governs.

The action taxonomy: safe, risky, yolo

Sally classifies actions so the same proposal is handled consistently everywhere.

Safe actions are reversible and low-blast-radius, and can auto-run under a permissive policy:

memory.create, memory.intake.execute
crm.activity.add, crm.follow_up.add
task.create, task.update, task.move, task.handoff.create
task.todo.*
comment.add, task.comment.add
blocker.create, approval.request
newsletter.draft.create

Risky actions are always quarantined for approval — they leave Sally, touch customers, or can't be easily undone:

email.send, newsletter.send
publish.external, code.deploy
data.export, record.delete
crm.bulk_update, marketing.bulk_update, external.write_back

Yolo isn't an action type — it's the escape hatch on a trust policy that lets a trusted source auto-execute anything, risky included.

Approvals

When a proposal or a handoff needs a human decision, Sally creates a typed approval request so the question reaches the right person with the right framing. Each request carries a question, options, an agent recommendation, and a status.

Approval types:

PUBLISHING
LIVE_DEPLOY
CREDENTIAL
PAYMENT_DATA
CUSTOMER_DATA
CLIENT_DECISION
DESTRUCTIVE_ACTION

Marketing mass sends always route through approval rather than executing directly — see Marketing. Agents can request an approval as a first-class step (approval.request is a safe action), and approvals surface in a task's context and in project.runtime_context.

A typed approval request card with the agent's question, recommendation, and approve or deny controls — Approvals, blockers, and marketing sends side by side — each card carries the agent's question, the context it used, its recommendation, and the human's decide controls.

Blockers

A blocker is a first-class "cannot proceed until a human resolves X" object. Rather than guessing or improvising, an agent raises a structured blocker, which moves the task to Blocked and records what input it needs.

Blocker types: CREDENTIAL, ACCESS, STAGING_FAILURE, ARCHITECTURE_CONFLICT, TEST_FAILURE, CLIENT_DECISION, LIVE_APPROVAL, DEPENDENCY, AMBIGUITY (default), and TOOLING_FAILURE. Each has a status (OPEN, RESOLVED, CANCELLED), a summary, and a requiredInput field.

Blockers are created through the handoff flow (see below), not a standalone tool. They surface in project.runtime_context, in task.get, and in task.resume_context so the next worker — human or agent — sees exactly what's outstanding.

Handoffs and evidence

The handoff is Sally's signature agent-to-human workflow, and where evidence discipline is enforced. task.handoff.create hands work back with a structured brief instead of a vague comment: a decision needed, a context summary, a recommendation, next-step instructions, and risks.

Depending on state, one handoff can:

create a real blocker and move the task to Blocked,
create an approval request and move the task to Review, or
move the task to a suggested status when it's simply done.

Every handoff and proposal records normalized evidence with a consistent shape:

sources — what the agent looked at
checksPerformed — what it verified
decisions — what it decided
assumptions — what it took as given
risks — what could go wrong
outputs — what it produced
confidence — how sure it is
nextSteps — what comes next

The inverse, task.resume_context, returns the latest handoff, its evidence, open blockers, pending approvals, recent decisions, and a computed recommended next action — so agent work is resumable, not restartable. As a safety measure, agent-supplied evidence and action JSON is scanned and secret-like values are rejected, so credentials don't leak into the ledger.

MCP tools: task.handoff.create, task.resume_context, project.runtime_context. See Projects & tasks for the full handoff flow.

The operational-event ledger

Every governance decision writes to an append-only operational-event ledger — the audit trail of how autonomy actually played out. Event types include CONTEXT_READ, RECOMMENDATION_CREATED, ACTION_PROPOSED, APPROVAL_REQUESTED, RESOLVED, ACTION_EXECUTED, the BLOCKER_* events, MEMORY_WRITTEN, and EXTERNAL_RESULT.

Reading context writes a CONTEXT_READ event; proposing writes ACTION_PROPOSED; approving and executing write their own events. Each decision also writes a corresponding entry to the security audit log, so governance activity is visible both operationally (what agents did and why) and for compliance (see Security).

The operational-event timeline: context read, action proposed, approval requested, action executed — The operational-event trail — every step an agent takes is logged: context read, action proposed, approval requested, and the safe action it auto-executed under its trust policy.

Automation governance

Beyond individual proposals, Sally governs whether and how automated workflows run.

Per project — automation config controls whether the project's workflow is enabled, its default agent, whether live actions require approval (on by default), and whether work is staged before going live (on by default). Only one active workflow job runs per project at a time.
Deployment-wide — an automation governance policy sets the allowed runtime types, which roles may start workflows, the maximum concurrent workflow jobs, and whether starting a workflow requires approval.

Because Sally is runtime-agnostic, these controls apply to any connected agent — Sally's own reference worker, Claude, ChatGPT, or your own runtime — through the same trust policies, approvals, and evidence rules. Connectivity is tracked too: revoking an agent connection cancels its active jobs and runs.

For agents

If you're building or connecting an agent, the governed loop is: call sally.context (or project.runtime_context) to ground yourself, decide what to do, then proposal.create with evidence. Safe, allowed work returns executed; risky work returns pending for a human, and you can raise a blocker or an approval request explicitly. See Connect your agent.

Roadmap

Some governance-adjacent surfaces are declared but not yet wired end-to-end:

External work-item sync. Sally can reference external items (LINEAR, JIRA, GITHUB), but only native Sally items are fully exercised today; treat cross-tool sync as not-yet.
Per-tenant security policy. Password, session, 2FA, audit, and key policies are currently deployment-global rather than per-customer (aside from a per-account two-factor requirement) — see Security.