AffirmedID Pulse CA

Executive Summary

AffirmedID Pulse CA closes session gaps that conventional identity IdP/IAM architectures leave open. Two examples: authentication ends at login, and authorization decisions age out the moment they're made. Pulse CA keeps identity trust live for the duration of a session and feeds that live trust directly into every authorization decision, for human users and, for fully autonomous AI agents, acting on their behalf.

Deployed with its optional Sentinel endpoint service, Pulse CA provides end-to-end closed loop session accountability from login to logout: the identity recognized and verified by Auth on the user's phone is verified to be the same person logged in at the access device where Sentinel is installed, end-to-end, phishing-resistant accountability, not just at login.

Gaps most IdP/IAM solutions leave behind are closed for all authenticated sessions, including agentic AI sessions. By anchoring every session to an immutable authenticated user and continuously verifying that user's presence, proximity, and participation throughout the session, Pulse CA establishes and maintains an immutable one-to-one relationship between the user and the session.

That assertion of user identity is transferred through phishing resistant connections to Pulse API and from there to Connect OIDC provider service and Sentinel access device and its apps and agents. Its a closed loop framework architecture operating as a persistent background service from Sentinel service to Pulse API to Auth and back to Sentinel, one single uninterrupted phishing resistant loop.

Pulse CA deploys in one of two configurations, described in detail below:

• As an Add-on, Pulse CA deployed alongside an existing IdP/IAM fills the gaps it leaves behind, without disrupting that investment or installation.
• As a Complete Solution, with its integrated OIDC/SAML provider included, Pulse CA becomes a complete, session-focused IdP that avoids those gaps entirely while orchestrating the full session lifecycle from login to logout.

The Gaps Pulse CA Closes

These Gaps Are Not Theoretical

Two Ways to Deploy Pulse CA

Pulse CA is architected so the same core, Auth, Pulse API, OIDC, and Sentinel, operates standalone or as the foundation of a full identity platform. Which mode you're in determines what Pulse CA controls directly versus what it hands off to your existing IdP.

Note: only Sentinel is optional in the table above. Auth, the app on the user's phone, is required in every configuration, AI-driven or not; it's the one component with no substitute, since it's the sole source of the live identity signal everything else depends on.

The Trust Signal Layer

Auth transforms the user's phone into a continuous security sensor, streaming live metrics to the Pulse API PDP throughout the session:

• Identity Trust Score, behavioral biometrics confirm the same person remains in control.
• Passive Proximity Trust Score, Bluetooth verification that the phone stays near the device in use.
• Active Proximity Trust Score (requires Sentinel), direct engagement between phone and access device for a higher-assurance proximity signal.
• 3D Location Trust Score, GPS plus barometric altitude; resolves floor-level position, so moving between floors of the same building registers as a location anomaly that 2D geofencing misses entirely.
• Device Health Trust Score, real-time integrity monitoring: jailbreak detection, malware indicators, hijack attempts.
• Session Health Trust Score (requires Sentinel), integrity of the phone's live connections to Pulse API and to Sentinel's BLE proximity responder. This is the score Tri-Net produces (below).

Tri-Net: The Patent Behind Session Health

Most of what Pulse CA claims, continuous monitoring, phishing resistance beyond login, agentic trust propagation, depends on one underlying mechanism: Tri-Net, a three-point trust network formed between the Auth app, the Pulse API, and Sentinel.

Each leg of the triangle independently verifies the others are live and uncompromised, Auth to Pulse API, Pulse API to Sentinel, Sentinel to Auth via active BLE proximity, rather than relying on a single link that, if severed or spoofed, would silently degrade the whole system. This three-point structure is what makes Active Proximity and Session Health possible at all: neither is a single sensor reading, but a cross-check across all three legs of the network, patent-protected as a Triangular Network (Tri-Net) architecture.

This is Pulse CA's hardest-to-replicate technical claim. Competitors can stream a location or biometric signal; verifying that the streaming path itself hasn't been compromised, via a triangulated network rather than a single channel, is the actual differentiator.

Tri-Net requires Sentinel and is therefore available in both add-on and complete-solution modes, but not in a Pulse CA deployment that omits Sentinel entirely.

Dual- and Triple-Assertion Identity

Every Pulse CA session is established through independent identity assertions layered for increasing assurance:

• FIDO2 Device Assertion, cryptographically verified proof of device possession via Passkey or Auth. Phishing-resistant authentication at NIST AAL2.
• Auth Identity Assertion, continuous behavioral identity from the Auth app, live throughout the session rather than a point-in-time check.
• FIDO2-DA (Device Assertion, no user gesture), extends the same cryptographic envelope to endpoint-to-endpoint trust (Sentinel-to-Pulse API, Sentinel-to-Connect, and Connect-to-Pulse API), without requiring repeated user interaction.

Combined, FIDO2 + Auth's continuous assertion step up authentication to NIST AAL3 in a single ceremony, where most solutions require two separate ceremonies to reach AAL3, Pulse CA reaches it in one.

Authorization: AuthZEN and MCP

AuthZEN

When a user, application, or AI agent requests access to a protected resource, the relying party queries the Pulse AuthZEN evaluator endpoint. The PDP evaluates against current trust context, not stale login-time state, and returns Permit, Deny, or Permit-with-conditions (reduced scope, pending step-up). Evaluations target single-digit-millisecond response times, with trust state held in-memory to avoid recomputation at query time.

Pulse CA also inverts the polling model: relying parties register callback endpoints, and the PEP pushes enforcement decisions the moment a trust event occurs, rather than waiting for the next request cycle. For AI agents running for hours unattended, this push model is what makes revocation meaningful in practice rather than theoretical.

MCP

The Model Context Protocol is emerging as the standard interface for agentic tool use. Pulse CA's current MCP support, delivered through Sentinel, is a proprietary implementation following generally accepted methodologies, it is not the OpenID Foundation AuthZEN working group's in-progress COAZ-MCP binding, which remains a Working Group Draft rather than a finished specification.

Agentic AI: Chain of Custody

Every AI agent, however autonomous, was initiated by a human, that origin is the immutable anchor of the agent's authority. Pulse CA enforces this as an authorization property, not just a design principle:

• Every agent session carries the correlation ID of its originating human session.
• If the human's trust score degrades, that signal propagates immediately through the entire agent chain, sub-agents included.
• Sub-agents inherit scoped authorization linked to the same human origin and are subject to the same trust evaluation.
• High-privilege agent actions can require real-time re-evaluation or explicit human confirmation.
• A Merkle-tree audit lineage traces every action, including sub-agent actions, back to a specific enrolled endpoint, verified session, and authenticated human principal.

Rules and Policies

A login-and-forget solution has little need for a policy engine. A continuous solution like Pulse CA depends on one. For this, Pulse CA adopted the Open Policy Agent (OPA) approach, a fit for the management tooling already available to Pulse users. OPA is documented in full at its own site and isn't re-explained here; what matters for this brief is what Pulse CA contributes to it: the metrics the policy runs against.

Most of those metrics originate at Auth, on the user's phone, the best vantage point to detect, gather, and monitor signals of identity, location, and proximity.

Proximity — Passive and Active

Of all the signal sources, proximity is the hardest to establish, and Pulse CA produces it two ways:

• Passive proximity works like passive sonar on a submarine, detection by listening. Auth passively monitors Bluetooth, WiFi, and cellular signals to detect and track proximity without any active exchange.
• Active proximity, active sonar, in the same submarine parlance, is produced by Sentinel, Pulse API, and Auth acting together, in a sequence that proves proximity rather than inferring it:
  1. Sentinel creates a token and sends it to the Pulse API over a secure WSS channel, roughly equivalent to the submarine's active sonar ping.
  2. Pulse API receives and verifies the token, then delivers the request and token to Auth on the user's phone as an FCM push notification.
  3. Auth verifies the token and begins actively broadcasting it over BLE, using the token itself as the advertised UUID.
  4. Sentinel, listening for a BLE advertisement matching that UUID, detects it, verifies it, and closes out the process. Proximity of the user's phone is now proven, not assumed.

Registration

Auth requires registering both the device and the person:

• Device registration follows standard FIDO2 device-bound attestation.
• User registration ties the account to a phone number and an email address, each unique to one user. Email is verified by confirming the phone holder has access to that inbox. Both are stored in the Pulse API user-registration database.

Once registered, Auth is ready to serve as the primary authenticator or as an adjunct that supplies the one thing every authentication scenario is otherwise missing: a live assertion of user identity.

How Sentinel Finds the Right Auth App

Sentinel is configured to launch on the system login event. It reads the username (email address) of the person logging in and sends an identity-verification request to Pulse API, which in turn triggers an Auth login request to that user. If either the database check or the Auth login fails, Sentinel refuses to launch.

Metrics

Policies and rules only have value once given something to evaluate, Pulse CA calls these metrics, and most originate at Auth. Representative examples from the full metric set:

Each metric is paired with a confidence indicator for the score itself.

The actual rules and policies applied to these metrics are written by the Relying Party using tools freely available from OPA. A typical rule looks like:

default allow := false

allow if {
    input.method == "user_identity"
    input.user == session.user
    input.score >= 0.8
    input.confidence >= 0.9
}

Scenario Comparison

Enforcement mechanics differ by deployment mode; scenarios below note where that matters.

Worth being precise about what Pulse CA does and doesn't control here: Pulse CA provides the signaling, from Auth to the Pulse API's PDP, and from there to Connect and/or Sentinel's PEP, but the evaluations the PDP performs and the actions the PEP takes are rules and policy, written in OPA by the Relying Party (see Rules and Policies, above). Pulse CA doesn't dictate what is or isn't acceptable; it provides the mechanism by which the RP decides that for itself. The scenarios above describe what Pulse CA makes possible, not a fixed behavior Pulse CA enforces on its own.

Standards Alignment

Rather than restate compliance bullet points here, we point readers to three vendor-neutral, AI-scorable evaluation frameworks published at affirmedid.com/ciso-tools:

• Eleven Commandments of Agentic AI Security, scores any identity provider's handling of agentic session security.
• Articles of Zero Trust, restates NIST SP 800-207 as ten identity-provider-scoped rules.
• Articles of CMMC Compliance, isolates the eleven CMMC Level 2/3 rules identity providers actually touch.

Each includes a ready-to-use AI prompt so a reader can score Pulse CA, or any competitor, against the same fixed, public text rather than take a vendor's word for it.