Capability security levels
The security level is the enforcement integer every runtime gate reads. You no longer set it directly on a capability: you pick an action tier (Public / Read / Act / Transact) and the level is derived from the tier and from what the capability’s connection can actually ask a customer for. See Capability tiers and verification posture for the tier side of it.
The levels that exist
- 0 — No proof — Open to anyone. No identity gate at all. — The Public tier.
- 2 — Verified customer — A code sent to a channel already on the customer’s account. — Read or Act on a connection Atender can make a scoped call on once the customer id is fixed — an API-key connection, say.
- 3 — Signed-in customer — The customer signed in on the connected system. — Transact, and Read or Act on a connection whose only credential is the customer’s own login (a customer-login endpoint, an External OAuth connection with an authorize URL and client ID, or a per-customer MCP session key).
There is no level 1. It is retired: nothing at runtime grants it, so a capability stored on it could never be unlocked by anybody. Rows written before it was retired still carry it — the agent’s capabilities tab renders those as “Legacy level 1 — retired. Not open to anyone: only a verified or signed-in customer clears it.” and a level 1 written today is clamped up to 2.
There is no supervisor-approval level. Nothing in the capability path pauses an action for a colleague to approve.
Successful capability and tool results can appear in agent debug with size caps and redaction applied; oversized responses are surfaced as tool errors instead of failing silently.
The stored default for a new capability is level 0, and re-deriving after a connection change can only ever raise a capability’s level, never lower it.
A specialist’s Capabilities tab can override the level per assignment — the choices are the same three, No proof / Verified customer / Signed-in customer. One floor applies: a capability that already requires a connection sign-in cannot be overridden below 3, because the execute-time gate reads the blueprint level and a lower override would bind a tool that then rejects every call it makes.
Voice agents execute only level 0 capabilities in the default configuration: the call’s tool binding is capped at L0, because without caller verification a gated tool could only be executed for “whoever dialled the number”. Where the caller-verification and tenant-tools options are enabled, verify_caller lifts that cap and level 2 becomes reachable mid-call — but Transact never does: it is dropped from the call’s tool list and reported as human-only.
Identity verification
The level is the identity gate: it decides whether the capability is bound to the agent at all. There is no separate per-capability list of identity questions — the old identity-fields editor (email / order number / zip code answers matched against your records) was removed along with the L0–L3 radio, and its only writer is gone. What unlocks a level today is one of two mechanisms:
- A one-time code sent to a channel already on the customer’s account, for level 2.
- A sign-in on the connection, for level 3 — the customer-login endpoint, the External OAuth flow, or a minted per-customer MCP session key.
Level 2 capabilities can use an OTP step-up flow, but only on the web chat widget surface. The agent may ask for the customer’s account email before Atender shows the verification-code UI in the widget.
Other surfaces do not render the OTP card. Email, SMS, WhatsApp/Messenger, Slack, in-app help, Testing, and agent inbox/debug surfaces strip or preserve the verification marker safely instead of showing a raw __verification_code_required__ token to the customer or agent.
If an L2 tool is withheld because of an OAuth token or login gate, Atender uses the login path instead of OTP. Level 3 — the top level — remains login/full-auth only.
When a capability is available to the agent, verification has already succeeded and the agent should call the capability directly. When verification is still required, Atender withholds the tool and drives the appropriate verification or login flow instead of having the agent ask for passwords, forms, or auth tokens.
Redaction rules
Redaction masks fields in the response a capability gets back, before that response enters the AI’s context. It is set per capability and per connection, and it works on field paths, not on free-text patterns you write:
- A rule is a simplified dot-path plus a replacement —
$.customer.ssn→[REDACTED]. - You can add extra field names to mask, matched case-insensitively anywhere in the response.
- On top of that, a built-in default pass masks well-known sensitive field names (
ssn,card_number,cvv,password,routing_number,passport_number, and similar) and two value patterns — an SSN-shaped string and a 16-digit card number.
Redaction applies to the response only; there is no rule set for capability inputs. The AI sees the masked form.
How they combine
The tier, the connection’s sign-in method, and the redaction rules are independent dials. A high-stakes capability typically looks like:
- Auth: OAuth2 + External OAuth
- Action tier: Transact (derives level 3, signed-in customer)
- Redaction rules: card number, full bank details
That capability won’t be offered to the agent at all until the customer has signed in on the connection, it is never bound on a voice call, and sensitive response fields are masked before the model sees them.