Bind stable identities, scope, and consent

Verifiedon 2026-07-302026.7.1

Identity is evidence, not a label

A message can arrive with a friendly display name, a familiar avatar, or a forwarded claim that says “I am the admin.” None of those fields should grant authority. Authentication answers which provider identity produced this event. Authorization answers what that identity may do. Consent answers why this identity is permitted to participate in this particular workflow. Keep the three questions separate.

The exact identity and verification fields vary by Telegram, WhatsApp, Discord, and generic webhooks. Do not copy a provider pattern to another provider. Start from the current OpenClaw documentation index, then read the provider’s primary identity, webhook, permission, and consent documentation for the exact adapter. This lesson’s version boundary is OpenClaw 2026.7.1, revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4, checked 2026-07-30; the examples are synthetic and do not assert that any provider setting is enabled.

Build the allowlist schema

For every test actor, record a stable identifier exactly as the provider presents it, but keep the identifier synthetic in shared course artifacts. Add:

• purpose: why this actor exists, such as support-triage-test;
• source scope: provider, workspace/server, channel, endpoint, or tenant;
• allowed operation: receive, classify, draft, approve, or deliver;
• destination scope: the exact disposable recipient class, not “any channel”;
• consent basis: named owner and the decision that permits this use;
• expiry: a date or event after which the entry becomes hold/drop;
• revocation: the control and owner that removes access;
• evidence: provider receipt, approval record, or test event that proves the binding.

The allowlist is not a secret store. It should contain references and redacted evidence, never access tokens, webhook signing secrets, QR codes, personal phone numbers, customer content, or private invite URLs. Store secrets in the approved secret mechanism; reference them by a non-sensitive label such as secret:test-channel-v2.

Provider comparison without false equivalence

A Telegram bot update, a WhatsApp Cloud API webhook, a Discord interaction, and a generic signed webhook each expose different identity evidence. A Discord display name may change; a webhook signature can prove origin only if the endpoint verifies it; a WhatsApp number may be meaningful only within the correct business account and consent context. Record the provider, scope, verification method, and failure behavior together. “It came from Discord” is not enough to identify the server, channel, actor, or permitted operation.

{
"actorId": "provider-actor-test-17",
"providerScope": "synthetic-workspace/support-room",
"purpose": "support-triage-test",
"allowedOperations": ["classify", "draft"],
"destinationScope": "reviewer-test-room",
"consentOwner": "ops-owner",
"expiresAt": "2026-08-15T00:00:00Z",
"revocation": "disable-route:channel-test-v2",
"secretRef": "secret:test-channel-v2"
}

Notice what is missing: no display name, no token, and no permission to send externally. The identity can enter the bounded workflow but cannot bypass the approval boundary.

Worked example: the name is right, the actor is wrong

The test inventory contains an approved actor provider-actor-test-17 with scope synthetic-workspace/support-room. An inbound event arrives with display name Support Bot, but the stable actor ID is provider-actor-test-91 and the channel scope is missing. A permissive implementation might match the name and process it. A safe implementation evaluates the stable ID first, then scope, then operation. No match means drop and log. Do not ask the actor to “try again” by echoing sensitive policy details into an untrusted channel.

Your decision record should say: reason=identity-not-allowlisted, observedDisplayName=Support Bot only if that presentation field is safe to retain, stableActor=redacted-test-91, action=drop, owner=integration-owner. It should not copy the message body. If the event could be legitimate, the owner may add a new entry after provider verification and explicit consent; that is a new policy decision, not an automatic retry.

Lab: identity and consent worksheet

Create four synthetic rows: an inbound sender, an approval actor, a delivery adapter, and an operator who can disable the route. Give each a different purpose. For every row, answer what it may read, what it may write, what it may send, when it expires, and how it is revoked. Then test these cases:

1. Correct display name, wrong stable ID → drop and log.
2. Correct stable ID, wrong workspace/channel scope → hold for verification.
3. Correct identity, expired consent → hold; never silently renew.
4. Correct identity, approved draft operation, attempted external send → deny because scope does not include delivery.

Expected output: a four-row identity-and-consent worksheet plus four redacted decision records showing the exact stable identity, scope, consent state, policy outcome, and safe next action. None of the records contains credentials or real message content.

Failure cases and rollback

If the provider does not give you a stable identity or verifiable endpoint, stop at the provider-research gate. If an identity is shared by multiple people and you cannot attribute approval, keep it draft-only or introduce a separate approval identity. If a credential is pasted into a worksheet, remove the artifact from shared storage and rotate the credential through the provider’s documented control. If consent expires during a run, hold the work and require a new decision; do not treat a previously approved identity as permanently trusted.

Rollback means remove the pending identity from the test allowlist, disable the route if it was enabled, preserve the redacted denial record, and ask the provider-specific reviewer to capture current evidence. The learner artifact is the allowlist and four decision records. Lesson 3 uses these stable identity bindings to make recipient routing auditable.

Source receipt

Primary source: OpenClaw documentation index. Release context: official OpenClaw releases, verified for 2026.7.1 at revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4 on 2026-07-30. Provider-specific identity and consent claims remain deliberately unapproved until the exact adapter documentation is reviewed.