AI Assistant Governance Checklist: Permissions, Evals, and Control

Maintain a registry with assistant name, purpose, users, business owner, technical owner, current version, model, data classes, tools, autonomy level, external actions, evaluation suite, and review date. Include default, custom, shared, and published assistants. Unowned assistants should not remain active in sensitive workflows.

The business owner accepts whether the workflow is useful and appropriate. The technical owner maintains configuration, tools, and monitoring. A data or security reviewer may approve sensitive scopes. The person using the result still owns the business decision unless responsibility has been explicitly assigned elsewhere.^[5]

Grant only the context and tools needed for the registered purpose. Keep tenant, workspace, user, and resource boundaries enforceable outside the model. Treat retrieved content as untrusted data. Do not rely on the assistant to infer whether an action is authorized from conversational context alone.^[6]

Classify actions by impact and reversibility. Read-only inspection may run automatically inside approved scope. Creating an internal draft can be automatic. Updating an external record should show a structured preview. Sending, publishing, paying, deleting, changing permissions, or making a binding commitment should require explicit approval and a rollback or recovery plan where possible.^{[4] [1]}

Create capability cases for hard tasks, regression cases for known-good behavior, and safety cases for data boundaries, prompt injection, excess agency, and escalation. Run multiple trials where variability matters. A version should not pass because its average prose quality improved while one prohibited action became possible.

Combine graders. Deterministic checks confirm required state and prohibited calls. Rubric-based graders assess open-ended quality. Human experts calibrate subjective judgments and review high-impact cases. Anthropic recommends evaluating the outcome and trajectory because a confident completion message can disagree with the actual environment.^[3]

A useful run record includes the initiating user, assistant version, route, specialists, context references, tools, approvals, timestamps, outcome, verification, errors, and cost-oriented telemetry. Alert on unusual tool sequences, repeated failures, budget exhaustion, unexpected data scopes, approval bypass attempts, and changes in acceptance or escalation rates.

Define a stop mechanism and incident owner before launch. Response may include disabling an assistant version, revoking a connector, pausing an action class, preserving traces, identifying affected records, notifying responsible teams, rolling back reversible changes, and adding a regression case before reactivation.^{[6] [5]}

Sharing expands the audience and may change the data or tool context in which an assistant runs. Published assistants need a clear owner, supported use, limitations, and version policy. Forking is safer than silently editing a shared configuration when another team needs different instructions or permissions.

Kona assistants support versions, sharing, publishing, and forking. Capability declarations separate web, code, canvas, and connector use. Workspace orchestration is bounded, and run records preserve routing, participants, status, verification, and operational telemetry. Connector actions are designed to cross policy and approval gates instead of inheriting blanket authority from a chat.^{[8] [10] [11]}