Docs/Agents & governors

Governors and execution identity

Screens 5.3 and 5.4 — bound allowed operations, destinations, quotas and approvals; define who an agent runs as.

PEEK Platform Administrator

/peek/customers/tenant-a/5-3

Live walkthrough · Governors and execution identity

Governors and execution identity — /peek/customers/tenant-a/5-4 — /peek/customers/tenant-a/5-4

A governor limits what an agent may do — allowed operations, destinations, quotas and the exact human approvals per action. Prerequisites are declared per action, not as a blanket dependency, so ordinary Core human handoffs never require Agentic Operations.

Every tool action rechecks current capability, data and source-use rights.
Retrieved text cannot expand the manifest: an instruction in a document to “add a recipient” is ignored.
Agents run as the current user or a scoped agency workload identity with its own grants — never as PEEK or a departed user. Revoking that identity or a source grant stops the next tool call.

5.3 · Governors & Action Boundaries

Bound agent actions and human decision points. Open it at /peek/customers/tenant-a/5-3 (any tenant ID you can access works in place of tenant-a). The primary action is Publish governor profile, which requires governor.publish.

How 5.3 works

1. Bound allowed operations, destinations, quotas and exact human approvals for each action

Screen 5.3 contract

Fields shown: Allowed operations, destinations, limits, approval requirement
Primary action: Publish governor profile
Required capability: governor.publish
Validation: Every tool action checks current capability, data and source-use rights. Retrieved text cannot expand the manifest.
Successful outcome: Governor version limits execution without gating ordinary Core human handoffs.
Screen states: Loading; empty; ready; restricted; stale; error; review pending
Audit event: admin.screen.5.3.action (acceptance test AT-UI-5.3)
Requirements: R02, R06, R15, R28, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-5.3

Boundary — Declare prerequisites for each action, not a blanket dependency for the module. Internal Core handoffs and human decisions do not require Agentic Operations.

Rejected even if the browser allows it — Put an instruction in retrieved content to add a recipient or tool; the executor must ignore the authority claim.

5.4 · Execution Identity & Connections

Define eligible execution identities and connection references. Open it at /peek/customers/tenant-a/5-4 (any tenant ID you can access works in place of tenant-a). The primary action is Validate execution profile, which requires execution_profile.publish.

How 5.4 works

1. Specify user-driven or agency workload execution, allowed connection profiles and required custodians

Screen 5.4 contract

Fields shown: User or service identity, delegated scope, credential custodian
Primary action: Validate execution profile
Required capability: execution_profile.publish
Validation: Workload identity has its own scoped grants; it cannot borrow PEEK or a departed user's rights.
Successful outcome: Profile validation returns permitted action intersection and missing agency setup requirements.
Screen states: Loading; empty; ready; restricted; stale; error; review pending
Audit event: admin.screen.5.4.action (acceptance test AT-UI-5.4)
Requirements: R02, R06, R14, R15, R28, SYS02, SYS04, SYS06, SYS10, SYS11, SYS20, SYS23, UI-5.4

Boundary — Use current user rights or a scoped agency workload identity. Recheck module, source and processing prerequisites at each execution step.

Rejected even if the browser allows it — Revoke a service identity or source grant before the next tool call; stop the affected action.

Related guides

Automation overview and agent templates

Screens 5.1 and 5.2 — review the permitted automation portfolio per tenant and release agent templates for agency adoption.

Communication rules and simulation

Screens 5.5 and 5.6 — govern outbound messages with exact-content approval, and test templates against synthetic cases before release.