Separate identities, authority, and approval

Verifiedon 2026-07-302026.7.1

Identity is not intent

Authentication answers who connected; authorization answers what that identity may do; approval answers whether this specific action should proceed now. Keep those questions separate. Consult the current authentication and trusted-proxy documentation before changing gateway controls: reverse-proxy headers are not evidence of identity unless the proxy boundary is explicitly trusted.

Lab — the authority matrix

Make a table with rows for inbound channel, gateway process, administrator, operator, tool/service account, plugin, and reviewer. Columns: can read, can write, can send externally, can change configuration, can approve, and how the action is logged.

For every write, external send, privilege increase, plugin install, or security-control change, choose an approval rule: no approval only for reversible, bounded actions; explicit approval for irreversible, external, or privilege-changing actions. Approval must show the target, data summary, and impact—not merely a button labelled “continue.”

Learner artifact

Capture a redacted approval request showing actor, requested operation, target, scope, expiry, and approver decision. Do not capture message content or tokens.

Checkpoint

A tool has a broad service credential but the chat user is read-only. Is a read-only chat permission enough? No. The effective authority is the reachable tool credential. Narrow the credential, restrict the tool path, or introduce a human gate.

Test

Attempt a safe, non-production action with an unapproved identity. Record the denial and the audit event. If it succeeds, stop automation on that path and open a remediation finding; do not “test” by performing a destructive action.