Eleven Rules of the Secure Agentic AI Framework
Agentic AI • Security Framework • Continuous Authentication

Eleven Rules for Securing Authenticated

and

Agentic AI Sessions

Second Edition • September 22, 2026

Notes

  1. The Eleven Rules for Securing Agentic AI Sessions documented here are foundational attributes, common-sense contributors to securing both agentic AI sessions specifically and authenticated sessions generally. They are the foundational principles of Pulse CA architecture and are original work products derived from generally available industry standards and authorities.
  2. Notwithstanding the title, the eleven rules apply to processes inclusive of those performing agentic AI tasks.
  3. This is a second edition updated to reflect more accurately standards alignments and to accommodate both human and machine origins.

Authentication establishes identity. The Eleven Rules establish trust.

For decades, cybersecurity has treated authentication as the primary measure of trust. Once a user successfully authenticated, the resulting session was largely assumed to remain trustworthy until it ended. That assumption no longer holds.

Modern attacks increasingly occur after authentication. And with the emergence of agentic AI, the consequences of a broken trust relationship extend far beyond a single compromised session.

Securing a session, especially an agentic AI session, takes the combined efforts of two related frameworks, the session security framework these rules apply to, and the separate yet equally important action security framework taking place within the session. While one is not the responsibility of the other, session security should make available its metrics and trust scores for evaluation by action security.

Modern attacks increasingly occur after authentication. Session hijacking, stolen tokens, consent abuse, and other post-authentication attacks have demonstrated that proving identity once is not the same as continuously trusting an active session. At the same time, the emergence of agentic AI has fundamentally changed the security landscape. Autonomous agents are capable of acting on behalf of users, invoking services, spawning additional agents, and making decisions without continuous human interaction. If the trust relationship between the human and those agents is not continuously maintained, the consequences can extend far beyond a single compromised session.

The cybersecurity industry has responded with a variety of technologies described as continuous authentication, continuous verification, continuous monitoring, continuous access evaluation, and continuous identity assurance. Standards such as Zero Trust Architecture (ZTA), CMMC, CAEP, and Shared Signals Framework have accelerated this evolution.

These advances are valuable, but they introduce a new challenge: how should architects, security professionals, regulators, and customers evaluate these solutions? What capabilities are essential? Which are optional? How can one distinguish comprehensive security from isolated features marketed under similar names?

The Eleven Rules for Securing Authenticated and Agentic AI sessopms answer those questions. Rather than describing a particular product or implementation, they define the fundamental principles that any secure agentic AI architecture, and, increasingly, any secure online session architecture, should satisfy. Together they provide a practical framework for evaluating whether a solution merely authenticates users or truly maintains trust throughout the entire lifecycle of human and agent activity.

Technology will continue to evolve. These principles are intended to endure.

The Eleven Rules

Each rule identifies a specific security measure that should be in place to reduce cyber risk in agentic AI deployments and business account security generally. This is not a pass/fail test. It's a diagnostic gauging level of achievement. Each rule traces its origins to generally accepted guidelines and standards, noted beneath each rule and listed in full under References.

What changed. The framework stays at eleven rules; revisions have been applied to accommodate a machine-to-machine (M2M) gap inside an existing rule or to emphasize that agentic agents exist as processes. The originals handled single-lineage agents well, including non-human roots. They were weakest where agents from different lineages call each other, where machine credentials can be replayed, where credential rotation was treated like identity revocation or where emphasis on the process was lost.

Definitions. These terms apply throughout. Where a rule says “founding identity,” it means either kind of root unless it names one.

  • Founding identity. The root of an agent's lineage. It is either a founding human, authenticated with a phishing-resistant method, or a founding non-human identity, cryptographically attested at creation through hardware-rooted keys, workload attestation, or an equivalent spoof-resistant mechanism.
  • Identity versus credential. An identity is the persistent, uniquely verifiable principal. A credential is the short-lived, rotatable proof that an identity presents at a given moment. Credentials expire and rotate routinely; identities are revoked deliberately.
  • Lineage. The chain from an agent instance, through every ancestor, to its founding identity. A lineage is a tree.
  • Delegation chain. The ordered record of every principal a request passes through, carried with the request itself. Where lineages meet, the delegation chain links trees into a graph.
  • Identity boundary. Any point where one party asserts identity, trust, or authorization to another: human to machine (H2M) or machine to machine (M2M), including process to process, agent to agent, agent to tool, and agent to MCP server.
  • Accountable owner. The human or organization answerable for a founding non-human identity. Every non-human root has one.
  • Process. As used here means an active, dynamic entity loaded into memory that performs the instructions of the program.

The Root

I

Phishing-Resistant Identity and Authorization

All points of human identity assertion—from initial login and token delivery to step-up reauthentication—must use origin-bound public-key cryptography (e.g., FIDO2/WebAuthn). This foundational boundary must be enforced continuously throughout the session lifecycle, not just checked at login. No rule that follows has meaning if this boundary can be compromised.

Standards alignment: NIST SP 800-63B-4; CISA phishing-resistant MFA guidance; W3C WebAuthn / FIDO CTAP2; Model Context Protocol authorization specification; OWASP Top 10 for LLM Applications.

II

Born from a Verified Human Activity

Every agent process traces to a verified human at the root. Nothing exists in the process tree without one, and an unverified or compromised root invalidates everything that follows. Every process traces its origin to a human foundation of trust, established in one of two ways:

  • Explicit: the founding human's verified, phishing-resistant login (Rule I). Their identity, authorization level, and trust posture at that moment become the process's immutable starting conditions.
  • Implicit: processes operating without active human presence on origination rely on assigned administrative ownership that the runtime environment enforces to prevent privilege escalation.

The foundation is established by the execution environment, not asserted by the process, and applies whether or not the process registers with an identity system or identifies itself as an agent. A process with neither foundation is an exception: it is reported and, as policy directs, paused or terminated.

Standards alignment: NIST SP 800-63-4; CoSAI Agentic Identity and Access Management.

III

Unique, Verifiable Identity

Each autonomous process and AI agent must possess a unique, cryptographically protected Non-Person Entity (NPE) identity. Agent instances cannot share credentials or remain indistinguishable during execution.

Standards alignment: NIST SP 800-53 IA-2 and IA-5; NIST SP 800-63-4.

The Chain (Depth)

IV

Authorization Equal or Lower than the Founding Human

Authority originates solely from human consent and strictly diminishes with every transfer. Each recipient receives only a subset of what was passed to them—never more. Scope expansion requires explicit administrative intervention or re-evaluation of user rights.

Standards alignment: NIST SP 800-53 AC-6; RFC 8693; NIST SP 800-207.

V

Presence Carried at Every Hop

Identity and presence are verified independently at every hop directly against the root authority, rather than relying on forwarded credentials or upstream assertions. The framework mandates short-lived, cryptographically bound assertions continuously monitored renewed; failure to renew leads to revocation of access authority.

Standards alignment: NIST SP 800-207; RFC 8705; RFC 9449; MITRE ATT&CK (lateral movement).

The Fan-out (Breadth)

VI

Branches Bound to the Root

Every branch opened from a live session, including through single sign-on, stays bound to the root rather than to a portable bearer token that outlives the proof of presence. A branch is valid only while the human's presence at the root is confirmed; if the human walks away, every branch follows.

Standards alignment: NIST SP 800-63C-4; RFC 9449; OpenID Shared Signals Framework and CAEP.

VII

Propagation Governed by Policy

Extending the process tree, whether by adding hops, opening branches, or spawning new agent processes, is a policy-granted privilege with limits on depth (hops) and breadth (branches).

Standards alignment: CoSAI Agentic Identity and Access Management; OWASP Top 10 for LLM Applications (excessive agency).

The Whole Tree

VIII

Session Lifecycle Linkage

Every hop and branch is a sub-lease of the root session. When the human's presence lapses or the root is revoked, the whole tree follows, chains and branches together, signaled by push notification (e.g., CAEP) rather than left to token expiry.

Standards alignment: OpenID Shared Signals Framework and CAEP; NIST SP 800-207.

IX

Right to Exist: Continuous Verification and Step-Up

The human's presence and identity are verified continuously, not once at login. When trust degrades, or an action's sensitivity exceeds the current trust level, step-up is required before the tree proceeds. Presence can lapse and be restored: the tree can be paused while presence is uncertain, resumed when the human re-establishes it, and terminated when the root is lost or wrong.

Standards alignment: NIST SP 800-63B-4; NIST SP 800-207; OpenID CAEP.

X

Supervision, Action-Level Control, and Auditability

Every action must be authorized at execution and recorded in a tamper-evident trail showing the acting node, its path through the chain, its branch, and the human at the root.

Standards alignment: NIST SP 800-53 AU family; ISO/IEC 27002; RFC 8693.

XI

Accountability and Enforcement

Accountability ends with the human at the root. Policy defines a graduated response to lost trust (pause, resume, or terminate), applied to the affected hop, branch, or the whole tree.

Standards alignment: NIST SP 800-53 IR family; CoSAI Agentic Identity and Access Management.


How Does Pulse CA Measure Up?

We built Pulse with these rules as design requirements, not aspirational goals. Session lifecycle linkage, phishing resistance through the full agentic tree, inherited trust posture, Merkle Tree auditability, these are baked into the architecture.

Ask your AI agent to score us. We're not concerned about the answer.

Request a Demo → Read the Technical Brief

Acknowledgements

In March 2026, the Coalition for Secure AI (CoSAI), an OASIS Open Project, published "Agentic Identity and Access Management," a nine-point framework for agent identity, delegation, and governance developed independently of this work and approved by the CoSAI Technical Steering Committee on March 20, 2026. The overlap in architectural instinct between that effort and the Eleven Rules, first-class agent identity, bounded delegation, immutable auditability, reflects a broader convergence taking shape across the industry rather than shared authorship. Notable points of departure include the treatment of standing privilege held independently by an agent versus privilege strictly bounded by the founding human, the universality of cryptographic identity assurance across all risk tiers, and the governance of collective scope within multi-agent groupings.

Additional standards and authorities are listed under References below.

Coalition for Secure AI, Workstream 4. "Agentic Identity and Access Management." OASIS Open Project, approved March 20, 2026.

References

Standards, specifications, and authorities from which the Eleven Rules are derived or with which they align. Draft and evolving specifications are identified as such.

  1. Coalition for Secure AI (CoSAI), Workstream 4. Agentic Identity and Access Management. OASIS Open Project, 2026. https://github.com/cosai-oasis/ws4-secure-design-agentic-systems/tree/main/whitepapers/agentic-identity-and-access-control.pdf
  2. NIST SP 800-63-4, SP 800-63B-4, and SP 800-63C-4. Digital Identity Guidelines; Authentication and Authenticator Management; Federation and Assertions. 2025. https://csrc.nist.gov/pubs/sp/800/63/b/4/final
  3. NIST SP 800-207. Zero Trust Architecture. 2020. https://csrc.nist.gov/pubs/sp/800/207/final
  4. NIST SP 800-53 Rev. 5. Security and Privacy Controls for Information Systems and Organizations (AC, AU, IA, IR families). https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
  5. NIST NCCoE. Accelerating the Adoption of Software and AI Agent Identity and Authorization (draft concept paper). February 2026. https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
  6. CISA. Implementing Phishing-Resistant MFA (fact sheet).
  7. W3C. Web Authentication (WebAuthn). FIDO Alliance. Client to Authenticator Protocol (CTAP2). https://www.w3.org/TR/webauthn/
  8. IETF RFC 6749. The OAuth 2.0 Authorization Framework. https://www.rfc-editor.org/rfc/rfc6749
  9. IETF RFC 8693. OAuth 2.0 Token Exchange. https://www.rfc-editor.org/rfc/rfc8693
  10. IETF RFC 8705. OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. https://www.rfc-editor.org/rfc/rfc8705
  11. IETF RFC 8707. Resource Indicators for OAuth 2.0. https://www.rfc-editor.org/rfc/rfc8707
  12. IETF RFC 9449. OAuth 2.0 Demonstrating Proof of Possession (DPoP). https://www.rfc-editor.org/rfc/rfc9449
  13. OpenID Foundation. Shared Signals Framework (SSF) and Continuous Access Evaluation Profile (CAEP). https://openid.net/wg/sharedsignals/
  14. OWASP. Top 10 for LLM Applications. https://genai.owasp.org/llm-top-10/
  15. Model Context Protocol. Authorization specification. https://modelcontextprotocol.io/specification/
  16. ISO/IEC 27002:2022. Information security controls.
  17. MITRE ATT&CK and MITRE D3FEND. https://attack.mitre.org/

About the Author: Rick Hallock

Rick's introduction to cybersecurity began in 2000, when he was the target of a cyber-attack that resulted in significant personal and business losses. He later received formal training in cyber defense while working for a multinational cybersecurity firm. Since then, he has continued to deepen his expertise through independent research, earning multiple related patents. Today, he applies his software architecture and design background to the creation of the Affirmed Identity service, available at https://AffirmedId.com.

← Back to Blog