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.
• MCP Server (stdio), provides local MCP clients, including agentic AI frameworks, with authenticated, gated access to cached CA metrics, configuration data, and configurable resource endpoints, all authorized through a composable gate drawing on the full Pulse CA trust arsenal.

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 the registered device identifier and the session identifier delivered with the initialization message. Anchoring the SSDI to the registered device identifier rather than a transient value ensures the session identity falls within the FIDO2-DA envelope and is fully accountable within the Merkle Tree audit chain.

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 form a graduated continuum from least to most disruptive, allowing policy to match the severity of the triggering condition:

• Suspend: temporarily withholds access for one or more endpoint applications pending trust recovery. Reversible within the session when trust metrics return to the required threshold.
• Suspend for Step-Up: a directed suspension that immediately initiates a step-up authentication challenge via the user's cell phone Auth app thus providing both device and identity assertions. Unlike a passive suspension that waits for ambient trust recovery, Suspend for Step-Up actively demands re-verification. The suspended application resumes automatically upon successful challenge completion; failure to complete the challenge within the configured window escalates to Terminate. This is the primary enforcement response when trust has degraded due to a condition the user can actively resolve, proximity drift, behavioral anomaly, or a policy-mandated periodic re-verification requirement.
• Terminate: permanently closes one or more endpoint applications for the current session. The application does not resume until a new authorized session is established.
• Panic & Terminate: immediately forces shutdown of all protected applications and tears down the session entirely. Non-destructive to the OS; the device remains operational but requires full re-authentication, including FIDO2-DA assertion, before a new session can be established. The appropriate response when trust has degraded beyond any recoverable threshold within the session.
• Panic & Reboot: forces an OS-level device restart, clearing all in-memory state and terminating all processes. Stronger than Panic, Terminate: the reboot additionally defeats any in-memory threat that survived application termination. Full re-authentication required on restart.

Panic actions can be triggered through two paths: a PDP push decision arriving over the standard secure policy channel, or a direct administrative signal from the AffirmedID cloud API, the latter enabling immediate response in scenarios such as device reported stolen or credential compromise confirmed, where waiting for a PDP trust evaluation cycle is unacceptable. All panic events generate a dedicated entry in the Pulse CA correlation ID audit log recording the trigger source, triggering condition, action taken, and timestamp, providing a complete and reconstructable record for incident response.

Device-wipe as a panic action is noted as a future extension consistent with MDM deployment contexts. It is not part of the current PEP enforcement model.

The policy configuration governing which enforcement action applies at which trust threshold, and which trigger conditions escalate directly to panic, 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.

MCP Server (stdio)

Sentinel includes a local MCP Server operating over stdio, providing MCP clients on the same endpoint, agentic AI frameworks, IDE extensions, local tooling, with fast, authenticated access to trust data and configurable resources without requiring cloud round-trips. The MCP Server's role is distinct from the AuthZen client: it does not make policy decisions. It serves data and gates resource access based on live trust state, acting as the local trust broker for the agentic session.

Authentication to the MCP Server is automatic and silent. Every client exchange requires a FIDO2-DA assertion from the requesting client, ensuring that only enrolled, cryptographically verified devices and agents can access Sentinel's MCP interface. Unenrolled or compromised clients cannot assert successfully and are denied at the connection layer.

Cached CA Metrics

Sentinel maintains a local cache of core Pulse CA trust metrics, refreshed on an approximately 30-second duty cycle. MCP clients query this cache for near-real-time trust data at localhost speed, current trust score, proximity state, SSDI lifecycle status, device health, and active policy conditions. Each metric response includes a cache timestamp, allowing consumers to factor freshness into their own decision logic. The cache refresh interval is configurable as operational experience accumulates.

Configurable Resource Endpoints

Beyond metrics, the MCP Server exposes a set of configurable resource endpoints that deploying organizations define to match their operational requirements:

• Static key-value pairs (KVPs), configuration-time data such as environment identifiers, API endpoints, tenant settings, or any named value that agents need at runtime without querying the cloud. Defined in Sentinel's service configuration and served from memory.
• Dynamic JSON from file, structured data loaded from a monitored file path, updated between sessions or by administrative action without restarting the service. Changes are reflected within the next cache cycle. Suited to data that changes more frequently than static KVPs but does not require a database.
• File access (future), gated read access to specified file paths, evaluated against CA metrics thresholds at the time of each request.
• Network access (future), gated outbound connection authorization, evaluated against CA metrics before the connection is permitted.

SSDI Permissions and Child Delegation

The MCP Server manages SSDI-scoped permissions for the local agent session. Permissions are initially configured by userid in the Sentinel service configuration, with a path to database-backed user record extensions as the framework matures. Key operations include:

• SSDI status query, the requesting agent's current lifecycle state (Running, Suspended, Terminated).
• Child SSDI spawn, a Running SSDI holding an explicit delegation grant may request creation of a child SSDI. The child inherits a defined subset of the parent's permissions; it cannot exceed them. By default, the permission to spawn further children is not inherited unless explicitly granted, preventing unbounded agent tree depth.
• Permission delegation, a parent SSDI may delegate specific named permissions to an existing child SSDI. Delegation events are written to the correlation ID audit log at the moment of grant, making the permission lineage tamper-evident from root to leaf.

All MCP Server interactions, metric queries, resource accesses, SSDI operations, delegation events, are recorded in the Pulse CA correlation ID audit log, tied to the requesting agent's SSDI and the active session's correlation ID. This produces a complete, reconstructable audit record of every action taken by every agent in the session without requiring any additional log correlation logic beyond the correlation ID itself.

Composable Authorization Gate

Every resource and capability exposed by Sentinel's MCP Server is protected by a configurable authorization gate. Each gate is defined as a named profile in the Sentinel service configuration and assigned to one or more resources. When a request arrives, Sentinel evaluates the gate profile against live cached metrics and the current session state before responding.

Gate profiles are composed from any combination of conditions drawn from the full Pulse CA trust arsenal:

Conditions within a profile combine with AND logic by default; OR logic is available for conditions that represent equivalent trust paths. When a gate evaluation fails, Sentinel returns a structured response identifying which condition was not met and, where the failure is remediable, the remediation path, for example, initiating a step-up challenge. Hard failures (proximity below threshold with no remediation available) are returned as final denials. All gate evaluations, pass or fail, are written to the correlation ID audit log.

Named profiles mean the gate is defined once and assigned to any number of resources. A change to a profile, tightening a proximity requirement, adding a trust score condition, applies immediately to every resource referencing it, without touching individual resource configurations.

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 and extends it into the agentic session. It 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. Its MCP Server makes Sentinel the local trust broker for agentic AI sessions, serving cached CA metrics to local agents, managing SSDI permissions and child delegation, and gating every resource access through a composable authorization profile drawn from the full Pulse CA trust arsenal. Every action, every gate evaluation, every delegation event is recorded in the Pulse CA correlation ID audit log, producing a complete and tamper-evident accountability record from human principal through every agent to enrolled endpoint.

For organizations where session-layer and cloud-side controls are insufficient, where the endpoint itself is a threat surface and agentic AI agents require trustworthy, auditable access control, Sentinel is the mechanism that closes those gaps. 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.