Capability Tiers and Verification Posture

Every capability used to carry a single number: a security level from L0 to L3, picked from a radio button. That number was doing three jobs at once — how risky the action is, what evidence should unlock it, and whose account it runs as — and none of those jobs were visible to whoever was configuring it. Capabilities now separate those concerns. The action tier (read / act / transact) lives on the capability and says how risky the action is. Subject binding, on the connection, says whose account the call runs as. Publishing an act or transact capability now goes through a checklist that the server enforces, not just the editor. And a tenant-wide reveal posture controls what an unverified caller is told about all of this while they’re on the line.

If you configured capabilities before this change: the old L0-L3 radio and its identity-fields editor are gone. Existing published capabilities were migrated automatically and were not re-gated — the checklist only applies going forward, to new publish actions.

The three tiers

• Read — Looks something up, changes nothing — No extra proof beyond a normal signed-in or on-record contact
• Act — Changes something, but it’s reversible or low-stakes — Subject binding + an ownership rule, so the action is scoped to the right account
• Transact — Moves money, cancels something, or otherwise can’t be casually undone — Signed-in identity on chat; on a call, it never binds — the caller gets a human handover instead

Transact’s requirement is deliberately channel-honest: the same capability behaves differently depending on how the customer reached it. A transact-tier capability can run for a signed-in chat customer, but it will never bind on a voice call — the status block offers a handover to a person instead of quietly refusing or, worse, letting a caller push through without you noticing.

An AI enricher can propose a tier when a capability is created, shown as an AI-suggested chip next to the tier row — but it never overwrites a tier you’ve set by hand, and it only auto-publishes its own read-tier proposals. Anything it proposes above read still needs a human to confirm it.

The tier card in the editor

Open a capability built with the guided path (Guided setup, not the advanced Workflow builder — the tier control only applies to simple-tool capabilities) and you’ll see the tier card in place of the old security-level radio. Each tier’s proof requirement is folded directly into its row, so you can see what read, act, and transact each demand without leaving the card. That policy is built into the platform and isn’t a setting you can edit — the card is documentation of the rule, not a configuration surface.

Pick a tier, and the rest of the editor reacts to it: act and transact tiers surface the ownership and subject-binding requirements described below; read tiers don’t need them at all.

The publish checklist

Saving a capability and publishing it are two different actions. You can always save your work-in-progress. Publishing — making the capability live for the Agent Stack to actually call — is gated by a checklist that both the editor and the server evaluate, and the server’s verdict wins if they ever disagree.

The checklist covers every precondition a capability needs before it can go live:

• Name — the capability has one (a nameless capability explains why it can’t publish rather than attempting a doomed save)
• Tier — a tier has been chosen, not left over from migration
• Connection + endpoint — the capability points at a working connection and endpoint
• Usage guidance — there’s guidance describing when the Agent Stack should use it
• Command config — the underlying command/tool is fully configured
• Subject binding — required for act and transact; whose account this runs as is set on the connection
• Ownership rule — required for act and transact; how the platform confirms the customer owns the resource being acted on (or an explicit acknowledgment that there’s no resource to check)

Each unmet row shows a Fix this link. For most rows, that scrolls you straight to the relevant field in the editor — the “which field is the customer?” question, for instance, is authored inline beside the ownership card, so fixing it doesn’t eject you into a different screen. For a capability wired through an MCP connection, Fix this instead routes you to the connection’s configuration pane (saving your draft first, so you don’t lose it).

Only act and transact capabilities are blocked from publishing without a green checklist — read-tier capabilities have nothing in the list that applies to them. And the ownership row includes an explicit exemption for capabilities that genuinely touch no per-customer resource; taking that exemption is a deliberate choice, and the checklist names what it means rather than letting it read as a silent bypass.

Subject binding, on the connection

Subject binding answers a different question than the tier does: not “how risky is this action” but “whose account does it run as when it executes.” It’s a first-class, editable card on every connection type now, not something buried in an auth-mode dropdown. An act or transact capability can’t publish until the connection it points to has this set — the checklist’s subject-binding row is really checking the connection, not the capability itself.

If you repoint a capability at a different connection, the enforcement level is re-derived automatically. That re-derivation only ever raises the effective level, never lowers it — a repoint can’t accidentally weaken enforcement that was already justified by evidence on the old connection.

The Verification tab and reveal posture

Alongside the capabilities list, the Verification tab now holds both tenant-wide verification behavior and the reveal posture for unverified visitors. Reveal posture still controls what a chat or voice agent is allowed to tell an unverified customer about capabilities and verification itself — not what the agent can do (that’s governed by tier and subject binding), but what it can say while the customer hasn’t proven who they are yet.

• Strict (default) — The agent doesn’t name mechanisms or list capabilities the caller can’t yet reach. It stays vague about what’s available until the customer verifies.
• Assisted — The agent can be more specific — for example, revealing a masked destination for a one-time code — to help a genuine customer verify faster.

Any stack that still has a legacy “middle” posture stored reads as strict — there are only two real options now. The posture is applied consistently on every unverified turn, on both chat and voice, and voice never names the underlying verification mechanism even under the assisted posture. It also applies on the login-withheld path, and the pre-verification promise the agent makes to a caller no longer lists capabilities that channel can’t actually reach — so a voice caller isn’t told about something they’d only ever be handed off for anyway.

The same tab also manages verified visitor sessions for web chat. From Settings → Verification, you can generate or read the signing key used to sign visitor identity tokens, and configure the trusted origins that are allowed to present those tokens. Once a visitor is verified, that identity applies across the conversation for the tenant scope; it is not tied to just one connection or one individual capability call.

Keep the signing key out of anything you ship to the browser. Customer-facing installation snippets live under Web Chat → Installation, and those snippets do not include the secret. The secret belongs on your server, where you sign the visitor session before the chat client receives it.

Reveal posture and verified visitor-session settings are settings-level permissions, not something any team member can flip: changing them requires the same access as managing Agent Stack settings generally.

Troubleshooting from the Agent Stack

The Agent Stack surfaces the other half of the picture: which capabilities are actually reachable, and by whom. Each capability shows a TierBadge for its tier, and a capability still carrying a legacy stored level renders honestly as “Legacy level 1 — retired” rather than implying it’s open to anyone.

The Used by column shows which specialists in the stack currently have a capability assigned and reachable — respecting whether the runtime can actually call it and whether it’s enabled — pulled from a tenant-scoped assignments list. A capability showing Not assigned links you straight to the Agent Stack so you can add it to a specialist; from an agent’s own tab, the same link runs in reverse, back to the capabilities list.

Between the tier card, the publish checklist, and Used by, you have the full loop: a capability can’t publish without the right binding and ownership rule, and once published, you can immediately see whether any specialist has picked it up — instead of discovering a published-but-unassigned capability the hard way, from a customer report.