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 (Public / 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 a 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 four tiers
- Public — No customer data — hours, status, FAQ — No proof
- Read — Reads one person’s data — order status, sign-in diagnostics — Verified caller (code to on-record channel, or login)
- Act — Changes one person’s data — send a link, update an address — Verified caller (code to on-record channel, or login)
- Transact — Money — refund, cancel a paid order — Signed-in customer — on a call, handed to a person
Public is the tier stored as the old read value, which is why an existing no-proof capability kept working through the rename; the “Read” row is a separate, verified personal read.
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 call drops it and reports it as human-only 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 a Suggested:
The tier card in the editor
Open a simple-tool capability — anything except the Advanced — workflow builder editor, which has no tier control at all — and you’ll see the Action 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 Public, 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: Read, Act and Transact all surface the ownership and subject-binding requirements described below; Public doesn’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
- Customers can sign in — required when the connection endpoint has a bound customer field; the connection needs a customer sign-in path, such as a login flow, per-customer MCP session key, signed visitor hand-off key, pre-auth session token, or claim-variable mapping. An external customer-login URL does not count — that redirect never calls back to verify anyone
- 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 Read, Act and Transact; whose account this runs as is set on the connection
- Ownership rule — required for Read, 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 button. For most rows, that scrolls you straight to the relevant card in the editor. The customer field and the ownership rule are edited on the connection, so those rows can send you to the connection pane instead, opened on the card that owns the answer; the same is true for every row on a capability wired through an MCP connection, which has no endpoint or binding card on the capability page at all.
The whole checklist has to be green before a capability publishes, at every tier — Public capabilities included. What changes with the tier is which rows appear: name, tier, connection and endpoint, command config and usage guidance apply to everything, while subject binding, the ownership rule and the OAuth rows are only added for Read, Act and Transact. 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. A Read, 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 section and reveal posture
Verification used to be tab 4 of the Capabilities page. It is now its own section in Settings under AI — Settings → Verification — because it governs every conversation on every channel, including tenants that have built no capability at all. (The old /settings/capabilities/verification bookmark still redirects there.) It holds the reveal posture, the signed-in-visitor keys, and the self-service one-time-code setting. Reveal posture controls what a chat or voice agent is allowed to say about the contact channels on a customer’s account before that customer has verified — 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) — Never name a contact channel, on any channel. The agent doesn’t name, read out or hint at any email address or phone number on the account, even masked; if a code is sent, it says only that it went to a contact already on file.
- Assisted — Reveal the masked channel the code went to — “…5206” — so a genuine customer can choose and verify faster. Still never a full number or address.
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 section also manages signed-in visitors for web chat. The Signed-in visitors card lists your connections; Turn on mints a signing key for one, Replace key rotates it and Turn off deletes it. The key is displayed once, at the moment it is minted — “Copy this key now — it is never shown again” — so there is no way to read it back later; if you lose it, rotate. Below it you set the Trusted origins that may present a token over the postMessage hand-off. A visitor signed in this way counts as verified for every connection you have set up that can name them, not only the one whose key signed them.
Keep the signing key out of anything you ship to the browser. The snippet that carries the signed-in visitor lives with the widget, under Settings → Web Chat → your widget → Installation, and it does 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 signed-in-visitor 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 badge for its tier, and one that has never had a tier confirmed reads Needs review rather than guessing. The proof selector beside it offers only the three levels that exist — No proof, Verified customer, Signed-in customer — and a row still holding the retired level 1 reads “Legacy level 1 — retired. Not open to anyone: only a verified or signed-in customer clears it.” 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. Specialists that hold it but can’t call it are listed separately as “assigned, off”. A capability showing Not assigned links you straight to Agent Stacks 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.