Trust-mode floors

Governance → Policies → Trust-mode floors is the security team's authoring surface for delegation floors: per tool operation, the minimum attestation a caller must present and the delegation modes it is allowed to use. It is the authoring counterpart to the read-only Agent Identity portfolio, and it is available to org admins and security admins.

What a floor means

A floor is enforced by the platform's policy decision point as a ceiling control on top of any compliance rules: a call that reaches the tool must meet the minimum attestation and use one of the allowed delegation modes, or it is refused regardless of what the compliance rules would say. A floor has two independent parts, either of which may be left unset:

• Minimum attestation — how strongly the calling workload's identity must be proven: asserted (credential only), attested:placement (service-account token — which pod), or attested:workload (workload attestation plus image digest — which build). See attestation levels.
• Allowed delegation modes — under which authority the call may run: chained, connected_account:user, connected_account:workspace, mandate, agent_own, or none. For example, allowing only connected_account:user on a mailbox tool means every call must run as a connected human user — never as the agent's own service identity.

Registry-backed authoring

Floors are keyed per tool operation (<server>__<operation>), exactly like compliance rules — and you never type a key by hand. The editor is backed by the Tool Registry: it lists every governable registered server (MCP servers and APIs) with its operations, so a floor is always authored against a real, admitted operation. A typo'd key would author a floor that never matches anything, which is why free-text entry doesn't exist.

Each server renders as a collapsible card showing its type, its operations (each tagged with its side-effect class — read-only, mutating, or destructive), and a floored count. Servers that already carry floors start expanded.

Editing floors

The screen follows the console's edit convention: read-only until you click Edit floors, then Save floors or Cancel.

In edit mode you author in bulk:

1. Select operations — tick individual operations, or tick a server's checkbox to select every operation it exposes at once.
2. Set the draft floor — pick a minimum attestation and toggle the allowed delegation modes in the bulk-apply bar.
3. Apply floor to selected — stamps the draft onto everything selected in one action. "Clear floors on selected" removes floors the same way, and each floored operation also has an inline clear.

Saving requires a justification, recorded in the policy change log like any other org-policy edit. The platform validates every floor on save (and rejects unknown attestation levels or modes), and enforces the authoring permission on every write — the console gate is a convenience, not the security boundary.

Floors on tools no longer in the registry

If a floor exists for an operation that isn't in the current registry (the tool was removed, or the floor was authored elsewhere), the editor surfaces it in a separate orphaned floors list instead of hiding it. Orphaned floors stay in effect; clear any that no longer apply.