Authentication, scope, and action authority
Distinguish who is connected from what they may see and do.
Four checks belong at the server
| Check | Question |
|---|---|
| Identity | Which person or integration is making the request? |
| Scope | Which organization, site, records, and operations are in bounds? |
| Current authority | May this identity perform this action now? |
| Prerequisites | Are the required evidence, revision, and review conditions satisfied? |
Give integrations their own identity
Use a dedicated integration identity where supported, with a named owner and a specific purpose. Separate environments and avoid sharing a person’s broad account credentials with automated systems.
Obtain the supported authentication method from the deployment contract. Keep secrets out of browser bundles, source control, screenshots, and example requests. Rotate and revoke credentials through the supported mechanism.
Do not encode approval as a shortcut
A client-side confirmation, a successful login, or an AI client’s tool approval does not replace an operational review required by the workspace. Evaluate the decision against the current record and applicable source revision.
Where independence is required, verify it on the server. A service account should not impersonate a human reviewer or manufacture a signature.
Verify the negative cases
- Cross-workspace record access is denied.
- Revoked or expired authorization cannot complete new actions.
- A stale review context requires refresh or renewed review.
- A caller can retrieve permitted context without acquiring unrelated write authority.
- Logs identify the actor and operation without exposing credentials.