A request to accept work
A partner employee signs in successfully. The case service has checked their identity; it must still decide whether this person may accept this particular handover. The same question applies when software acts through a service account or a tool with delegated authority.
Zero Trust is an approach to access within security architecture. NIST’s model gives no automatic trust solely because a request comes from an internal network or an organisation-owned device. Policy considers the person or service requesting access, the resource, the requested action and relevant context. Authentication checks identity; authorisation decides permitted access. NIST SP 800-207, 2020, sections 2–3.
Decision and enforcement
For the fictional case service, the proposed access record identifies:
- the person or service requesting access, and any delegation;
- the case and action, such as reading selected details or accepting a handover;
- the current role, named receiver, device or workload conditions that matter;
- the policy version, decision and place where it is enforced;
- when permission expires or must be reconsidered, and how revocation reaches the service.
The policy decision and its enforcement are separate responsibilities. They may be implemented within one application or by cooperating services. The diagram shows those responsibilities; the choice of products remains open. NIST also develops service and application identities for distributed cloud applications. SP 800-207A, 2023.
Practical trade-offs
More frequent checks can shorten the time that withdrawn access remains usable, but depend on available identity and policy information. Define which actions stop when that information is unavailable. In this example, accepting ownership pauses if current authority cannot be established. Any emergency access would require a separately agreed, limited and reviewed procedure.
An offline device may hold a permitted local copy, but cannot make a server accept a new action. On reconnection, current policy and case state must be checked. Revoking server access does not erase information already copied; device storage, retention and remote-management arrangements need attention.
A tool that summarises a case receives only the permitted facts for its task. Retrieved text and model output may contain misleading instructions. Neither can grant access or authorise further tool use. The application enforces permitted actions independently of the generated text.
A gradual transition
Choose one useful service interaction, identify who requests access and to which resources, observe current access and test the proposed policy. Introduce enforcement with support arrangements and a recovery plan. Extend it using what the team learns. Include misuse of credentials, policy mistakes and loss of the identity service in the review; a successful login test is only one check.
The worked example joins these access decisions to the wider security controls and unrun checks.