HEPO's security model connects identity, permitted operations, data access and the account of what occurred. Administrators establish roles and access; implementers verify the operation paths; reviewers examine the evidence relevant to the deployment.
The System security reference explains the shared model. This document provides a more detailed evaluation sequence.
Client and server responsibilities
The client architecture groups its concerns into three layers:
| Layer | Responsibility |
|---|---|
| Preservation | Check identity, session and relevant application-state integrity |
| Prevention | Apply supported input-format, content and business validation before submission |
| Defence | Handle detected problems through appropriate containment, recovery, notification and logging |
Server-side validation and authority remain essential. A field validator or hidden control is not proof that a direct request is protected. The relevant behaviour must be demonstrated on the actual path; a design inventory does not establish that every validator runs on every input.
Roles, permissions and context
Roles group permissions. Permission definitions and supported expressions describe the operation and contextual restrictions. Organisation structure may inform a rule where configured; a change of position is not itself proof that every required permission changed correctly.
Client presentation and server enforcement have different jobs. Shared vocabulary helps them align, but the server must enforce the authoritative decision. Verify allowed and denied requests, including requests made without the intended interface.
Four levels to examine
- Process: may this actor request the operation?
- Step: may the relevant step execute under this context?
- Record: which data may the actor access or change?
- Field: which values may the actor view or modify where field restrictions are required?
Establish how changes or revocation take effect for sessions, cached views and long-running work. Do not assume that every layer is evaluated identically or continuously on every operation merely because the design names it.
Follow the actor and the execution context
The account should distinguish the initiating person, any responsible decision, the process that performed work and any integration credential used for delivery. Scheduled or background operations need an explicit identity and authority model too.
The assistant supplies a way to reach supported retrieval, navigation and operations. Review which functions are enabled and which permissions they require. A confirmation is not a permission grant, and neither substitutes for a human approval required by the process.
Inspect the audit account
Follow representative creation, change, denial, review and external-delivery events. Establish what is recorded about actor, time, operation and outcome. Ask how an authorised reviewer can connect a recommendation to its available basis and a decision to the action taken.
Review actual coverage, retention, access, backup and protection of the stored account. An append-oriented application design does not establish that privileged infrastructure access can never change stored data.
Evaluate deployment assurance
Encryption, key management, support access, retention and recovery need to be assessed for the actual environment. Obtain any required audit, certification or testing reports with their scope and dates. Architecture descriptions alone do not establish certification or satisfy an organisation's complete obligations.
Use two representative roles and include a denied operation, an invalid input, a changed permission and an unavailable dependency. Security Follows the Actor applies these questions to a business decision.