Tenant settings

Retention

How long CorPole keeps what it records about people and agents: the agent access log 2 years (then deleted), full texts of agent calls 90 days (then the text goes; the call, digest and hash stay), agent session detail 90 days (then events go and the person is forgotten; totals stay), prompt texts 30 days (then the text goes). Owners and admins can shorten each period down to its minimum, never lengthen it; the daily run applies it. The change history and the records are the audit record and are kept — a value written by mistake is redacted, not deleted.

Auditor access

Owners and admins can let an auditor read some or all solutions through their AI client without making them a member: name the auditor and the purpose, choose the solutions (none chosen: all) and the end date (up to 90 days). The token is shown once with one address per solution (…/api/mcp?solution=KEY). It works on the MCP endpoint only and sees read tools only — nothing can be proposed, moved or changed — and every read is logged once in the solution it reads (Audit trail, agent "Auditor …"). The list shows last use and the number of reads; End access stops the token at once. The access review lists it as an auditor token.

Issue trackers (Jira, Azure DevOps)

Owners and admins connect the tenant's Jira Cloud site (address, a service account's e-mail and API token) or Azure DevOps organisation (address and a personal access token with Work Items read & write) once. CorPole checks the credentials and keeps the token encrypted. Every solution whose key or name matches a tracker project is bound to it — new solutions too, on the next sync — and the others can be bound by hand. From then on it syncs on its own: the webhook (one for the Jira site; in Azure DevOps one service hook per bound solution) brings changes at once, and CorPole reconciles every 15 minutes.

• Epics, stories, tasks and defects become issues (types and statuses follow the editable mappings); the acceptance criteria appear under a marked line of the description.
• Title, description, status, owner and parent move both ways. A field changed on both sides since the last sync is a conflict that a person settles, here or on the solution's settings.
• A status set in the tracker passes the same checks as a move in CorPole, with the permissions of the member with the same e-mail. Moves by people CorPole does not recognise count as automated unless Trust moves made in the tracker is on; Done always needs its criteria met and no failing test. When CorPole refuses, it puts the status back and comments why.
• A criterion line changed in the tracker becomes a change proposal on its record. New issues come into the bound solution's Backlog (switchable); issues deleted there are marked missing, and nothing is deleted in CorPole.

Task governance

Tasks are work without development. Per category (configuration, access, data change, documentation, operation) you can require approval before a task is carried out and a check by a person before it is Done. Nothing is required unless you turn it on.

Maker-checker: the requester cannot approve, and whoever carried a task out cannot check it. AI agents never approve or check.

Work gates

• Definition of Ready: a story is Ready when it implements an Authority requirement and covers at least one of its criteria.
• Done: a story or defect is Done when every criterion it covers is Met, confirmed by a person or a passing test — a criterion only an AI agent reported as met shows "Agent-reported, not verified".
• Advisory lets the move happen and writes what was missing into the history; Enforced refuses it and says what is missing.
• Demand ("no work without a demand"): work is committed — to Ready, or straight to In progress — and an initiative moves to Ready or Implementing only when the initiative answers a demand. Enforced by default; it can be relaxed to Advisory or Off. Initiatives the system opens (charter, onboarding, maintenance, urgent work) always have their demand. Check the effect first under Governance preview.

Block reasons

Work can only be marked blocked with one of these reasons, plus an optional note. One reason per line; leave empty to use the defaults.

AI agent policy

For each action, choose Allowed, Ask first or Forbidden: database migrations, dependencies, CI/CD and infrastructure, security code, changing tests to make them pass, breaking public contracts, merging, pushing to main, deploying and production data; and which CorPole actions agents may take (proposals, results, moving work and more).

• CorPole actions are enforced by the server: a forbidden tool call is refused and logged.
• Code actions with a command or path pattern become Claude Code permission rules (ask / deny) in the repository kit's .claude/settings.json.
• All rules are given to agents with get_agent_policy and in every work context.
• Solutions inherit the tenant policy and can only make it stricter (Solution settings). Changes are kept in the change history.

Agent gates

Tip During a declared production emergency both gates only advise (Agents → Production emergency).

Agent drift thresholds

Override the account's thresholds for this tenant. An empty field uses the account's value, shown as the placeholder.