AffirmedID Sentinel

Executive Summary

AffirmedID Sentinel is an installable background service for Windows 10/11, macOS, and Linux that extends the Pulse Continuous Authentication & Identity Assurance framework directly to the user's endpoint. Where the Auth mobile app provides the user-side trust signal and the Pulse PDP provides the analysis engine, Sentinel provides device-side enforcement and verification—the component that closes the loop at the machine the user is actually working on.

Sentinel is an optional component of the Pulse CA framework. Most Pulse CA capabilities operate fully without it. But for organizations that require active proximity verification at the endpoint, device-layer policy enforcement, or phishing-resistant device identity at token refresh boundaries, Sentinel is the mechanism that delivers those capabilities.

Sentinel is also meaningful as a standalone security layer. Several of its functions—persistent device identity, FIDO2 device assertion, and policy enforcement—harden an endpoint against a class of attacks that no perimeter or cloud control can address, because the relevant vantage point is the device itself.

What Sentinel Is

Sentinel is a multipurpose background service with seven distinct functional roles, each contributing independently to the security posture of the endpoint and the integrity of the Pulse CA session:

• Device Identity Service, establishes and maintains a persistent, accountable cryptographic identity for the physical device on which it is installed.
• Cryptographic Session Identity Service, generates an ephemeral cryptographic identifier at the start of each session, binding the device to the active session context.
• FIDO2-DA (Device Assertion) Client, provides phishing-resistant device authentication at token refresh boundaries without requiring user interaction.
• FCM Notification Client, receives and acts upon secure push notifications from the AffirmedID cloud API service.
• Active Proximity Verification Service, actively and continuously verifies that the user's Auth mobile device is physically near the endpoint throughout the session.
• Policy Enforcement Point (PEP), monitors and acts on policy decisions from the Pulse PDP, including suspension or termination of applications on the same endpoint.
• AuthZen Evaluation Client, submits real-time authorization evaluations to the AuthZen PDP extension, acting on results against running endpoint applications.

Device Identity

During installation and initialization, Sentinel creates a persistent GUID-based device identifier. This identifier is bound to the physical device for the lifetime of the Sentinel installation. Accountability measures enforce its persistence across restarts and OS-level events.

The device identifier is the foundation of session accountability within the Pulse CA framework and the basis for interaction with other Pulse services. It is what distinguishes this device, cryptographically and persistently, from every other device in the framework.

Cryptographic Session Identity

At the start of each Pulse CA session, Sentinel generates an ephemeral cryptographic device identifier. This is distinct from the persistent device identity and serves a different purpose: binding Sentinel's participation to a specific session instance.

Generation is triggered by notification over a secure network channel and occurs only upon receipt of instructions from a cryptographically recognized Pulse CA OIDC service provider. The identifier is a SHA-256 or SHA-512 hash constructed as a concatenation of a newly created GUID and the session identifier delivered with the initialization message.

The result is a session-scoped cryptographic identity: unique per session, verifiable by the OIDC provider that initiated it, and structurally tied to the persistent device identity. This pairing—persistent device identity plus ephemeral session identity—ensures that session records are attributable to a specific physical device across the full session lifecycle.

It is through the cryptographic session identity that Merkle Tree accountability for agentic AI sessions is anchored at the device layer. When Sentinel is present on the endpoint hosting an agentic session, the session's Merkle Tree audit chain includes the device-bound cryptographic session identifier, binding the tamper-evident audit record not only to the human ClientMaster and the agent hierarchy, but to the specific physical device on which the session originated. This closes the accountability chain from human principal through agent to enrolled endpoint.

This cryptographic session identity has a formal name within the framework: the Sentinel Session Device Identifier (SSDI). Each SSDI is registered under the session account in the AffirmedID cloud API, with accountability maintained at the OIDC provider—the authoritative center of session awareness across the Pulse CA framework. The first SSDI of any session originates at CA initialization, when the access device's Sentinel service initiates the OIDC provider's authorize function; from that point, the OIDC session carries and manages the SSDI record as an integral extension of session state.

The SSDI structure is designed to support distributed agentic environments. In agentic AI deployments, a session may involve not just the human user's endpoint but one or more AI sub-agents operating on behalf of that user, each running in its own Sentinel-enabled environment. The first SSDI—created by the human user's endpoint—is the root of what may grow into a tree: a root identity plus any number of sub-agent SSDIs, each representing a Sentinel-based environment that has inherited session rights, authorizations, and access. Each sub-agent creates its own SSDI as a concatenation of its device identifier and the parent session ID, then registers it with the API to receive its share of session access. This inheritance-and-registration model is what enables Merkle Tree accountability across the full agent hierarchy: every node in the tree is cryptographically traceable to the root session and the human principal who initiated it.

FIDO2-DA: Device Assertion Without User Interaction

As part of Sentinel installation and initialization, the service registers with the AffirmedID cloud API. This registration is structured analogously to user account registration: it is unique, cryptographically secure, phishing-resistant, and persistently remembered by the API. Registration includes three elements: the device identifier, a FIDO2-DA (device assertion) credential, and an FCM registration identifier.

FIDO2-DA is FIDO2 without the user-presence component. Where standard FIDO2 requires a human gesture—a PIN, a biometric, a touch—FIDO2-DA performs the same cryptographic device assertion silently, as a background service operation. The credential is device-bound and phishing-resistant by the same mechanisms as standard FIDO2: challenge-response is cryptographically bound to the registered device, and an attacker's proxy infrastructure cannot generate a valid assertion without access to the enrolled hardware.

The practical consequence for session security is significant. At token refresh boundaries, the Pulse CA OIDC provider can require a FIDO2-DA assertion from the registered device as a condition of issuing a refreshed token. An attacker who has captured a valid token cannot satisfy this requirement. The token's useful life is bounded by its original TTL, and persistent access through captured tokens is structurally prevented.

Registration Email Address

Sentinel registration with the AffirmedID API requires an email address as part of the registration record, consistent with the API's account model. For a background service, a user-facing email address is not appropriate. Sentinel handles this by requesting that the AffirmedID cloud API generate a unique address at installation time, issued in the form randomname@AffirmedId.com. Generation by the API ensures global uniqueness within the registration namespace. Where operational or administrative requirements call for a specific address—for audit routing, administrative notification, or organizational policy—a preference address can be assigned through the service configuration prior to or following registration.

FCM Notification Client

Sentinel registers an FCM (Firebase Cloud Messaging) identifier as part of its registration with the AffirmedID cloud API. This gives Sentinel the same push notification capability as the Auth mobile app: the ability to receive and act upon secure, unsolicited notification messages delivered from the AffirmedID cloud API service.

Push notifications are the mechanism by which the AffirmedID API initiates actions on Sentinel without polling. Session initialization triggers, proximity verification requests, and policy instructions can all be delivered through this channel. FCM delivery is not guaranteed and carries inherent latency variability; Sentinel's design accounts for this through retry logic and does not treat time-sensitive operations as solely dependent on a single FCM delivery event.

The use of push notification as the initiation channel carries a meaningful security property beyond convenience. Because Sentinel receives instructions rather than polling for them, there is no predictable request cadence for an attacker to observe, anticipate, or exploit. Notification timing is determined by server-side events, making the communication pattern inherently unpredictable from the endpoint's perspective. Combined with the cryptographic validation of the notification source, this makes the channel resistant to timing-based attacks and replay attempts that polling architectures are structurally more exposed to.

Active Proximity Verification

Active proximity verification is a Pulse CA-specific capability that provides a higher-assurance proximity signal than passive Bluetooth detection alone. Where passive proximity monitors signal strength as an ambient indicator of phone presence, active proximity verification initiates a directed, cryptographically distinct exchange with the user's Auth mobile app on a continuous, repetitive basis.

Each verification cycle consists of five steps:

1. Sentinel generates a unique, cryptographically secure 128-bit BLE UUID for this verification cycle.
2. An advertising request carrying this UUID is transmitted to the registered user's Auth mobile device over a secure out-of-band network channel (not over BLE directly).
3. Upon receipt, the Auth app begins advertising the UUID over BLE.
4. Sentinel listens for BLE advertising announcements. Detection of the expected UUID confirms that the user's phone is physically near the endpoint.
5. Proximity metrics are produced and published to the Pulse CA framework, feeding the Active Proximity Trust Score in the PDP.

The two-channel design—instruction over network, verification over BLE—is a deliberate security property. BLE alone is susceptible to relay attacks; requiring the Auth app to receive the specific UUID through the authenticated network channel before advertising it closes that vector. A relay attacker would need to compromise both channels simultaneously to fabricate a valid proximity signal.

Beyond confirming presence, Sentinel uses BLE signal characteristics to estimate the approximate physical distance between the user's phone and the endpoint. This distance estimate feeds into the Active Proximity Trust Score as a graduated signal rather than a binary present/absent result: a phone within arm's reach produces a near-maximum score, with the score degrading incrementally as estimated distance increases. This graduated response allows policy to be tuned to distance thresholds appropriate to the deployment context rather than requiring a fixed pass/fail boundary.

Policy Enforcement Point (PEP)

Sentinel includes a Policy Enforcement Point service that operates as a local enforcement agent for policy decisions issued by the Pulse Policy Decision Point (PDP). Policy decisions arrive over a secure channel from a cryptographically recognized PDP source. Sentinel validates the source before acting on any instruction.

Enforcement actions available to the Sentinel PEP include suspension and termination of applications running in the same endpoint environment. This is the mechanism by which a degraded session trust score—calculated by the PDP based on Auth device metrics and AuthZen evaluations—can result in immediate, local action on the endpoint rather than relying solely on session-level revocation at the OIDC provider.

The distinction between suspension and termination is operationally significant. Suspension is reversible within the session: if trust recovers—including through successful completion of a step-up authentication challenge issued by the Pulse CA OIDC provider—the suspended application resumes automatically. Step-up authentication, initiated via the user's Auth mobile app, is the standard recovery path when trust has degraded to a threshold that warrants suspension rather than termination. Termination is final for the current session: the application is closed and does not resume until a new authorized session is established. The policy configuration governing which response applies to which trust threshold is defined by the deploying organization.

AuthZen Evaluation Client

Sentinel's AuthZen client performs pre-configured authorization evaluations by submitting requests to the AuthZen server extension of the Pulse PDP. Evaluations are applied against a collection of named trust metrics accumulated and updated in real time throughout the Pulse CA session.

Actions triggered by AuthZen evaluation results follow the same enforcement model as the PEP service: suspension or termination of endpoint applications based on the evaluation outcome. The AuthZen client and the PEP service may operate in parallel on the same endpoint; the two are complementary rather than redundant. The PEP responds to PDP push decisions; the AuthZen client initiates evaluation requests on a configured schedule or in response to local events.

The relationship between Sentinel's PEP and AuthZen client, and the potential for overlapping enforcement actions, is governed by configuration. Organizations deploying both should define precedence and deduplication behavior in their policy configuration.

Architecture Summary

Sentinel's components interact with the broader Pulse CA framework through well-defined integration points:

Platform Support

Sentinel is distributed as an installable system service for three platforms:

BLE capability is required on the endpoint for active proximity verification. All other Sentinel functions operate on endpoints without BLE hardware; active proximity verification will not be available in that configuration.

Scenario Comparison

How Sentinel addresses attack and risk scenarios that session-layer and cloud-side controls alone cannot:

Open Design Items

The following items are acknowledged but remain under active development. They are recorded here for traceability between the current specification and the implementation roadmap.

Conclusion

AffirmedID Sentinel brings the Pulse CA trust framework to the endpoint. It is the component that establishes a cryptographic device identity, extends FIDO2 phishing resistance to the token lifecycle, actively verifies the physical presence of the user's Auth device throughout every session, and enforces policy decisions from the Pulse PDP directly on the endpoint—suspending or terminating applications when trust conditions are not met.

For organizations where session-layer and cloud-side controls are insufficient—where the endpoint itself is a threat surface that requires active, continuous verification—Sentinel is the mechanism that closes that gap. It runs silently, requires no user interaction after installation, and operates equally effectively as a Pulse CA component and as a standalone endpoint hardening layer.