Skip to main content

13. Security and Identity

This section defines how identity, access, and trust are managed across the architecture. Security is applied as a cross-cutting concern without embedding security logic into the DXP or capability implementations.

13.1 Authentication and Authorisation​

Authentication establishes who is making a request; authorisation establishes what they are permitted to do.

Principles:

  • Authentication is performed at the edge
  • Identity is propagated as immutable context
  • Executors do not re-authenticate users

Authorisation:

  • Is evaluated before capability invocation
  • Is based on identity, role, tenant, and context
  • Does not depend on backend system identities

This ensures consistent and centralised access control.

13.2 Capability-Level Access Control​

Access control is applied at the capability level, not the system level.

Capability-level access control:

  • Determines which capabilities and versions a consumer may invoke
  • Applies regardless of execution path or implementation
  • Is enforced consistently through the gateway

Benefits:

  • Prevents accidental overexposure of backend systems
  • Allows fine-grained permission models
  • Supports evolution without reworking security models

Access decisions are explicit and auditable.

13.3 Data Sensitivity and Classification​

All data handled by the architecture is classified according to sensitivity.

Classification:

  • Is applied to inputs, outputs, and persisted artefacts
  • Influences logging, storage, and transmission policies
  • Is propagated as part of execution context

Rules:

  • Sensitive data is never exposed unnecessarily
  • AI-assisted execution respects classification constraints
  • Data handling policies are enforced by infrastructure, not convention

This enables safe operation across mixed-trust environments.

13.4 Audit Logging​

Audit logging is mandatory for capability invocation.

Audit logs capture:

  • Identity and context of the invoker
  • Capability name and version
  • Execution mode and executor identity
  • Timestamp and outcome

Audit logs:

  • Are immutable
  • Are centrally collected
  • Support investigation, compliance, and reporting

Logging is comprehensive but does not leak sensitive payloads.

13.5 Trust Zones​

The architecture defines explicit trust zones.

Typical zones include:

  • User-facing experience zone
  • Capability and gateway zone
  • Execution and integration zone
  • Legacy system zone

Rules:

  • Trust does not flow implicitly between zones
  • Data crossing zones is validated and governed
  • AI-assisted components operate in constrained zones

Trust zones limit blast radius and support defence-in-depth.