Subscribe to the Non-Human & AI Identity Journal

System of Record vs System of Interaction

A system of record stores the authoritative data, while a system of interaction is where users initiate and manage work. In agent-mediated environments, separating the two can reduce interface sprawl, but it also raises the need for stronger logging, attribution, and control over write actions.

Expanded Definition

A system of record is the authoritative source for business data, while a system of interaction is the user-facing layer where work is initiated, reviewed, and completed. In NHI and agentic environments, that separation matters because an NIST Cybersecurity Framework 2.0 approach expects clear control boundaries, traceability, and least-privilege handling across systems that read, write, or approve data. Definitions vary across vendors when workflows span SaaS, internal tools, and AI agents, so no single standard governs this yet. Practically, the system of interaction should collect intent and context, while the system of record should enforce validation, persistence, and auditability. That distinction reduces interface sprawl and helps keep write permissions concentrated where policy can be enforced. It also supports cleaner attribution when an AI Agent or service account initiates an action on behalf of a human user. The most common misapplication is treating the interaction layer as a safe place for authoritative writes, which occurs when teams let front-end approvals or agent prompts bypass record-level controls.

Examples and Use Cases

Implementing this pattern rigorously often introduces extra integration and governance overhead, requiring organisations to weigh user experience gains against tighter controls over writes, identity, and logging.

  • A ticketing portal lets staff request access, but the identity store remains the system of record for approvals, entitlements, and revocation history.
  • An AI Agent drafts a support case in the chat interface, while the case management platform remains the system of record for status changes and final closure.
  • A customer portal displays account details, but a billing ledger remains authoritative for balances, invoices, and dispute outcomes.
  • A DevOps console initiates deployment actions, yet the CI/CD platform and change log remain the sources of truth for execution and rollback evidence.

For NHI governance, this separation is especially useful when service accounts, API keys, or workflow automations act across multiple tools. NHI Mgmt Group’s Ultimate Guide to NHIs explains why visibility, rotation, and offboarding become harder when identities are allowed to write everywhere, and why authoritative records should be protected from casual interface-layer updates. The same principle aligns with NIST Cybersecurity Framework 2.0, where data integrity and access control depend on maintaining clear protection boundaries.

Why It Matters in NHI Security

When the distinction is blurred, organisations often lose attribution, create duplicate records, and widen the blast radius of compromised secrets. A prompt-driven agent or over-permissioned service account can mutate authoritative data without the review path that a system of record was meant to enforce. That is a direct governance problem, not just a UX issue, because write access in the wrong layer undermines audit trails, incident response, and rollback. It also makes PAM and RBAC enforcement harder, since access policy becomes scattered across multiple interfaces instead of concentrated at the record boundary. The risk is amplified in environments with poor secret hygiene: NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, as documented in the Ultimate Guide to NHIs. That finding is especially relevant when a system of interaction is allowed to act as if it were authoritative. Organ organisations typically encounter the need to separate record and interaction layers only after an erroneous agent write, a secrets leak, or an access review exposes that no clear source of truth existed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AC-4 Access control and least privilege depend on clear record-vs-interaction boundaries.
NIST Zero Trust (SP 800-207) Zero Trust requires verifying each transaction, not trusting the interaction layer by default.
OWASP Non-Human Identity Top 10 NHI-02 Secret and privilege management are central when agents can write to systems of record.

Constrain write actions to authoritative records and review entitlements for each interaction layer.