Architecture Portal

Security

Permission at the point of use.

Adrian Sutherland · Version 1.0 · · © 2005–2026

BP-V07 (Access and authority) · Version 1.0 · September 2026

Access and authority

Current permission controls each read and action.

Design state
SOFT-01 (Later software option)
Level
Logical
Design
Proposed; checks unrun
Scope
Case reads, acceptance and receipt retrieval
ASAF aspects
Security, Systems, Information

On a small screen, scroll the diagram sideways or read the text description below.

The caller uses a staff client. The case service checks trusted identity, current policy and requested resource before performing the permitted operation. Protected case and receipt records remain behind this decision. A restricted summary workflow reads permitted context and returns a proposal for human review. Security records support authorised investigation.
BP-V07 (Access and authority). Fictional software option; implementation checks are unrun.

Key

  • Groups show where responsibilities differ; being inside a network is not permission.
  • Arrows identify permitted information or actions; actual policy and deployment are still to be selected.

Linked records

Text description

The caller uses a staff client. The case service checks trusted identity, current policy and requested resource before performing the permitted operation. Protected case and receipt records remain behind this decision. A restricted summary workflow reads permitted context and returns a proposal for human review. Security records support authorised investigation.

Access and authority

SEC-A1 (Service authorisation) places the permission decision at the service where information is read or a change takes effect. A request includes a claimed purpose and case reference; trusted identity and current policy establish what the caller may do. A network location, device or earlier successful call does not supply continuing authority. This applies the Zero Trust guidance to the service’s actual reads, transfers and receipt lookups.

A new acceptance checks the intended receiver and current case facts. A retry checks current access before returning the retained receipt. If permission has been withdrawn, the accepted business event stays recorded while that caller loses access to its protected result.

Risks and controls

Risk Control in the proposal Responsible role
SEC-R1 (Excess disclosure) Limit disclosure to the case and fields required; check reads and exports. Information owner
SEC-R2 (Unauthorised acceptance) Check identity, current policy, intended receiver and version when accepting work. Service owner
SEC-R3 (Unsafe summary use) Restrict summary source facts, retained content and tools; check generated text against sources. Application owner
SEC-R4 (Altered records or traces) Protect credentials, records and audit information; separate administration and prepare recovery. Platform and service owners

Likelihood, consequence, remaining exposure and acceptance are open decisions. The wider partner option needs separately agreed disclosure and supplier controls; it is not part of the first process-only trial.

Operation and assurance

SEC-O1 (Security operation record) links actor, action, case, policy decision and result so an authorised operator can investigate. Logs require access and retention controls and should exclude credentials and unnecessary learner content.

An incident owner coordinates containment and business communication. Recovery includes trustworthy configuration, credential replacement where needed and reconciliation of accepted work. Test denied access, revoked permissions, unavailable identity services, unwanted tool actions and damaged records. The security checks are unrun. The security example and recovery view retain the connected details.

About this edition

Refreshed for the September 2026 website update. This edition develops earlier Architecture Portal and ASAF material; the fictional service example was added in 2026.

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

Proposed

Last reviewed

Intended users

  • Architects describing, comparing and adapting an architecture

Non-goals

  • A prescribed product stack or a claim of measured service outcomes

Limitations

  • The service is a fictional design. Its proposed implementation and operational checks remain unrun.

Next evidence sought

  • Apply the views and linked checks to an actual service.