Capability security levels
Capabilities have four security levels (0 through 3) that decide how much supervision the AI gets when calling them. Levels exist because not every capability deserves the same trust — looking up your store’s opening hours is one thing; refunding a charge is another.
The four levels
- 0 — No extra approval or identity gate. The AI runs the capability silently, though normal execution and debug traces may still be recorded. — Read-only lookups against safe data: order status, opening hours, public catalogue queries.
- 1 — Logged, but no human approval required. — Most read operations on customer data — looking up the customer’s own orders, account info, invoices.
- 2 — Requires OTP verification before the capability is made available to the agent. — Mutations the customer wants to take but should be gated behind verified identity: cancellations, plan changes, address updates.
- 3 — Requires supervisor approval before execution. The capability pauses; a human in your team has to approve it before the AI proceeds. — High-stakes actions: refunds above a threshold, account deletions, anything you’d want a second pair of eyes on.
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 default for new capabilities is level 0. Raise the level any time the action has real consequences — the cost of an extra confirmation step is far less than the cost of a wrong action taken silently.
Identity verification
On top of the security level, you can require the customer’s identity to be verified before a capability becomes available to the agent. Verification factors can include:
- Email — the email on the customer’s account.
- Order number — a recent order number.
- Zip code — the customer’s billing zip.
- Custom identity fields — anything you’ve stored on the contact record.
Capability security levels control what happens once the agent is allowed to call a capability. Identity verification controls whether the capability is made available to the agent in the first place.
Level 2 capabilities are withheld until the OTP flow completes. The agent may ask for the customer’s account email before Atender shows the verification-code UI.
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 verification flow instead of having the agent ask for passwords, forms, or auth tokens.
Redaction rules
Define patterns that should be automatically masked in capability inputs and outputs. Common targets:
- Credit card numbers
- Social security numbers
- API tokens or passwords leaking through error messages
- Anything matching a regex you specify
Redacted values never appear in logs or in the capability’s execution history — the AI sees only the masked form.
Consent tracking
For capabilities that act on the customer’s behalf (cancellations, subscription changes, account modifications), Atender records the customer’s consent before the action runs. The consent record includes:
- The customer’s identifier
- The capability that was called
- The action that was about to happen
- The customer’s affirmative response
- A timestamp
Consent records are part of your audit trail and can be exported for compliance reviews.
How they combine
Identity verification, security levels, and consent tracking are independent dials. A typical configuration for a high-stakes capability:
- Auth: OAuth2 + Full Access
- Identity verification: email + order number
- Security level: 3 (supervisor approval)
- Redaction rules: credit card numbers, full bank details
- Consent tracking: on
That capability won’t run until (1) the customer proves identity, (2) a supervisor approves, (3) the customer confirms — and even then, sensitive values never reach the logs.