Enterprise identity has reached a tipping point where Non-Human Identities (NHIs)—service accounts, swarms, APIs, and AI agents—are now the primary residents of the network. Multiple industry reports put machine identities at one to two orders of magnitude larger than human populations; for example, Entro reports a 144:1 machine-to-human ratio in the environments it analyzed (Entro). CyberArk similarly frames machine identities as the dominant identity class and has reported large ratios (e.g., “80+:1” in some public materials) (CyberArk).

The second driver is operational velocity. Unlike humans, autonomous agents can execute hundreds of actions per minute, maintain asynchronous operations for days, and traverse organizational boundaries instantly. This creates a fundamental mismatch with traditional lifecycle controls—such as issuance, rotation, revocation, and deprovisioning. Because these legacy frameworks were built for human-scale login sessions and manual reviews, they have become bottlenecks. In a high-velocity environment, traditional controls aren't just slow; they are functionally impractical.

Against that backdrop, United State's National Institute of Standards and Technology (NIST)’s National Cybersecurity Center of Excellence (NCCoE) published a February 2026 concept paper explicitly aimed at accelerating adoption of software and AI agent identity & authorization, raising concrete design questions like ephemeral/task identities, hardware binding, OAuth integration, and workload identity options (e.g., SPIFFE/SPIRE) (nccoe.nist.gov). The OpenID Foundation’s work on agentic AI identity/security echoes the same theme: delegation, intent capture, auditability, and cross-domain revocation become first-class design constraints (openid.net).

To avoid the common pitfall of using one credential for everything, modern architecture splits agent identity into three distinct, decoupled layers:

1. Durable identity record (who/what this agent is over time)
   A stable identifier + provenance + ownership binding used for audit, policy, and revocation decisions.

2. Short-lived runtime credentials (what this agent can do right now)
   Rotated frequently, scoped narrowly, ideally bound to device/workload posture.

3. Action-specific authorization artifacts (what this agent is allowed to do for this action)
   Proof of delegated authority with explicit constraints: purpose, limits, time window, targets.

Decentralized Identifiers (DIDs) are often proposed for agent identity because they decouple identifiers from any single issuer while still enabling cryptographic control, providing a permanent cryptographic anchor (the Who) that remains globally unique and resolvable even as an agent moves across different clouds or organizational boundaries. The W3C DID Core spec defines DIDs as URIs that resolve to DID Documents containing verification material (e.g., public keys) and service endpoints (openid.net).

However, DID alone does not solve identity. Proving you own a cryptographic key doesn't explain what you are allowed to do or who is responsible for your action. Verifiable claims (VC) are the essential piece that provide the verified authority (the What) by wrapping specific "portable facts" —such as spending mandates, security clearances, or organizational bindings—into tamper-proof digital containers. Together, they create a durable primitive for autonomous systems. The W3C Verifiable Credentials (VC) Data Model standardizes interoperable credential structures that can carry claims (e.g., “registered agent for org X,” “passed compliance checks,” “approved merchant scope”), enabling verifiable delegation and audit trails (Microsoft Learn).

Agents are high-leverage: when they go wrong, they can go wrong fast. That’s why the design trend is toward short-lived, task-scoped credentials for execution, combined with a durable identity record for audit.

NIST’s 2026 concept paper explicitly probes how agent identities should incorporate ephemeral metadata tied to specific tasks/transactions, and how identities might be tied to hardware boundaries (nccoe.nist.gov).

The hard reconciliation is:

• Ephemerality (reduce blast radius; rotate constantly)
  vs.

• Accountability (durable audit trails; non-repudiation; clear responsibility chains)

A common synthesis is:

• Use short-lived operational tokens for runtime access (rotated frequently, narrowly scoped), while

• Maintaining a durable agent identity record (identifier + provenance + ownership + registration metadata) used for audit, policy, and revocation.

Agent systems break the “authenticate once, trust forever” assumption. Runtime trust decisions increasingly rely on continuous evaluation of origin, device/workload posture, session risk, and behaviour.

Two standards anchors make this shift easier to reason about:

NIST SP 800-207 frames zero trust as moving defenses away from static perimeters and toward continuous, context-driven decisions focused on users/assets/resources (NIST Publications).

The OpenID Foundation’s Continuous Access Evaluation Profile (CAEP) defines event types used between “Transmitters” and “Receivers” so security state changes can attenuate access for shared human or robotic users, devices, sessions, and applications (openid.net).

Practical implication: you can’t honestly promise “revocation in <500ms” from standards alone. CAEP gives the event model; end-to-end latency depends on the emitter/receiver architecture, subscriptions, and enforcement points.

As agents act “on behalf of” humans or organizations, the ecosystem needs ways to prove authorization without disclosing the principal’s full identity or sensitive attributes.

In practice, this shows up as:

• Selective disclosure (“prove you’re authorized / compliant / within threshold”)

• Unlinkable presentations (reduce correlatability across merchants/platforms)

• Minimal-revelation mandate proofs (prove a mandate exists and its bounds)

The verifiable claim ecosystem provides the interoperable credential container; newer selective disclosure techniques build on that, but the key conceptual shift is: in agentic systems, you often don’t need “prove your name,” you need “prove you have a mandate within constraints.”

The 2025–2026 commerce push is the "HTTP moment" for AI. Just as the web needed a common language to move beyond walled gardens, agentic commerce has converged on a stack that standardizes how agents discover products, negotiate terms, and execute secure payments.

The Universal Commerce Protocol (UCP), co-developed by Google and Shopify, is the open standard that allows agents to "speak" to any merchant (Shopify's Engineering Blog on UCP). Instead of "scraping" HTML like a human, agents query a merchant’s UCP profile to discover capabilities (e.g., subscription support, loyalty points) and product data. Using a "server-selects" architecture (Google for Developers merchant documentation), the agent proposes what it wants to do, and the merchant’s server chooses the best transaction path from their overlapping capabilities. UCP's transport-agnostic design, supporting traditional REST APIs, Agent-to-Agent (A2A), and Model Context Protocol (MCP) bindings, UCP offers the flexibility to power diverse of commerce activities and the interoperability to bridge the traditional web service integration and the new agent-native protocols (ucp.dev).

AP2’s central innovation is the Mandate: a cryptographically signed artifact capturing what the user authorized—often described as:

• Intent Mandate (rules of engagement: limits, timing, conditions)

• Cart Mandate (final approval of the specific purchase)

Google’s AP2 announcement describes this two-stage mandate flow and emphasizes constraints like price limits and timing as part of the signed authorization (Google Cloud AP2 Protocol). This is a concrete example of “authorization artifact as the cryptographic anchor” in a delegated action chain.

Mastercard’s Agent Pay messaging emphasizes making agent transactions recognizable and controllable across the value chain, with:

• registering and verifying AI agents, and

• enabling transactions using “agentic tokens” (dynamic, cryptographically secure credentials) (Mastercard).

Mastercard’s framework descriptions also highlight sharing intent-adjacent data elements—such as cart contents, transaction limits, and validity windows—to improve auditability and dispute handling (Mastercard).

Important nuance: “digital power of attorney” is a useful analogy, but the public pages primarily describe registration + tokenization + constraints metadata rather than fully specifying every binding semantic in public detail.

Where agentic commerce meets crypto infrastructure, a common design is “agent proposes, policy engine (or human) co-signs.” This is frequently implemented with MPC / threshold signatures:

• Coinbase describes threshold signatures as running an MPC protocol so that a threshold t of participants can sign without reconstructing the private key; and highlights Distributed Key Generation (DKG) where no one sees the private key in plaintext (Coinbase).

• Fireblocks documents co-signer architectures and operational models where an API co-signer can hold a key share, enabling automated approvals in some configurations and tighter controls (warm/cold) in others (Fireblocks Developer Portal).

This maps cleanly to agent governance:

• The agent can initiate actions (one share / proposal authority).

• A co-signer enforces policy thresholds and only participates in signing when criteria are met.

Agents don’t fit cleanly into static roles because they need conditional access tied to task and context (“resolve ticket,” “issue refund,” “book travel”), not blanket permissions.

NIST defines attribute-based access control (ABAC) as determining authorization by evaluating attributes of the subject, object, requested operations, and sometimes environment conditions against policy/rules (NIST Computer Security Resource Center)

NIST’s Policy Machine / NGAC work is positioned as a fundamental reworking of access control aligned with an ANSI/INCITS NGAC standard track (NIST)

Purpose-based access control (PBAC) is often used to describe access decisions conditioned on declared purpose of use (e.g., support resolution, audit). Academic work by Byun & Li is foundational here (Purdue Computer Science)

Capability-based authorization flips the default: you present a capability that already encodes what actions are allowed and under what caveats.

The W3C CCG ZCAP-LD spec describes an object capability model where capabilities can be delegated via chains and carry caveats (scope, lifetime, attenuation) (w3c-ccg.github.io)
This aligns naturally with mandate-based commerce flows: the portable artifact is the proof of authority.

In agentic systems, “semantic hijacking / intent hijacking” usually collapses to prompt injection + tool abuse, especially indirect prompt injection where malicious instructions ride along in external content (web pages, files, retrieved passages).

OWASP’s GenAI guidance describes indirect prompt injections as inputs from external sources that alter model behavior in unintended ways (OWASP Gen AI Security Project)

So the security job shifts: it’s not just “authenticate the agent,” it’s “ensure the agent’s tool calls remain inside the mandate.”

Traditional rate limiting counts requests. Agents need impact budgets:

• token spend,

• dollars spent,

• irreversible actions,

• or expensive external API consumption.

NIST’s API protection guidance explicitly treats risks like unrestricted resource consumption and recommends mitigations such as quotas, rate limiting, and policy controls across the API lifecycle (NIST Publications)

In agentic payments, the same pattern shows up as transaction limits and validity windows—constraints baked into the authorization context rather than bolted on later (Mastercard)

A “defensible” 2026 agent identity + commerce architecture typically combines:

1. Durable agent identity + registration
   Agent profile (DID or equivalent), operator/org binding, provenance and audit identifiers (openid.net).

2. Short-lived runtime credentials
   Narrowly scoped, frequently rotated execution tokens tied to runtime context (nccoe.nist.gov).

3. Intent/capability artifacts
   AP2 mandates (intent/cart) or capability tokens (ZCAP-LD style) that embed constraints and serve as portable proof of authority (Google Cloud).

4. Continuous evaluation + revocation propagation
   Zero trust posture plus cross-domain shared signals (CAEP) to attenuate access when risk changes (NIST Publications).

5. Schema’d tool interfaces (not UI scraping)
   MCP bindings for deterministic invocation of commerce actions (ucp.dev).

6. Impact budgets
   Quotas/limits for spend, actions, and resource consumption aligned to business impact (

Even with rapid standardization, a few gaps remain stubborn. For example:

• Interoperable “agent integrity state” attestation (model/tool/guardrail integrity) is much less mature than classic device/workload attestation, even though NIST is explicitly pushing the ecosystem to think beyond static credentials.

• Revocation in delegated, multi-hop ecosystems remains operationally difficult: you can propagate shared signals, but you still need strict constraints (short lifetimes, bounded execution, narrow scopes) to limit blast radius when revocation lags.

• Commerce trust/liability norms are still forming. UCP/AP2 define discovery and mandate primitives, but “who vouches for which agent, under what liability regime, with what privacy guarantees” is still being negotiated across merchants, issuers, networks, and identity providers.

“Quis custodiet ipsos custodes?” — Who will watch the watchmen? (Juvenal, Satires VI) (Wikipedia) The ancient question from Juvenal’s Satires has become a modern operational requirement. As autonomous systems transition from "chatting" to "acting," the primary security challenge is no longer just authentication; it is legibility. For an agent to be a safe participant in the 2026 economy, its actions must be defined by four distinct pillars:

• Attribution (Traceability): Every action must be cryptographically linked to a responsible principal via durable identity primitives like DIDs.

• Boundability (Scoped Authority): Authority is never open-ended; it is restricted by explicit mandates that define the "blast radius" of what an agent can and cannot do.

• Continuity (Temporal Context): Trust is not a one-time check but a continuous state that must be re-evaluated as the environment and security posture shift.

• Containability (Kill-switch Capability): Systems must have the "circuit breakers" necessary to halt a workflow instantly if an agent deviates from its intended path.

The standards and protocols emerging across identity, access control, and commerce are converging on a singular thesis: Trust is not a static login event; it is a runtime property. In this new paradigm, authority is expressed through short-lived credentials, constraint-heavy authorization artifacts, and shared signals that propagate risk across the network.

However, this shift toward "trust-as-a-service" leaves us with the fundamental questions that will define the next era of the agentic ecosystem:

• The Accountability Gap: Who is liable when an agent’s toolchain crosses multiple vendors, conflicting policies, and legal jurisdictions?

• The Persistence Problem: What does "revocation" look like when authority is delegated through portable mandates and capability chains that outlive the session that spawned them?

• The Integrity Paradox: How do we prove an agent’s internal integrity—not just its key custody—without turning compliance into total surveillance?

• The Impact Budget: When spending, compute, and irreversible actions become fully programmable, who sets the limits, who can override them, and who pays when they are exceeded?

As we delegate our agency to silicon, we must define its boundaries with precision and intention. Name them poorly, and you’ll spend the night chasing the wind you accidentally gave a wallet...

Enterprise identity has reached a tipping point where Non-Human Identities (NHIs)—service accounts, swarms, APIs, and AI agents—are now the primary residents of the network. Multiple industry reports put machine identities at one to two orders of magnitude larger than human populations; for example, Entro reports a 144:1 machine-to-human ratio in the environments it analyzed (Entro). CyberArk similarly frames machine identities as the dominant identity class and has reported large ratios (e.g., “80+:1” in some public materials) (CyberArk).

The second driver is operational velocity. Unlike humans, autonomous agents can execute hundreds of actions per minute, maintain asynchronous operations for days, and traverse organizational boundaries instantly. This creates a fundamental mismatch with traditional lifecycle controls—such as issuance, rotation, revocation, and deprovisioning. Because these legacy frameworks were built for human-scale login sessions and manual reviews, they have become bottlenecks. In a high-velocity environment, traditional controls aren't just slow; they are functionally impractical.

Against that backdrop, United State's National Institute of Standards and Technology (NIST)’s National Cybersecurity Center of Excellence (NCCoE) published a February 2026 concept paper explicitly aimed at accelerating adoption of software and AI agent identity & authorization, raising concrete design questions like ephemeral/task identities, hardware binding, OAuth integration, and workload identity options (e.g., SPIFFE/SPIRE) (nccoe.nist.gov). The OpenID Foundation’s work on agentic AI identity/security echoes the same theme: delegation, intent capture, auditability, and cross-domain revocation become first-class design constraints (openid.net).

To avoid the common pitfall of using one credential for everything, modern architecture splits agent identity into three distinct, decoupled layers:

1. Durable identity record (who/what this agent is over time)
   A stable identifier + provenance + ownership binding used for audit, policy, and revocation decisions.

2. Short-lived runtime credentials (what this agent can do right now)
   Rotated frequently, scoped narrowly, ideally bound to device/workload posture.

3. Action-specific authorization artifacts (what this agent is allowed to do for this action)
   Proof of delegated authority with explicit constraints: purpose, limits, time window, targets.

Decentralized Identifiers (DIDs) are often proposed for agent identity because they decouple identifiers from any single issuer while still enabling cryptographic control, providing a permanent cryptographic anchor (the Who) that remains globally unique and resolvable even as an agent moves across different clouds or organizational boundaries. The W3C DID Core spec defines DIDs as URIs that resolve to DID Documents containing verification material (e.g., public keys) and service endpoints (openid.net).

However, DID alone does not solve identity. Proving you own a cryptographic key doesn't explain what you are allowed to do or who is responsible for your action. Verifiable claims (VC) are the essential piece that provide the verified authority (the What) by wrapping specific "portable facts" —such as spending mandates, security clearances, or organizational bindings—into tamper-proof digital containers. Together, they create a durable primitive for autonomous systems. The W3C Verifiable Credentials (VC) Data Model standardizes interoperable credential structures that can carry claims (e.g., “registered agent for org X,” “passed compliance checks,” “approved merchant scope”), enabling verifiable delegation and audit trails (Microsoft Learn).

Agents are high-leverage: when they go wrong, they can go wrong fast. That’s why the design trend is toward short-lived, task-scoped credentials for execution, combined with a durable identity record for audit.

NIST’s 2026 concept paper explicitly probes how agent identities should incorporate ephemeral metadata tied to specific tasks/transactions, and how identities might be tied to hardware boundaries (nccoe.nist.gov).

The hard reconciliation is:

• Ephemerality (reduce blast radius; rotate constantly)
  vs.

• Accountability (durable audit trails; non-repudiation; clear responsibility chains)

A common synthesis is:

• Use short-lived operational tokens for runtime access (rotated frequently, narrowly scoped), while

• Maintaining a durable agent identity record (identifier + provenance + ownership + registration metadata) used for audit, policy, and revocation.

Agent systems break the “authenticate once, trust forever” assumption. Runtime trust decisions increasingly rely on continuous evaluation of origin, device/workload posture, session risk, and behaviour.

Two standards anchors make this shift easier to reason about:

NIST SP 800-207 frames zero trust as moving defenses away from static perimeters and toward continuous, context-driven decisions focused on users/assets/resources (NIST Publications).

The OpenID Foundation’s Continuous Access Evaluation Profile (CAEP) defines event types used between “Transmitters” and “Receivers” so security state changes can attenuate access for shared human or robotic users, devices, sessions, and applications (openid.net).

Practical implication: you can’t honestly promise “revocation in <500ms” from standards alone. CAEP gives the event model; end-to-end latency depends on the emitter/receiver architecture, subscriptions, and enforcement points.

As agents act “on behalf of” humans or organizations, the ecosystem needs ways to prove authorization without disclosing the principal’s full identity or sensitive attributes.

In practice, this shows up as:

• Selective disclosure (“prove you’re authorized / compliant / within threshold”)

• Unlinkable presentations (reduce correlatability across merchants/platforms)

• Minimal-revelation mandate proofs (prove a mandate exists and its bounds)

The verifiable claim ecosystem provides the interoperable credential container; newer selective disclosure techniques build on that, but the key conceptual shift is: in agentic systems, you often don’t need “prove your name,” you need “prove you have a mandate within constraints.”

The 2025–2026 commerce push is the "HTTP moment" for AI. Just as the web needed a common language to move beyond walled gardens, agentic commerce has converged on a stack that standardizes how agents discover products, negotiate terms, and execute secure payments.

The Universal Commerce Protocol (UCP), co-developed by Google and Shopify, is the open standard that allows agents to "speak" to any merchant (Shopify's Engineering Blog on UCP). Instead of "scraping" HTML like a human, agents query a merchant’s UCP profile to discover capabilities (e.g., subscription support, loyalty points) and product data. Using a "server-selects" architecture (Google for Developers merchant documentation), the agent proposes what it wants to do, and the merchant’s server chooses the best transaction path from their overlapping capabilities. UCP's transport-agnostic design, supporting traditional REST APIs, Agent-to-Agent (A2A), and Model Context Protocol (MCP) bindings, UCP offers the flexibility to power diverse of commerce activities and the interoperability to bridge the traditional web service integration and the new agent-native protocols (ucp.dev).

AP2’s central innovation is the Mandate: a cryptographically signed artifact capturing what the user authorized—often described as:

• Intent Mandate (rules of engagement: limits, timing, conditions)

• Cart Mandate (final approval of the specific purchase)

Google’s AP2 announcement describes this two-stage mandate flow and emphasizes constraints like price limits and timing as part of the signed authorization (Google Cloud AP2 Protocol). This is a concrete example of “authorization artifact as the cryptographic anchor” in a delegated action chain.

Mastercard’s Agent Pay messaging emphasizes making agent transactions recognizable and controllable across the value chain, with:

• registering and verifying AI agents, and

• enabling transactions using “agentic tokens” (dynamic, cryptographically secure credentials) (Mastercard).

Mastercard’s framework descriptions also highlight sharing intent-adjacent data elements—such as cart contents, transaction limits, and validity windows—to improve auditability and dispute handling (Mastercard).

Important nuance: “digital power of attorney” is a useful analogy, but the public pages primarily describe registration + tokenization + constraints metadata rather than fully specifying every binding semantic in public detail.

Where agentic commerce meets crypto infrastructure, a common design is “agent proposes, policy engine (or human) co-signs.” This is frequently implemented with MPC / threshold signatures:

• Coinbase describes threshold signatures as running an MPC protocol so that a threshold t of participants can sign without reconstructing the private key; and highlights Distributed Key Generation (DKG) where no one sees the private key in plaintext (Coinbase).

• Fireblocks documents co-signer architectures and operational models where an API co-signer can hold a key share, enabling automated approvals in some configurations and tighter controls (warm/cold) in others (Fireblocks Developer Portal).

This maps cleanly to agent governance:

• The agent can initiate actions (one share / proposal authority).

• A co-signer enforces policy thresholds and only participates in signing when criteria are met.

Agents don’t fit cleanly into static roles because they need conditional access tied to task and context (“resolve ticket,” “issue refund,” “book travel”), not blanket permissions.

NIST defines attribute-based access control (ABAC) as determining authorization by evaluating attributes of the subject, object, requested operations, and sometimes environment conditions against policy/rules (NIST Computer Security Resource Center)

NIST’s Policy Machine / NGAC work is positioned as a fundamental reworking of access control aligned with an ANSI/INCITS NGAC standard track (NIST)

Purpose-based access control (PBAC) is often used to describe access decisions conditioned on declared purpose of use (e.g., support resolution, audit). Academic work by Byun & Li is foundational here (Purdue Computer Science)

Capability-based authorization flips the default: you present a capability that already encodes what actions are allowed and under what caveats.

The W3C CCG ZCAP-LD spec describes an object capability model where capabilities can be delegated via chains and carry caveats (scope, lifetime, attenuation) (w3c-ccg.github.io)
This aligns naturally with mandate-based commerce flows: the portable artifact is the proof of authority.

In agentic systems, “semantic hijacking / intent hijacking” usually collapses to prompt injection + tool abuse, especially indirect prompt injection where malicious instructions ride along in external content (web pages, files, retrieved passages).

OWASP’s GenAI guidance describes indirect prompt injections as inputs from external sources that alter model behavior in unintended ways (OWASP Gen AI Security Project)

So the security job shifts: it’s not just “authenticate the agent,” it’s “ensure the agent’s tool calls remain inside the mandate.”

Traditional rate limiting counts requests. Agents need impact budgets:

• token spend,

• dollars spent,

• irreversible actions,

• or expensive external API consumption.

NIST’s API protection guidance explicitly treats risks like unrestricted resource consumption and recommends mitigations such as quotas, rate limiting, and policy controls across the API lifecycle (NIST Publications)

In agentic payments, the same pattern shows up as transaction limits and validity windows—constraints baked into the authorization context rather than bolted on later (Mastercard)

A “defensible” 2026 agent identity + commerce architecture typically combines:

1. Durable agent identity + registration
   Agent profile (DID or equivalent), operator/org binding, provenance and audit identifiers (openid.net).

2. Short-lived runtime credentials
   Narrowly scoped, frequently rotated execution tokens tied to runtime context (nccoe.nist.gov).

3. Intent/capability artifacts
   AP2 mandates (intent/cart) or capability tokens (ZCAP-LD style) that embed constraints and serve as portable proof of authority (Google Cloud).

4. Continuous evaluation + revocation propagation
   Zero trust posture plus cross-domain shared signals (CAEP) to attenuate access when risk changes (NIST Publications).

5. Schema’d tool interfaces (not UI scraping)
   MCP bindings for deterministic invocation of commerce actions (ucp.dev).

6. Impact budgets
   Quotas/limits for spend, actions, and resource consumption aligned to business impact (

Even with rapid standardization, a few gaps remain stubborn. For example:

• Interoperable “agent integrity state” attestation (model/tool/guardrail integrity) is much less mature than classic device/workload attestation, even though NIST is explicitly pushing the ecosystem to think beyond static credentials.

• Revocation in delegated, multi-hop ecosystems remains operationally difficult: you can propagate shared signals, but you still need strict constraints (short lifetimes, bounded execution, narrow scopes) to limit blast radius when revocation lags.

• Commerce trust/liability norms are still forming. UCP/AP2 define discovery and mandate primitives, but “who vouches for which agent, under what liability regime, with what privacy guarantees” is still being negotiated across merchants, issuers, networks, and identity providers.

“Quis custodiet ipsos custodes?” — Who will watch the watchmen? (Juvenal, Satires VI) (Wikipedia) The ancient question from Juvenal’s Satires has become a modern operational requirement. As autonomous systems transition from "chatting" to "acting," the primary security challenge is no longer just authentication; it is legibility. For an agent to be a safe participant in the 2026 economy, its actions must be defined by four distinct pillars:

• Attribution (Traceability): Every action must be cryptographically linked to a responsible principal via durable identity primitives like DIDs.

• Boundability (Scoped Authority): Authority is never open-ended; it is restricted by explicit mandates that define the "blast radius" of what an agent can and cannot do.

• Continuity (Temporal Context): Trust is not a one-time check but a continuous state that must be re-evaluated as the environment and security posture shift.

• Containability (Kill-switch Capability): Systems must have the "circuit breakers" necessary to halt a workflow instantly if an agent deviates from its intended path.

The standards and protocols emerging across identity, access control, and commerce are converging on a singular thesis: Trust is not a static login event; it is a runtime property. In this new paradigm, authority is expressed through short-lived credentials, constraint-heavy authorization artifacts, and shared signals that propagate risk across the network.

However, this shift toward "trust-as-a-service" leaves us with the fundamental questions that will define the next era of the agentic ecosystem:

• The Accountability Gap: Who is liable when an agent’s toolchain crosses multiple vendors, conflicting policies, and legal jurisdictions?

• The Persistence Problem: What does "revocation" look like when authority is delegated through portable mandates and capability chains that outlive the session that spawned them?

• The Integrity Paradox: How do we prove an agent’s internal integrity—not just its key custody—without turning compliance into total surveillance?

• The Impact Budget: When spending, compute, and irreversible actions become fully programmable, who sets the limits, who can override them, and who pays when they are exceeded?

As we delegate our agency to silicon, we must define its boundaries with precision and intention. Name them poorly, and you’ll spend the night chasing the wind you accidentally gave a wallet...