Continuous Authentication & Identity Assurance
For Every Human, and Every Agent Acting on Their Behalf
Your IdP verifies who logs in. Pulse CA verifies who's still there—human or AI agent.
Extend your existing IdP with continuous identity assurance that follows a session from human login, through every agent and sub-agent it authorizes, to logout.
The Gap Attackers Exploit
Traditional authentication checks credentials once—at login. But what happens in the 30 minutes, 2 hours, or full workday after that? Credentials get stolen mid-session. Devices change hands. Users move to unexpected locations. And your security system has no idea until it's too late.
Agentic AI widens the same gap. A single login can spawn an agent that spawns sub-agents, running for hours or days after the human who authorized it has logged off, gone to sleep, or had their own credentials revoked. Most frameworks issue a token at launch and never check again. If the human's trust status changes, nothing tells the agent.
Built as One. Not Bolted Together.
Most CA solutions force you to integrate multiple vendors—authentication here, monitoring there, enforcement somewhere else. We architected Pulse CA as a single, elegant framework where every component was designed to work together from day one.
No Integration Headaches
It's already integrated. The OIDC provider, Auth device, and PDP were built to work together—no duct-taping vendor APIs or hoping they'll talk to each other.
No Gaps in Coverage
The OIDC provider orchestrates authentication, knows session state, and controls logout. CA monitoring starts exactly when it should and stops when the session ends—no blind spots.
Instant Enforcement
PDP trust decisions flow directly to the OIDC provider managing your session. No separate enforcement layer. No hoping policies get applied. Immediate action.
Single Pane of Glass
Correlation IDs link every event from authentication through monitoring to enforcement. Complete audit trail. One cohesive system—not three vendors pointing fingers at each other.
Pulse CA Framework
As the IdP Provider Service
Five integrated parts working as one elegant system
1. Access Device
The OIDC client application (a.k.a. laptop, desktop, tablet, machine, robot, et.al) integrates seamlessly with Pulse CA. An OIDC session started by the application or AI agent, links to Pulse Connect OIDC provider that supports user login using either Auth or cell phone, OS Passkey, or FIDO2 key.
2. Pulse API Services
Pulse Cloud API platform orchestrates all Pulse components. It securely maintains the registration database for Auth, OIDC, SAML, and Sentinel, provides Relying Party federation, streamlined FIDO2 upgrade/recovery, and federates FIDO2 Client functionality with bi-directional authentication on behalf of Relying Parties. Its integrated Policy Decision Point (PDP) enables Continuous Authentication and Identity Authorization through real-time, risk-based access decisions.
3. OIDC Provider
The session orchestration hub; manages authentication ceremonies, maintains session state, receives real-time PDP policy-based decisions a.k.a. Policy Enforcement Point (PEP). Exposes AuthZEN endpoint with MCP. Connects with Pulse API over HTTPS/WSS, with WSS channel traffic additionally protected by an ML-KEM-derived AES-256-GCM session key. Optional SAML provider is avilable.
4. Auth Device (User's Phone)
As primary or adjunct to Passkey authenticator, implements user recognition via behavioral patterns and PIN. Dual assertions, identity and device-bound FIDO2, delivered to federated FIDO Client over secure networks. Provides for easy and secure FIDO2 upgrades, same or different phone types. Captures and streams trust metrics (Identity, Proximity, Location, Device Health) to the PDP throughout monitored sessions. Provides BLE advertising secure token on Sentinel request to do so.
5. Sentinel (Endpoint Background Service & AI Agent Trust Broker)
Optional addition completes the Pulse CA security loop framework. Operates as a persistent, per-user background service on the access device, extending continuous authentication and identity assurance to that device and to every AI agent running on it. Establishes a cryptographically secure device identity, registers with FIDO2-DA (device assertion without user interaction), and actively verifies the physical proximity of the user's Auth device over BLE. For agentic AI, Sentinel is the local trust broker: it answers MCP and AuthZEN requests from endpoint agents over loopback HTTP, so an agent's authorization check never has to leave the machine. Connects with Pulse API over HTTPS/WSS, same as described above. Incorporates policy enforcement (PEP). Hosts two MCP listeners, an embedded MCP listener with COAZ enforcement, and a second for fallback to conventional MCP.
Pulse CA Framework
An Addon to IdP/IAM Service
Five integrated parts working as one elegant system
1. Benefits
Where the existing IdP or IAM service is working well but has no continuous authentication and identity authorization, and most do not, Pulse CA is a workable and cost-effective addition that brings continuous authentication and identity authorization to any existing environment. With few exceptions, Pulse CA as described above and elsewhere within this website can be stood up alongside any existing IdP or IAM service.
2. Configuration
As a service, Pulse CA is installed in less than a day. On-premises installations take a bit longer with addition of the Pulse API cloud service on either private or public networks. Best of all, there is absolutely no modifications to the existing infrastructure. Indeed, its unaware of Pulse CA standing alongside it.
3. Impacts
Impacts will be realized as will have to install and register the Auth app on their cell phones. They’ll have to be trained and coached into keeping the cell phone nearby when taking part in authenticated sessions. Notwithstanding this impact, all else should go on as per usual.
4. Hidden from View
Transparently to normal activities, Pulse CA carries on as it normally would without taking part in the authentication process. Indirectly Sentinel activated on login prompts the user for their username. With that it begins a headless Pulse OIDC session use throughout till the logout event.
5. Phishing Resistant Adder
It’s possible the addon environment is not phishing resistant. Pulse CA provides it at each of its access points. It employs 2 FIDO2 configurations, an H2M FIDO2 authentication based on the SoloKey opensource SDK Level 1 certified by FIDO Alliance/WebAuthn. The other M2M we call, DPoP, employs the same core FIDO2 but without its user gesture component. As such it is not candidate for certification but its underlying base, that of FIDO2, provides the phishing resistance. Pulse employs it as an M2M solution at API connections to OIDZC, SAML, and Sentinel.
Cryptographic Accountability
The Pulse API enforces cryptographic accountability by requiring attestation at registration and identity assertion at every access. FIDO2 user access relies on either the Auth app or a Passkey on the user's mobile device, while device identity attestation and assertion across all endpoints use the same FIDO2 algorithm—referred to as FIDO2-DA—operating without a user gesture requirement. Wherever supported, hardware security elements handle private key and certificate storage, keeping credentials off the reach of software-only attacks.
When deployed as an addon, user authentication is untouched and remains governed by your existing IdP or IAM installation. Even in this configuration, the user's mobile device with the Auth app installed continues operating as an identity monitoring and assertion layer, running alongside the primary authentication method rather than replacing it.
This attestation-and-assertion chain is what anchors Sentinel's Merkle-tree audit lineage, tracing every action—including those of agentic AI sub-agents—back to a specific enrolled endpoint, a verified session, and an authenticated human principal.
Anchoring Agentic AI to a Human Root of Trust
The same continuous trust signal that protects a human session extends to every agent—and every sub-agent—that session authorizes.
ClientMaster: Human Presence as the Root of Trust
Every agentic session inherits its authority from the ClientMaster, the live OIDC session of the human who launched it. Agents share its session identity and cannot outlive it. If the ClientMaster session ends—logout, a trust threshold breach, device compromise, a proximity violation—every subordinate agent is notified and terminated immediately, no matter how many hours or sub-agents removed from the original login.
AgenticID: Cryptographic Identity Per Agent
Each agent instance, including every sub-agent it spawns, receives its own AgenticID: a SHA-256/SHA-512 hash encoding its role and scope, its parent agent, the ClientMaster it descends from, and a time-bounded validity window. Tamper with an agent's context or parentage and the hash no longer matches—expired or forged agents are cryptographically self-evident, not just flagged after the fact.
Merkle-Anchored Audit Lineage
Sentinel registers every AgenticID in a Merkle tree, the same integrity structure used to secure cryptocurrency ledgers. Any action, by any agent, at any depth in the tree, is traceable back through its parent agents to the ClientMaster and the authenticated human—and any descendant of a given agent can be found by traversing the tree from that point.
From Pre-Auth to Logout: Complete Session Coverage
The Complete Framework in Action
1. Pre-Authentication Setup
Following Auth app installation, registration of it and the device along with verified email address, and phone number completes the installation.
2. Behavior Recognition
Behavior recognition (how, where, when, and frequency of use) is a learning process that begins with first PIN entry. Over time its accuracy improves to the point PIN use may becomes optional in some cases.
3. Choice of Authenticators
An authentication event triggers at login with application link to Connect OIDC or SAML session service. There is a first use option, use SFA Passkey or MFA Auth, as the default method. Both use phishing resistant FIDO2. A session ID is created for accounting and tracking purposes.
4. Continuous Monitoring Begins
The session begins and Auth app, even when Passkey is used, begins streaming trust metrics to the cloud Pulse API: behavior-based identity recognition, BLE proximity, device possession by human, GPS-based location including elevation and Device health tracking; all monitored until logout.
5. Real-Time Analysis & Enforcement
Throughout the session, Pulse’s Policy Detection Point (PDP) analyzes trust scores feeding results to OIDC or SAML Policy Enforcement Point (PEP) for enforcement. High trust: Session continues. Medium trust: Step-up required. Low trust: Session terminated. Normal logout: CA monitoring ends gracefully.
6. Sentinel Option
Sentinel installed on the access device completes the security circle. Both Auth FIDO2 and Sentinel DPoP merge at Pulse API. Token traversal from Sentinel to Pulse API on to Auth and over BLE to back to Sentinel where it’s verified. A closed loop security model on like Googles CaBLE but distinguished by its whole session application. If AI agents are running on the device, Sentinel brokers their MCP and AuthZEN checks locally and terminates them the instant the human's ClientMaster session degrades.
Built on Modern Security Frameworks
AuthZEN
OpenID Foundation AuthZEN access evaluation, vendor-neutral, interoperable authorization integrated into OIDC and SAML client configurations. Learn more →
Zero Trust Architecture (ZTA)
Continuous verification aligns perfectly with "never trust, always verify" principles
CMMC
Meet Cybersecurity Maturity Model Certification requirements with real-time monitoring and enforcement
NIST
Aligned with NIST guidelines for continuous diagnostics and mitigation
The Attacks That Slip Through Traditional Auth
Mid-Session Credential Theft
Traditional Auth: ✗ User logged in at 9 AM. Credentials stolen at 11 AM. System has no idea.
Pulse CA: ✓ Behavioral anomaly detected immediately. Session terminated. Threat neutralized.
Unexpected Location Change
Traditional Auth: ✗ User authenticated from Boston. Now accessing from Romania. Still trusted. Or same building, wrong floor, 2D geofencing can't tell.
Pulse CA: ✓ 3D location monitoring (latitude, longitude, and barometric altitude) detects both impossible travel and floor-level displacement. Location violations trigger immediate step-up or session termination.
Device Compromise
Traditional Auth: ✗ Phone jailbroken mid-session. Full access continues.
Pulse CA: ✓ Device health monitoring detects compromise. Access revoked instantly.
Orphaned AI Agent
Traditional Auth: ✗ Human launches an agent, then logs off, sleeps, or has credentials revoked. Agent and its sub-agents keep working on a token issued at launch, unaware anything changed.
Pulse CA: ✓ Every agent inherits authority from the human's live ClientMaster session. The moment that session degrades, every descendant agent is notified and terminated—automatically, at any depth.