Architecture of the Pulse Framework

Continuous Authentication & Identity Assurance — Component Architecture and Design Rationale

Philosophy

Authentication is an event. Trust is a long-term, continuously evaluated session state. Securing the session is the objective, securing authentication is only one part of doing so.

This principle underlies every design decision described in this document. Pulse does not treat login as the finish line; it treats login as the first of many checkpoints in a session that is monitored, scored, and enforced against, continuously, until logout.

Core Principles

Identity is a core principle of Pulse architecture.

• Identity originates from the human user, represented by a combination of behaviors and knowledge and their possession of a phishing-resistant device, both attested to as part of a single registration process.
• User identity is affirmed by verification of their behavior-based PIN and their physical possession of the registered phishing-resistant device. Together, though attested to separately, they form a trust bond on which the rest of the Pulse framework relies.
• User identity becomes an immutable fact, with reassurance of it provided on a continuing basis.

End-to-end trust is also a core principle.

• Every endpoint within the framework is cryptographically assured by phishing-resistant FIDO2 and/or a demonstrated proof-of-possession using OAuth 2, each verified as a condition of exchange.
• Payload encryption using post-quantum cryptography is employed in all TLS exchanges between framework endpoints.

Extending the identity model:

• Cryptographically coupling user identity to that of the agent.
• Providing accountability based on those cryptographic identities.
• Doing so by monitoring user identity trust scores:
  • User identity itself
  • User presence and participation
  • User proximity to agent activities
• Localized AuthZEN provides agent-level monitoring.

The Problem with Today's Security

Every organization that provides access to digital services faces the same hidden vulnerability: authentication happens once, at the point of login, and then stops. From that moment on, whether the session lasts 10 minutes or 10 hours, the system has no reliable way of knowing whether the person who logged in is still the person in control.

This gap is where modern attacks occur: an authorization token handed off to a bad actor following a successful MFA login, stolen credentials used mid-session, a device handed to an unauthorized person, an employee moving to an unexpected location, a compromised phone that continues to hold active access tokens. Traditional security tools have no answer to any of these scenarios once the login ceremony is complete.

As AI-powered automation becomes central to enterprise operations, the stakes increase further. AI agents frequently run for hours without direct human interaction, making decisions and accessing sensitive data on the user's behalf. Worse, the agentic sub-tasks they spin off inherit that same access, often without equivalent accountability or awareness. A compromised session that feeds an autonomous agent can cause far greater harm than a compromised human session alone.

These aren't hypothetical risks. The 2024 discovery of 17 billion stolen session cookies exposed session hijacking as an attack class in its own right; by 2025 it was behind 87% of successful attacks that followed a valid MFA login. In November 2025, exploitation of Gainsight's OAuth integrations compromised 200+ Salesforce customer environments, not because anyone's login was compromised, but because nothing was watching what happened after it.

Architecture Diagram

FIGURE — Pulse CA with Reflex, Architectural Overview

Auth, Pulse API, OIDC, and OAuth 2.1 orchestrating Reflex's boot and identity services across tenant endpoints.

The diagram shown here is an architectural view of Pulse and all its components; each is briefly described here, with more depth later in this document:

• Auth, the authenticator and source of continuous-monitoring metrics, an app on the user's cell phone.
• Pulse API, the cloud service responsible for orchestrating all other parts.
• OIDC, the OpenID Connect provider service (a SAML provider is also available).
• OAuth 2.1, an implementation of OAuth 2.1 with extensions.
• Reflex, a two-part endpoint security service installed on tenant endpoint devices.

Legend:

• DPoP-secured WSS Pub/Sub channels exist between the API and each component.
  • Connection not shown for OAuth 2.1, to reduce picture clutter.
  • Special note for Auth, where its use is limited to active continuous-monitoring sessions.
  • Pub/Sub terminology means a publisher-and-subscriber service in which the API is always the publisher.
• Notification channel, a subscription message notification service.
• SIEM out, sends logs to tenants electing to receive them.
• Pulse CA components.
• Reflex endpoint service, optional components installed on one or more tenant endpoint devices.

Architectural Objectives

Legacy IdP and IAM solutions date to a time when a “detect and report” philosophy was considered good security hygiene. Pulse CA aligns with a present-day “detect and prevent, and report too” philosophy. It is a subtle distinction, but one worth deliberate consideration in any evaluation of the architecture.

Historically, moving to a detect-and-prevent posture meant choosing between two unattractive paths: patch and pray, or rip-and-replace an existing IdP/IAM investment. The Pulse architecture offers a third, more attractive option, retain the existing IdP/IAM investment and add a Pulse-like continuous-monitoring layer alongside it.

The Pulse architecture is designed as a unified authentication, identity assurance, and session security platform that continuously establishes, evaluates, and enforces trust throughout the lifecycle of every authenticated session. The architecture targets two deployment models built from a common set of components:

• Principal Identity Provider (IdP), deployed independently, alongside an existing IAM, or behind an existing IAM.
• Add-on security service, deployed alongside an existing IdP or IAM service.

Architectural Principles

• Unified components by design
• Integrated by design
• Standards-based wherever practical
• Standards-aligned where no applicable standard exists
• Secure-by-design, using established industry best practices
• Engineered through automated verification and secure development practices

Identity and Trust Objectives

Pulse provides continuous assurance of:

• User identity
• Device identity
• User presence and engagement
• Session integrity
• Full session accountability and auditability
• Dynamic trust evaluation throughout an authenticated session
• End-to-end, login-to-logout phishing resistance

Operational Objectives

Alongside enterprise-grade security, Pulse is designed to deliver and maintain:

• A frictionless user experience
• Simplified integration for relying parties
• Ease of deployment and operation
• Scalable, standards-based interoperability
• Flexibility to meet differing client needs

Component Architecture

The figures below introduce the Pulse component set and its two supported deployment models.

Pulse as the Principal IdP Provider

As the Principal Identity Provider and Continuous Authentication (CA) and Identity Authorization service, Pulse provides phishing-resistance enforcement for both authentication and session monitoring:

• Auth app's Multi-Factor Authentication (MFA).
• Connect, Pulse's OIDC provider service, enhances security by detecting and neutralizing device-code phishing attacks and by including:
  • Device-bound WebAuthn-compliant FIDO2 assertions, augmented with Auth's PIN-behavior-based identity assertion, or
  • Passkey FIDO2, augmented with Auth's PIN-behavior-based identity assertion.
• Step-up authentication, triggered by the Policy Enforcement Point (PEP) service of OIDC or Reflex (configuration-dependent) and fulfilled by the Auth app on the user's cell phone device.

FIGURE 1, Pulse as the Principal IdP

Auth, Commander, and Connect (SAML / OIDC) surrounding the Pulse API hub, with User Access Device(s) running Reflex.

** Work in progress — completion targeted Q4 2026

Component Summaries, Principal IdP Configuration

Pulse as an Add-on Security Service

As an add-on Continuous Authentication (CA) provider service, Pulse operates in parallel with an existing IdP or IAM, which retains primary responsibility for identity and user authorization. Important characteristics include:

• Pulse as an add-on is compatible with virtually every type of IdP or IAM deployment. A list of known-compatible deployments is available on request.
• The internal Pulse OIDC provider service is available to the relying party for general session management.
• The internal OIDC provider is used in headless authorizations to create CA tracking and authorizing sessions.
• The example configuration shown in Figure 2, aligned with Cisco Duo, illustrates a realistic deployment, it does not imply an exclusive or required pairing.
• The example configuration has a mobile-device dependency, shown also hosting the Pulse Auth sensor and authenticator app. Where the aligned third-party product does not require a mobile device, the user must still have a personal cell phone, or be issued one by the relying party, for Pulse CA to function.

FIGURE 2 — Pulse CA as an Add-on — Example Alongside Cisco Duo

Pulse CA (Auth, Pulse API, OIDC Provider, Reflex) alongside Cisco Duo Cloud and a third-party IdP/Directory.

** Work in progress — completion targeted Q4 2026

Discovery Sequence

Discovery of a cell phone device's near-proximity to its user depends on each of the following steps, in order:

• Reflex knows the username of the cell phone device's user, and transfers that as part of a proximity random-nonce token request to the Pulse API.
• Pulse API discovers and accesses the username database record, retrieves the user's cell-phone FCM address, and formats and transmits a single FCM data-only message containing Reflex's request to the device.
• Auth receives and promptly acts on that notification message, translating the provided token to UUID format and publishing it as part of a BLE advertising session.
• Reflex detects the BLE advertisement by UUID recognition or timeout, produces a metric indicative of its findings, and forwards that metric to Pulse API for promotion to monitoring endpoints.
• Reflex ends the proximity-detection session by transmitting an end-advertisement request to Auth via Pulse API, using similar exchange methods.

Securing the proximity-request exchange is indicated in the diagram at Figure 3, below.

Three Foundational Cornerstones of Pulse CA

Phishing Resistant, from login to logout, AiTM Avoidance, by design, Attack Pattern Focus attention to details

1. FIDO2, the Bedrock of Phishing-Resistant Authentication

The Pulse OIDC provider only supports login using Auth or Passkey. Both are FIDO2-compliant. Pulse also recognizes that any generally available human-to-machine (H2M) authentication endpoint remains susceptible to phishing attack, which is why Pulse additionally relies on FIDO2 for:

• Device Cryptographic Assertion (DA): an out-of-scope application of FIDO2 in which its cryptographic capabilities are used without a user gesture, which is unnecessary where DA is applied. In Pulse documentation this is referred to as FIDO2 DA. Specific claims of use:
  • Based on FIDO2 cryptography
  • Adopts the FIDO2 attestation ceremony
  • Adopts the FIDO2 assertion ceremony
  • Does not support user gesture or user verification (UV)
  • Is not FIDO2-certified

2. TriNet, the Original 3-Point Security Assurance Methodology

Triad Security Network (TriNet) is a network-security architecture similar to the caBLE (cloud-assisted Bluetooth Low Energy) approach announced by Google in April 2019, but conceived and patent-protected four years earlier. Figure 3 shows an application of TriNet, employed by Reflex to actively verify the near-proximity of a specific cell phone and its user.

Components

• Reflex — installed on the user's access device; one of its responsibilities is detecting and verifying near-proximity of a specific cell phone device and its user, and reporting metrics indicative of its findings.
• Pulse API — the intermediary responsible for transferring a Reflex proximity-check request to a specific cell phone device, and for receiving metrics input and disseminating it to Pulse's monitoring endpoints.
• Auth — the Pulse authenticator app, responsible for receiving and forwarding a UUID token via BLE advertisement from its device's BLE controller.

Dependencies

TriNet has two critical dependencies, both user-controllable and either of which could be disabled. User education on these requirements is out of scope for this document.

• Bluetooth Low Energy (BLE) availability is required on both the user's cell phone device and the access device on which Reflex is deployed.
• FCM/APNS push messaging must be enabled.

FIGURE 3 — TriNet Active Proximity Verification

Auth ↔ Pulse API ↔ Reflex exchange showing FCM (encrypted payload), BLE-UUID, and WSS (encrypted payload) legs.

** Work in progress — completion targeted Q4 2026

3. Basis of Trust & Policy-based Decision and Enforcement

Pulse CA's source of trust originates mainly in the Auth app on the user's cell phone. Other inputs originate within the API, OIDC, and Reflex: metrics from OIDC and the controllers within API, as well as from Reflex as the source of truth for the active-proximity metric, are added to the trust score package as it passes through the API.

The flow progresses from API to Reflex's AuthZEN service. Configured policies are applied to the metrics by the Policy Decision Point (PDP), creating trust scores. Trust scores proceed from the PDP to the Policy Enforcement Point (PEP).

Not shown, but also provided, is the streaming of trust-score metrics and associated decisions to the API's SIEM interface, for forwarding to any configured logging endpoints.

Metrics from Auth are updated every 30 seconds. Availability from the PEP and AuthZEN is on a millisecond scale, with a staleness possibility of up to 29 seconds.

FIGURE 4 — Basis of Trust & Policy-based Decision and Enforcement

Trust-score flow from Auth, OIDC, API, and Reflex metrics, through the PDP, to the PEP.

** Work in progress — completion targeted Q4 2026

Threat-Class Map

An architectural intent is that Pulse will detect and prevent, or notify on, potential security events, or block their occurrence altogether. It's been suggested that OAuth app consent phishing is impossible to prevent, by those unaware of Pulse's architecture.

An explicit map of well-known attack classes addressed by Pulse, applicable both when deployed as the primary identity provider and when used as an add-on to an existing IdP or IAM. Each class is stated plainly as in scope by design, out of scope by design choice, or in scope pending further work — so that a reader does not need to reconstruct the position by cross-referencing separate documents.

Architecture Narrative

Design Goal Statement — Pulse Framework Overall

Architecturally Pulse is as effective at securing sessions in general as it is at securing AI agent sessions. No matter the session's purpose, by definition a session begins with authentication as part of login and extends to logout. Its focus is on that simple truth. While below we discuss AI-centric features such as AuthZEN, the more general security features are equally important. In that regard then:

Core Principles, Pulse Framework

• Pulse API registration is obligatory for all Pulse framework elements:
  • As part of the Auth app installation and registration; and
  • As part of instantiation of each framework element, including:
    • OIDC
    • SAML
    • Reflex
    • Tenant Dashboard
    • Admin Dashboard
    • Diagnostic Dashboard
• Phishing resistant authentication is mandatory:
  • Provided by Auth FIDO2 authenticator for login to both OIDC and SAML.
  • Provided by Passkey authenticator for login to OIDC (user's choice).
  • Provided by Auth for all step-up re-authentication ceremonies.
• Pulse API requires phishing resistance at every human-to-machine boundary:
  • For Auth, phishing-resistant FIDO2 registration as part of app registration;
  • For all others, phishing-resistant FIDO2 DA registration on first instantiation of services during the element registration ceremony, including OIDC, SAML, and OAuth 2.1 providers, Reflex, and all dashboard tools; and
  • Use of phishing-resistant DPoP (Demonstrating Proof of Possession), RFC 9449, for all messages originating in all Pulse elements, including OIDC, SAML, and OAuth 2.1 providers, Reflex, and all dashboard tools.
• Use of Mutual TLS (mTLS) is required by all elements except Auth for messages that originate from the element.
• Notification message handling by Pulse API:
  • Delivered over FCM for Auth; and
  • Delivered over WSS for all other elements.
• Payload encryption is enforced by Pulse API for all exchanges between it and Auth, Reflex, and all dashboards.

Design Goal Statement — Pulse AuthZEN Enforcement Engine

Purpose

Pulse is not an inference engine that happens to touch policy — it is a policy enforcement engine that may use inference as one input among several. That distinction determines everything about where authority lives in the system.

Core Principle

Protocol compliance is not authorization. That AuthZEN permits a request to be structured and transmitted says nothing about whether a human or their employer actually wanted that action taken in that moment. An AI process can infer intent, but inference is a guess — however well-informed — not a decision of record. Pulse exists to close that gap: to ensure consequential actions are gated by an authoritative decision outside the AI's own reasoning, not by the AI's confidence in its own judgment.

Design Goals

• 1. Decision authority lives outside the AI process. The AI may request evaluation and supply context, but it does not compute, interpret, or apply the policy decision itself. The evaluator is a separate, authoritative component the AI cannot reason its way around.
• 2. Enforcement sits at the resource, not in advice. The evaluator must sit at the same layer as the protected action (the AuthZEN server, the API gateway, the resource owner). A judgment the AI can bypass by calling something else directly is not enforcement — it's a suggestion.
• 3. Fail-closed by default. Any failure to obtain a clear, timely decision — timeout, outage, malformed response, ambiguous state — is treated as a denial, never as permission to proceed. Uncertainty blocks; it never waves through.
• 4. Independent, tamper-resistant record of decisions. The evaluator logs its own decisions. The system of record does not depend on the AI's self-reported summary of what happened.
• 5. No path from “judgment” to “override.” Where a hard stop applies, it terminates the flow unconditionally — no retry-around, no partial continuation, no downstream step that can fire once state is marked blocked.
• 6. Metrics are the source of knowledge AuthZEN operates on. Auth is the primary source of metrics, though other Pulse components also produce metrics as part of endpoint and operational monitoring. Core metrics from Auth deal with user identity and user-device (cell phone) identity. Of the available metrics, the one of central interest must answer: is the user recognized, present, and engaged? An identity composite is derived from an amalgam of user and device assertions, combined with device proximity (both passive and active) and adjusted by metric aging, to address a query such as the following:

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "resource": {
    "type": "identity",
    "id": "metric"
  },
  "action": {
    "presence": "is_present"
  },
  "context": {
    "source": "pulse_auth"
  }
}

The evaluator's rule and policy schemas that back this query are structured as follows:

Rule schema

{
  "principal": {
    "type": "User",
    "id": "alice@example.com"
  },
  "action": {
    "type": "Action",
    "id": "is_present"
  },
  "resource": {
    "type": "Identity",
    "id": "metric"
  },
  "context": {
    "source": "pulse_auth"
  }
}

Policy schema

{
  "PulseAuthApp": {
    "entityTypes": {
      "User": {},
      "Identity": {}
    },
    "actions": {
      "is_present": {
        "appliesTo": {
          "principalTypes": ["User"],
          "resourceTypes": ["Identity"]
        }
      }
    }
  }
}

Deployment Modalities

Different modalities serve different tenant needs.

Pulse Component Specifics

Pulse API

The Pulse cloud-based API service, providing special-purpose controllers.

• Common to all controllers
  • User authentication using Auth on all user-initiated pathways
  • Encrypted payloads used on all API exchanges, bidirectional
  • OAuth 2 with proof-of-possession employed throughout
• API Controller
  • Primary application interface
  • Routes assignments to other controllers on behalf of applications
  • Implements the WSS Pub/Sub head-end service
• Auth Controller
  • Supports all Auth-related requirements
  • Includes FIDO2 client service
• Admin Controller
  • Provides administrative support
  • Maintenance and monitoring
• Continuous Authentication Controller
  • Provides overall orchestration of continuous authentication sessions
    • CA sessions are initiated by OIDC and then transferred to this controller
    • Operative in both foreground and background
    • Operative in both foreground and background
    • Merkle Tree Management providing hash tree accountability

Auth

Cell-phone multi-mode application.

• Operative in both foreground and background
• Authenticator mode
  • Acting as the primary FIDO2 authentication provider
  • Acting as an auxiliary provider alongside a primary authenticator (Passkey, Passwordless Push, etc.)
• Continuous identity provider
  • Human-in-possession detector
  • Behavior-based PIN-code keypad sensor
  • User identity, device, and session-integrity monitor, as individual trust scores
    • 2D location, GPS
    • Elevation, barometric altitude
    • 3D Location, a composite of 2D location and elevation
    • Device motion
    • Human-in-possession detection
    • User behaviors
    • Passive proximity detection
    • Identity-recognition probability
    • Device health
    • Session health, from the cell phone's perspective
• Millisecond or sub-millisecond metric access, with a 30-second worst-case aging window
• On-request Bluetooth advertising of a unique UUID (Figure 1, red line)
• FIDO2 authenticator, based on the Level-1-certified SoloKey SDK
• Firebase Cloud Messaging
  • Receives and posts messages for human consumption, with encrypted token verification
  • Receives and processes encrypted data messages
• HTTPS/WSS, with the WSS channel using ML-KEM-derived AES-256-GCM session-key encryption
• Default use of FCM or APNS notification messaging is a design goal: it enhances security posture, improves messaging timeliness, and is familiar to users. The consent-phishing / push-fatigue downside of this requirement is mitigated as described in the Threat-Class Map, above.
• Authentication ceremony is secured using FIDO2 WebAuthn-compliant controls.
• Within a Continuous Authentication (CA) session:
  • As the source of the phishing-resistant metric stream sent over the HTTPS/WSS channel to the cloud API service, employing DPoP proof (OAuth 2 Demonstration of Proof-of-Possession), a.k.a. mTLS within a JWT.

Connect

Implementations of tightly integrated, well-known session providers.

• SAML provider — an implementation of the ComponentSpace SAML 2 SDK; fully integrated and maintained, offered as an optional service.
• OIDC provider — an implementation of ComponentSpace OIDC 1.0 / OAuth 2.0; integrated and maintained as a standard Pulse component.
• OAuth 2 provider — an implementation of OAuth 2.1 for internal use only.
  • Operates as DPoP Authorization server for all internal dependencies.
  • Provides headless authorization (username provided by caller).
• Provider out-of-scope extensions, with the addition of security features such as Continuous Authentication and Authorization:
  • Each, where needed, uses OS security services for store and retrieval of sensitive content (private keys)
    • Uses FIDO2 DA for private key storage.
  • Each provider implements a phishing-resistant cloud API connection over the HTTPS/WSS channel to the cloud API service, employing DPoP proof (OAuth 2 Demonstration of Proof-of-Possession), a.k.a. mTLS within a JWT.
  • Each provider employs FIDO2 DA (Device Assertion) for all out-of-band (WSS) exchanges with the cloud API:
    • Registration attestation on session start
    • Assertion challenge / response — challenge follows registration; assertion response on each subsequent exchange; rechallenge with a new nonce occurs randomly throughout the session
  • OIDC Provider, as an IdP extension, supports only FIDO2 authentication:
    • Auth FIDO2 by default, providing full MFA compliance
    • Passkey as implied MFA, user / RP choice (Auth identity assertion is optional)
• Where used (OIDC and SAML)
  • Pulse as IdP of choice: either or both protocols can be used, at the relying party's discretion
  • Pulse as an add-on extension to an existing IdP or IAM: SAML is not available; headless OIDC is used by Reflex (see below)

Reflex, An Endpoint Security Service

Reflex is the endpoint security component of the Pulse CA framework, closing the loop from user to endpoint and back. It isn't meant to replace existing identity, endpoint, or edge security solutions, which remain essential. Identity platforms verify who a user is and whether a device looks trustworthy at the moment of access, and endpoint tools watch for threats on the device, but neither ties what happens on the endpoint afterward back to the identity performing those operations. That is what Reflex does.

For most identity providers, security coverage ends when the authentication ceremony completes. From that moment on, the system simply assumes the human who logged in is still the one in control, and risk grows with every minute that assumption goes unchecked. Pulse and Reflex begin where that assumption ends, continuously verifying the authenticated user’s presence and authorization from login to logout. That human-centric focus is also a deliberate boundary: for Reflex, there's no distinction at the device level, but rather at the process level. Thus, from its point of view, there's little distinction between human-to-machine and machine-to-machine environments.

Common continuous monitoring practice is to monitor, detect, and report and Pulse is no exception, it monitors, detects, and reports; Reflex closes the loop by reacting to exceptions with policy-based pause, step-up, terminate, or resume the process as the human's presence is lost, or reaffirmed. In doing so it extends the Pulse repertoire to monitor, detect, prevent, and report.

The Reflex Architecture

An installable package with two background service components:

• The persistent boot service, started at OS system start; and
• The transient client service, started either by a user login event, or by the boot service on detecting the start of a process of interest.

The client service is transient: its beginning and end align with those of the root process it is assigned to monitor, and it follows that process's descendants. Key to Reflex is the process. Every running entity in the system belongs to a process with a unique identity (its process ID and start time). Reflex links every process of interest to a human responsible for the task assigned to it. A process of interest comes into existence in one of three ways:

• Human: through the login ceremony. The client service links the new process to the user who logged in.
• Parent: an existing process creates a child. The client service verifies this is a monitored parent and, if so, chain-links the new process to its parent.
• Decree: a configuration, such as a scheduled task, service unit, or event trigger, creates a new root process with no human lineage. The client service reads the account identifier under which the new process runs and, under policy rules mapping task assignment to a username, links the process to the username responsible for that account.

A process that cannot be linked in one of these ways is an exception, reported and, as policy directs, paused or terminated. In this way, every process Reflex monitors has, at every moment from origination to extinction, a human who serves as its foundation of trust.

Reflex, Trust Model

As a background service, Reflex has no original authentication or login requirement. Rather, it relies on step-up authentication of the user assigned responsibility for the task(s) being performed by the monitored process:

• Explicit Invocation is the result of user login to the local system, the Human class described above. In this instance, the logged-in username performs step-up authentication, thereby becoming the foundation of trust for the new process. The username must be that of a registered Auth app user.
• Implicit Invocation is the result of:
  • Creation by a parent, confirmed to be under monitor, which inherits its foundation of trust as the parent in a tree of two or more processes; or
  • Creation by decree, where the account under which the new process runs, combined with policy guidance, determines the username currently responsible for the new process. In this instance, the assigned username undergoes step-up authentication, thereby becoming the foundation of trust for the new process. The username must be that of a registered Auth app user.

A process for which a foundation of trust cannot be found is an exception, reported and, as policy directs, paused or terminated. In this way, every process Reflex monitors has, at every moment from origination to extinction, a human responsible for it who serves as its foundation of trust.

Reflex, Core Architecture

Pulse CA, like other session monitoring solutions, provides:

• Pulse CA service continuous monitoring → detection → reporting.

Pulse CA, with its Reflex endpoint security component, is unique in providing:

• Pulse CA with Reflex continuous monitoring → detecting → intervention → reporting.

The distinction, intervention, is critical especially where agentic AI is concerned. The more time that passes between a reported incident and intervention, the more critical it often is to minimizing damage. This unique endpoint security is provided by background service modules installed on endpoint devices where critical agentic software services are operating as processes. The process is Reflex's focal point, having the ability to monitor and control its activities.

Core Architecture Features

• Reflex serves dual purposes depending on configuration:
  • Extends the OIDC provider service to include endpoint security when Pulse CA is the IdP of choice.
  • Adds endpoint security to existing IdP or IAM installations when Pulse CA is an add-on extension.
• Packaged as an installable Service for Windows, or Daemon for Linux or macOS environments.
  • Where needed, OS security services are used for store and retrieval of sensitive content (private keys)
    • Uses FIDO2 DA for private key storage.
  • Where needed, Pulse OAuth 2.1, an internal-use implementation, supports headless operations.
• Moderate technical skills with admin rights are needed for installation and configuration.
• Automated boot service completes initialization on system restart.
  • Implements state tracking at startup to distinguish:
    • Unclean-termination recovery reboot, which performs boot service recovery initialization; from
    • Clean-termination reboot, which performs boot service clean initialization.
• Boot service — recovery initialization
  • Logs the fact of, and an unclean recovery of, prior correlation IDs.
  • Continues as a clean initialization.
• Boot service — clean initialization
  • Creates a service identifier from a new GUID.
  • Establishes and maintains FIDO2 DA access to Pulse OAuth 2.1.
  • Establishes and maintains FIDO2 DA access to Pulse API.
  • Registers the service identifier as a Reflex boot service with Pulse API.
  • Establishes a device notification and message channel with Pulse API:
    • Obtains an access token from OAuth.
    • Requests creation of a WSS channel using ML-KEM-derived AES-256-GCM session-key encryption; and
      • Pub/Sub registration for notifications.
  • Creates a secure named pipe, shared by the boot service with all client services.
  • Implements new-process detection and management:
    • Filtering to focus on processes of interest
    • Recovery of the assigned responsible user's username
    • Posting events to the client service based on process parentage
  • Prepares AuthZEN servers for optional use by all monitored processes.
  • Begins the boot service new-process detection task.
  • On reboot, restarts all memorized client services.
• Boot service — new-process detection task
  • Discards the new process if it is of a default system type, or a type specified by policy.
  • Absent policy governance, abandon monitoring if new process has ancestry linage to an actively monitored root process.
  • Using the new process's account information, inspects policy and configuration settings for an assigned user; and
    • If no user is found, logs the event and takes policy-based action to terminate the process or allow it to run without monitoring.
  • Collects the assigned username based on configuration and policy.
  • Spawns a new client service instance, passing the assigned username.
• Automated client service initialization
  • The Reflex client service starts under two conditions:
    • If on behalf of a device login event, in which case the username is obtained directly.
    • On behalf of a new process detected by the boot service, in which case the boot service provides the assigned username.
  • If the new process has ancestry linage to an actively monitored root process:
  • Abandon monitoring if no related policy governance provided.
  • If policy governance applies and the new process exceeds policy limits;
  • Terminate new process, log the event with process tracking information; and
  • Abandon monitoring this process.
  • Verifies user recognition and presence:
    • Retrieves user status, performing step-up if necessary;
    • Verifies device proximity; and
    • Should either fail:
      • Logs the event; and
      • Terminates the process.
  • Creates a cryptographic Session Process Identifier, a SHA-256 hash of the process identifier concatenated with the session identifier, on behalf of the new process.
  • Creates a unique session correlation ID (GUID).
  • As part of registration, establishes and maintains:
    • FIDO2 DA access to Pulse OAuth 2.1, sharing;
    • FIDO2 DA access to Pulse API; and
    • The correlation ID and client service ID with both.
  • Registers the client service identifier with Pulse API as a Reflex client service process.
  • Establishes a device notification and message channel with Pulse API:
    • Obtains an access token from OAuth.
    • Requests creation of a WSS channel using ML-KEM-derived AES-256-GCM session-key encryption; and
      • Pub/Sub registration for notifications and message exchange; and
      • Subscribes to username metrics streams.
  • Creates a headless OIDC session on behalf of the username, with AcrValues set including:
    • Correlation ID;
    • Client service ID;
    • Step-up method, defaulting to Auth;
    • Mode set to Continuous Authentication and Authorization; and
    • OIDC provider AuthZEN and metrics disabled.
  • Begins the root process notification handler task.
  • Begins the root process integrity handler task, on a policy-prescribed duty cycle, defaulting to a 15-minute duty cycle if no rule is specified.
• Client service — root process integrity handler, invoked on the prescribed duty cycle:
  • Performs user presence and engagement checks on each duty cycle;
  • Logs user status; and
  • Takes policy-prescribed corrective action if necessary, to include:
    • Step-up authentication; or
    • Pausing the parent process and all children; or
    • Terminating the parent process and all children.
• Client service — root process exit, crash, or termination by policy
  • Logs the event.
  • Closes the headless OIDC session,
  • Deregisters the client service ID with Pulse API,
  • Unsubscribes from Pub/Sub,
  • Closes the WSS channel, and
  • Removes the entry from the “memorized client services” store.
• Client service — clean device shutdown event
  • Writes the clean-termination flag and gracefully ends active sessions.
• Reflex root process notification handler
  • Processes notifications as received.
• Additional Reflex services
  • Localized configuration setups during installation include:
    • Policies and rule bundles applicable to the PDP and PEP.
• Implications
  • The user may have parallel active sessions to the same or different apps. Each becomes a separate app session associated with the same IdP session. Policy rules can influence how this is handled by Reflex (pause, resume, or end).
  • Single Sign-On (SSO) is handled seamlessly within this architecture, extending the benefits of Pulse CA and Reflex to every SSO branch. The user's application session that began at login is logically joined to the IdP session and so moves as the IdP session does. This is true even where the client has multiple concurrent apps on the same device — for example, an email app running concurrently with an agentic AI app.

Pulse API

The orchestration and coordination component of the framework.

• A cloud service with controllers for:
  • API — responsible for affiliate cloud services
  • Admin — responsible for administrator access
  • Tenant — responsible for Relying Party administration services
  • Auth — responsible for administering Auth app needs
  • SIEM / Logging — responsible for CA logging and outbound SIEM streaming
  • Database — a non-public service responsible to all other controllers
• Architecture attributes common to all or most controllers:
  • A Pub/Sub facility over WSS
  • FIDO2 DA Client, one per controller, responsible for its active channel(s)
  • Compartmentalized for security (lateral-movement reduction)

Endpoint Security

The security model shown here is applicable between all endpoints in the Pulse architecture, securing each API call. It employs OAuth 2.1 and its demonstration proof-of-possession model. In most cases, the Server is the Pulse API while the Client is a registered Pulse endpoint service accessing API resources. One exception worth noting is Reflex, which uses this form of security between its own server and client components.

FIGURE 5 — Demonstrating Proof of Possession

Client and Pulse OAuth Server exchange establishing a DPoP-bound access token, followed by resource-server validation of DPoP proof and token binding on each API call.

Multiuser, Multiple Agent per User, Flow Diagram

Pulse CA configured with its Reflex endpoint background service is an ideal framework for securing AI agents. Architecturally it provides:

• Background service configured to launch on user login.
• On first launch, registers a unique device and configured tenant identifiers.
• Verifies the user's Pulse CA registration (has installed and registered Auth on their cell phone).

While Pulse CA is effective at securing any type of remote user session, it's especially so where AI agents are concerned. Each additional user login spawns a new instance of Reflex. Figure 6 shows the protocol flow in a typical single-user, multi-agent environment. The players in this case are:

• The environment (secured, of course)
• The user, with the necessary access rights and keys
• Pulse CA
  • Cloud OIDC provider service
  • Cloud API service
  • Auth user identity app (cell phone)
  • Reflex endpoint security agent
• A human user (login)

FIGURE 6 — Single User, Multiple Agent Flow

Protocol flow from user login through Reflex session start and continuous trust scoring.

Not shown is user login to the environment using phishing-resistant authentication (Passkey or Auth).

1. The login event launches the Reflex background service, which initializes and begins a new session on the user's behalf.
   1. Creates and pre-registers a device identifier (DeviceID).
      1. On decline, logs, reports, and terminates.
2. From the user, gets their registered username or alias.
   1. Verifies the username provided.
      1. On decline, logs, reports, and terminates.
   2. Establishes internal tracking.
      1. Correlates username to process ID.
3. Completes the device registration process and enters idle monitoring mode.
   1. The user spawns a Root Agent.
4. Continuous authentication and identity monitoring begins with delivery of the authorization token.
5. Within 30 seconds, a first set of trust scores is received with notification, with updates received every 30 seconds thereafter.
6. AuthZEN servers are enabled and available for use.

In this way, user identity becomes the basis of AI agent identity — an association that extends to agent children as they come and go. Along the way, user verification via cell phone notification continues for each new agent, configuration allowing.

Glossary

Terms used throughout this document. Extend this table as new terms are introduced.