New requirements for Authentication and Authorization in the AI Agents era

Introduction Traditional security models are built on a core assumption: the behavior of a protected entity, be it a human or a service, is relatively predictable. We authenticate an "identity" and then grant it a set of fixed "permissions." AI Agents shatter this foundation. An AI Agent is not a simple instruction executor; it is a goal achiever. We provide it with a high-level objective (e.g., "optimize supply chain costs"), and it autonomously deconstructs the task, learns from its environment, invokes tools, and may discover innovative operational paths we never anticipated. This shift introduces four disruptive characteristics: High Autonomy and Emergent Behavior: An Agent's actions are not pre-coded but are dynamically generated to achieve a goal. Static permission rules can neither foresee nor cover all its possible operations. Dynamic, Ephemeral, and Replicable Nature: For efficiency, a primary Agent may spawn thousands of ephemeral sub-agents in an instant to handle parallel tasks. Their identities are transient, massive in scale, and may exist for only milliseconds. Complex Delegation and Chains of Responsibility: Agents can form deep, networked call chains. A travel Agent might call a flight Agent, which in turn calls a payment Agent. When an unauthorized action occurs, attributing responsibility and tracing the flow of permissions becomes incredibly complex. Continuous Learning and Adaptation: An Agent's decision-making model evolves over time. This means an Agent's "normal behavior" today may differ from yesterday's, making it vulnerable to model drift or malicious manipulation that traditional static credentials cannot detect.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174].

New Authentication Requirements:From "Who Are You?" to "Are You Still Trustworthy?" In the face of these characteristics, one-time authentication becomes woefully inadequate. We need a new authentication framework capable of continuously assessing an Agent's trustworthiness.

New Requirement 1: Traceable Identity and Provenance Authentication protocols must support a new identity format that is more than just an ID; it's a cryptographic "provenance record." This certificate must contain: Genesis Information: The root user or task that initiated the Agent's creation. Delegation Chain: A cryptographically signed, non-forgeable call path that clearly records every delegation from the genesis to the current instance.

New Requirement 2: Continuous Behavioral Attestation Authentication cannot be a single event. Protocols must support a lightweight "behavioral heartbeat" mechanism, allowing an Agent to periodically submit a cryptographic digest of its recent actions to a monitoring system. By comparing this digest against an expected behavioral baseline, the system can continuously verify that the Agent is "acting normally," thus detecting hijacking or unexpected drift even if its identity credential remains valid.

New Requirement 3: Ultra-Low-Overhead Identity Management To support massive-scale, ephemeral Agents, protocols must enable near-zero overhead for identity creation and verification. Expensive public-key operations and complex handshakes should be replaced with efficient symmetric-key mechanisms to meet the demands of high-frequency creation, destruction, and continuous attestation.

New Authorization Requirements: From "What Permissions Do You Have?" to "What Are You Allowed to Do, Right Here, Right Now?" Static, Role-Based Access Control (RBAC) is obsolete in the face of autonomous Agents. Authorization decisions must become dynamic, precise, and risk-aware.

New Requirement 1: Intent-Driven, Just-in-Time (JIT) Permissions Authorization is no longer about pre-assigning a broad role. Instead, it must be about granting the principle of least privilege required to complete a specific task, at the moment of execution. For example, the system should grant an Agent permission to "execute a payment of amount <= $100 for the purpose of booking a flight" rather than a generic "payment" permission. This permission must expire immediately upon task completion.

New Requirement 2: Rich Context and Risk-Awareness Authorization decisions must be based on a rich set of contextual factors, including but not limited to:

The Agent's intent and objective.
A risk assessment of the requested operation.
Whether its current behavioral patterns are normal.
The sensitivity and provenance of the data being accessed.

Protocols must be able to efficiently carry this structured context to the policy engine for real-time evaluation.

New Requirement 3: Explainable and Auditable Authorization Given the autonomy of Agents, when something goes wrong, we must be able to answer, "Why was the system authorized to do that?" Therefore, the response from an authorization protocol must be explainable. It should return not just an "Allow" or "Deny" verdict but also the rationale behind the decision, such as the policy IDs that were matched and a snapshot of the critical context evaluated. This is essential for post-mortem audits, accountability, and the iterative refinement of security guardrails.

IANA Considerations

Security Considerations