Audit logs, roles and policies for AI coding

In AI CodeOps, governance is the set of controls around every AI session: roles decide who may do what, policies decide what the AI may do and what needs approval, the audit log records who changed what, and each change gets a signed evidence pack. Together they answer the three questions an auditor asks about AI-written code: who allowed this, what did the AI do, and can you prove it.

Which agents run

Governance applies to every agent, so it is about control rather than one agent's work:

• Policies per agent. A rule on agent.dispatch can allow, ask for approval on, or deny a given agent's step, such as the Builder or the DevOps Engineer. A session containing a denied agent does not start.
• Workspace agents. A workspace can override a built-in agent's instructions and model under Configure, Agents, and narrow which MCP tools that agent may call. The override applies to that agent's steps only.
• Recorded per step. Each agent step is stored with its agent, model, tokens and cost, and ends up in the evidence pack.

See the agent catalogue for what each built-in agent does.

Policies

Workspace policies decide what an AI session may do. A rule names an action, an optional resource pattern and a decision:

When several rules match, the strictest wins, so a rule added later can never quietly loosen an earlier one. Actions that cannot wait for a person (MCP tool calls, test commands and automatic deploys) take allow or deny only. A trust setting covers actions no rule matches: trusted allows them, limited (the default) asks for an approval before a session's pull request, and none makes sessions read-only. The ruleset as the Policies page saves it through PUT /api/policies:

{
  "enabled": true,
  "workspaceTrust": "limited",
  "rules": [
    {
      "id": "infra-needs-review",
      "action": "diff.apply",
      "resource": "infra/**",
      "decision": "ask",
      "description": "Infra changes need an approval"
    },
    { "id": "no-auto-prod", "action": "release.deploy", "resource": "production", "decision": "deny" },
    { "id": "payments-repo", "action": "github.push", "resource": "acme/payments", "decision": "ask" }
  ],
  "expectedVersion": 7
}

An invalid ruleset is refused with every problem listed. Every deny and ask decision is recorded.

Roles

Every member has one role per workspace:

Only an owner can assign a role that carries administrative rights, and a workspace can never lose its last owner. Custom roles (Enterprise) are built from the same permissions, under Settings, Roles & Permissions. See members and roles.

Quality gates involved

• Approvals. Every AI change needs an approval from someone allowed to decide it, by default owners, admins and security admins. The person who started the session cannot cast the approving vote while another approver exists in the workspace; a one-person workspace can self-approve. One rejection ends the request. Teams can be named as approvers.
• Policy holds. An ask on starting a workflow opens an approval, and the session waits. An ask on files or the repository holds the pull request until it is approved.
• Fail closed. If the policy cannot be loaded, the session does not start.

The quality gates page explains how approvals, tests and findings combine.

Audit log

The Audit Log (under Measure) records who changed what: members and roles, API keys and their scopes, policies and approval decisions, secrets, provider keys, budgets, MCP servers, agents, schedules, people editing an AI session's code, and evidence pack downloads. Each entry stores the time, account, action, target, IP address, user agent and a short description. Refused or failed attempts are recorded too. Reading it needs audit access. How long entries are kept depends on your plan; on Enterprise they are kept indefinitely. There is no CSV export yet.

Sign-in security

• Two-factor authentication with an authenticator app or a passkey, plus recovery codes. Owners, admins and roles that manage sensitive settings must use it.
• Single sign-on with SAML 2.0 or OIDC on Enterprise, after you verify your email domain.
• Scoped API keys limited by permissions, IP ranges, rate limit and expiry. A key acts as the member who created it, with that member's current role.

Signed evidence packs

Every change has a Download evidence pack button. The JSON pack records the task, the models and tiers used, each run's tokens and cost, approvals and votes, policy decisions, findings and their triage, test results, the pull request, deployment and any incident, and the audit entries about all of it. The code itself is not included; a SHA-256 hash of the diff matches the pack to the pull request. The pack is signed with Ed25519, and anyone can check it at /evidence/verify without an account. See evidence packs.