Pulse Agentic AI Extension

Executive Summary

Pulse Continuous Authentication establishes a foundational principle: security is not a gate at login — it is a continuous, living signal tied to the verified presence and identity of a human user. As organizations deploy agentic AI systems that operate autonomously for extended periods, a critical security gap emerges: the human who authorized the workflow may no longer be actively engaged, yet the automated activity proceeds without any ongoing verification of the originating principal.

The Pulse Agentic AI Extension bridges this gap. By anchoring every agentic session to the continuous authentication state of the initiating human — enforced through a tightly integrated OIDC/OAuth 2 + AuthZEN + PDP/PEP framework — Pulse extends the same trust guarantees that protect human sessions to the autonomous agents operating in their name. When the human's trust degrades or their ClientMaster session terminates, the entire agentic chain responds immediately and automatically.

The Security Challenge: Agentic AI Without Human Continuity

Traditional authentication frameworks were designed for human sessions. A user logs in, performs actions, and logs out. The session lifecycle is predictable and relatively short. Agentic AI fundamentally changes this model:

• Agents may operate for hours or days without human interaction
• A single human authorization can spawn dozens of sub-agents with cascading permissions
• Agents access sensitive resources, execute transactions, and modify systems autonomously
• The human who initiated the workflow may be unavailable, asleep, or have had their credentials compromised after launch
• Existing session tokens provide static authorization that cannot reflect changes in the human's trust state

Architectural Foundation

1. The ClientMaster: Human Presence as the Root of Trust

At the core of the Pulse Agentic Extension is the ClientMaster — the OIDC client session that binds the authenticated human to the agentic ecosystem. The ClientMaster is not merely an authentication record; it is the continuous, live proof of human presence and accountability.

• The human authenticates to the ClientMaster using Passkey (FIDO2) or the AffirmedID Auth app, establishing a dual-assertion identity baseline
• The Auth app continuously streams Identity, Proximity, 3D Location, and Device Health trust metrics to the Pulse PDP throughout the ClientMaster session
• All agentic sessions inherit their authority from the ClientMaster — they share its ClientID and cannot outlive it
• If the ClientMaster session terminates for any reason — logout, trust threshold breach, device compromise, proximity violation — all subordinate agentic sessions terminate immediately via PEP push notification

2. Agentic Identity: Cryptographic Accountability with SHA-256/SHA-512

Each agentic instance receives a unique AgenticID — a cryptographic hash (SHA-256 or SHA-512) derived from a context tuple that establishes its provenance and relationships. The resolved context elements contributing to the AgenticID hash are:

• The specific agentic instance parameters (role, scope, invocation context)
• The ClientMaster instance identifier at time of spawn
• The parent agentic instance identifier (for spawned sub-agents)
• A time-bounded session window — the valid operational time range for this agent instance, baked into the hash at creation. An agent whose session window has elapsed carries an identity that no longer matches any valid authorization record, making expired agents cryptographically distinguishable from active ones without a separate revocation lookup.
• A timestamp and nonce to prevent replay and hash collision

The AgenticID hash provides multiple security properties simultaneously:

• Immutability: the identity of any agentic instance is fixed at creation and cannot be altered
• Provenance: the hash encodes the chain of delegation from human to ClientMaster to agent
• Non-repudiation: every action taken by an agent is attributable to a specific, cryptographically identified instance
• Auditability: AgenticIDs serve as keys in the Merkle Tree audit structure, enabling efficient verification of any action in the session history

3. OIDC PKCE and BFF: Secure Agentic Session Architecture

Agentic implementations leverage the Pulse OIDC framework through two proven patterns, both built on the PKCE authorization flow:

A critical architectural decision — shared ClientID — ensures that all agentic sessions are recognized within the same OIDC authorization domain as the originating human. This means:

• The OIDC provider can enforce session-level policies across the human and all their agents uniformly
• Token revocation at the ClientMaster level propagates to all agents sharing that ClientID
• Authorization scope granted to agents is always a subset of what the human ClientMaster holds — agents cannot self-elevate

4. Authorization via AuthZEN: Policy-Governed Agent Operations

Every agentic authorization request flows through the Pulse AuthZEN evaluation pipeline. This is not a separate agent-specific authorization system — it is the same trust-enriched evaluation that governs the human session, extended to agents:

• The agent sends an AuthZEN access evaluation request specifying subject (AgenticID + session context), action, and resource
• The PDP evaluates the request against current trust context, including the live trust scores from the human's Auth app
• Decisions are trust-enriched: permit, deny, permit-with-reduced-scope, or permit-pending-step-up
• Step-up is invoked inline by AuthZEN at the moment of evaluation — the PEP immediately pauses all affected agentic operations and pushes a step-up challenge to the human's Auth app. If the human completes the step-up challenge, operations resume. If the challenge is refused or times out, the relevant agent sessions terminate.
• All decisions are logged with AgenticID, timestamp, trust scores at time of evaluation, and the policy rule applied

Agentic Lifecycle Management

Agent Spawning: Clone vs. New Incarnation

Agentic instances authorized by the system may themselves spawn new agents, subject to policy. Two spawn models are supported, each with distinct authorization semantics:

In both cases, the spawn operation itself is logged with the parent AgenticID, spawn type, timestamp, and the trust state of the human ClientMaster at time of spawn. This creates a complete genealogy of agent delegation for compliance and forensics.

Session Continuity Conditions

Agentic operations continue if and only if all three of the following conditions are simultaneously satisfied. Failure of any single condition triggers immediate suspension or termination of all affected agents:

Accountability and Monitoring: Merkle Tree Session Integrity

The Pulse Agentic Extension employs Merkle Tree methods to provide tamper-evident, continuously verifiable accountability across the entire agentic session hierarchy. This is not post-hoc logging — it is real-time integrity assurance embedded in the OIDC session domain.

How Merkle Tree Accountability Works

• Each significant agentic event — spawn, authorization request, resource access, trust score update, termination — is hashed and appended as a leaf node
• Leaf nodes are organized into a binary Merkle Tree where each parent node contains the hash of its two children
• The Merkle root hash represents the complete, tamper-evident state of all agentic activity in the session
• Any modification to any historical event invalidates the root hash and is detectable immediately
• The Merkle root is re-anchored on two triggers: on-demand during compliance queries (always producing a fresh verified root for audit), and at a configurable rate set by the Relying Party — allowing deployment-specific tuning of integrity assurance vs. overhead

Continuous Session Monitoring Within the OIDC Domain

All Merkle Tree operations occur within the OIDC session domain — the same domain that governs the human's ClientMaster. This means:

• The OIDC provider, PDP, and PEP are all aware of both the human trust state and the agentic activity record simultaneously
• A policy decision that terminates the human session can reference the Merkle-anchored activity record to determine which agent actions to flag for review
• The session correlation ID ties the human's Auth app metric streams, the ClientMaster session, and every AgenticID into a single queryable record
• Incident response teams can reconstruct the complete chain of events — from human login through every agent action — using a single correlation ID

Technical Benefits Summary

Resolved Design Decisions

The following architectural questions have been resolved and are incorporated into this document. They are recorded here for traceability between the design outline and the specification.

Alignment with Existing Pulse Framework

The Agentic AI Extension is architecturally additive — it does not require modification of the core Pulse continuous authentication framework. All extension points use existing Pulse interfaces:

• ClientMaster sessions use the existing AffirmedID Connect OIDC provider with no protocol changes
• AgenticID hash generation and Merkle Tree operations are new services that consume existing session correlation IDs and OIDC token data
• AuthZEN evaluation for agents uses the same PDP evaluator endpoints already exposed for human session authorization
• PEP push notifications for agent suspension use the same callback registration mechanism already available to OIDC relying parties
• Audit log output is additive to the existing Splunk HEC pipeline — new AgenticID and Merkle root fields are appended to the existing session log schema