Decoupling Identity from Consent: A Practical Deep Dive into PACT and Agentic Delegation

The Delegation Trap: Why Scraped Sessions and Static API Keys Break Under Autonomous Agents

When we wire autonomous personal agents to external business systems, the architectural temptation is always convenience: give the agent a browser runner, dump an active session cookie or password into its vault, and let it click through the merchant's portal on the user's behalf. We have seen this pattern across early automation bots and computer-use demonstrations. In production, this approach collapses under basic security and operational realities.

Handing session cookies or raw user credentials to an autonomous execution harness violates every fraud prevention and identity assumption built over the past two decades. To the business's risk engine, an incoming connection from a headless Chromium instance hosted in an AWS or GCP data center looks indistinguishable from credential stuffing, session hijacking, or botnet abuse. Multi-factor authentication immediately breaks down: when a merchant demands an SMS one-time passcode or biometric WebAuthn prompt mid-checkout, the personal agent's execution loop either deadlocks or demands clunky out-of-band credential interception that trains users to bypass their own defensive instincts. Worse, the receiving service remains completely blind to caller provenance. If an agent executes an erroneous purchase or deletes a booking, the merchant's audit trail records only the human user's compromised session, destroying non-repudiation and leaving dispute systems incapable of determining whether an action originated from human intent, agent hallucination, or an injected instruction.

Moving to static personal access tokens or service account API keys fare no better. Static tokens offer an all-or-nothing blast radius; users cannot parse fine-grained API permissions, and configuring developer tokens is fundamentally unviable for consumer-grade assistance.

As I explored when breaking down why the deterministic harness is the real architecture of production AI agents, agentic execution across organizational boundaries cannot rely on ambient credentials or brittle client emulation. True delegation requires decoupling two orthogonal concerns: establishing the cryptographic identity of the calling platform, and securing explicit, user-authorized consent for bounded scopes. Without that split, every cross-agent interaction remains an accident waiting to happen.

Architectural Decoupling: How A2A Agent Cards and Asymmetric Keys Authenticate the Caller

To eliminate blind automation, the Personal Agent Consent & Trust Protocol (PACT)—co-developed by Decagon and Instinct—separates caller identity verification from end-user resource authorization. It establishes this foundation by building directly on top of the Agent2Agent (A2A) discovery standard.

Before executing conversational tool requests, a personal agent platform initiates discovery by retrieving the business system's A2A Agent Card. The Agent Card serves as a machine-readable manifest declaring supported conversational endpoints, transport capabilities, required cryptographic schemes, and exposed permission scopes (such as orders:read or orders:cancel). This discovery exchange establishes the operational contracts between the two agent runtimes before any sensitive payload is exchanged.

sequenceDiagram
    autonumber
    participant PA as Personal Agent Platform
    participant BA as Business Agent Endpoint
    participant User as End User

    Note over PA,BA: Step 1: Discovery & Caller Identity
    PA->>BA: Fetch A2A Agent Card
    BA-->>PA: Return Agent Card (Endpoints, Scopes, Auth Requirements)
    PA->>BA: Connect with Caller JWT (Signed by Personal Agent Private Key)
    BA->>BA: Validate Caller JWT against Personal Agent JWKS

    Note over PA,User: Step 2: Delegated Authorization (RFC 8628)
    PA->>BA: Initiate Authorization Request (Requested Scopes)
    BA-->>PA: Issue device_code, user_code, & verification_uri
    PA->>User: Display verification URL & user code
    User->>BA: Authenticate directly & approve scopes out-of-band

    Note over PA,BA: Step 3: Token Issuance & Scoped Tool Execution
    loop Poll Token Endpoint
        PA->>BA: Poll /token (device_code + caller JWT)
        BA-->>PA: Return Delegation Token (bound to User, Agent, & Scopes)
    end
    PA->>BA: Execute Scoped Tool Call (Bearer Delegation Token)
    BA-->>PA: Return Tool Execution Response

Once endpoints are resolved, the personal agent platform must authenticate itself. Rather than relying on static pre-shared secrets or standard API tokens, PACT mandates asymmetric cryptographic verification. The personal agent issues a short-lived JSON Web Token (JWT) signed by its private key. Upon receipt, the business provider resolves the caller platform's public key through a published JSON Web Key Set (JWKS) endpoint and verifies the signature, issuer, and token freshness.

This step establishes non-repudiable platform identity: the business endpoint now knows with cryptographic certainty that the caller is Instinct, Meta Muse, or another verified agent runtime, rather than an anonymous script.

However, this architecture enforces a strict security boundary: authenticating the caller's platform grants zero authority to manipulate customer data. Verifying that an inbound connection originates from a trusted agent runtime permits conversational negotiation to proceed, but touching protected account state requires a completely separate authorization grant derived directly from the end user.

Adapting RFC 8628: How Out-of-Band Device Authorization Behaves in LLM Conversational Loops

To bridge the gap between a verified agent runtime and protected user account state without intercepting user credentials, PACT adapts the OAuth 2.0 Device Authorization Grant (RFC 8628). Standard OAuth Authorization Code grants rely on browser redirects (302 Found), an approach that breaks down inside headless, terminal, or conversational agent runtimes that do not sit directly in the user's browser redirect path.

Under PACT's RFC 8628 adaptation, when an agent determines that fulfilling an intent requires protected account state—such as fetching an order or modifying a reservation—it requests authorization from the business provider for discrete scopes. The provider's authorization server responds with a device_code, a user-facing user_code, and a direct verification_uri. The personal agent presents this URL to the user in the conversational stream. The user steps out-of-band onto the merchant's native web or mobile login surface, authenticates directly using their existing credentials and multi-factor mechanisms, inspects the requested scopes, and approves or denies delegation.

Operating this handshake inside conversational agent execution loops exposes several distinct mechanical tensions:

[Personal Agent Loop] ---> Generates Verification URL ---> [User Clicks Out-of-Band]
         |                                                              |
    Polls /token                                                Encountering 2FA / SSO
         |                                                              |
  Hits 30s LLM Timeout  <--- [slow_down / authorization_pending] <--- [In Progress]

First, polling mechanics conflict with traditional LLM execution bounds. While the user is completing out-of-band authentication, the personal agent must periodically poll the merchant's /token endpoint using the device_code. In chat and voice interfaces, context execution windows are strictly bounded, often timing out after 30 to 60 seconds. If a user encounters multi-factor verification delays or corporate SSO friction on the merchant's domain, a naive synchronous execution loop will exhaust its timeout budget before the user finishes approving the request.

Second, the agent runtime must handle RFC 8628 error responses deterministically rather than treating them as unrecoverable conversational failures. When polling too aggressively, the authorization server returns slow_down responses, requiring the client to back off its polling interval. The runtime must differentiate between an authorization_pending status and terminal failures without burning context window cycles or spitting raw HTTP exceptions into the user chat stream.

Finally, teams must account for device code expiration. Standard device codes expire within 5 to 15 minutes. If user distraction or authentication friction causes the code to expire, the agent loses state, requiring the runtime to gracefully trigger a fresh grant rather than looping indefinitely or hallucinating completed authorization. Structuring the host runtime to suspend active LLM generation while polling out-of-band prevents burned tokens and keeps conversational state coherent.

Cryptographic Token Binding: Enforcing Scopes at the Gateway Instead of the Prompt

Once out-of-band consent completes, the business provider issues a cryptographically bound delegation token. In my view, the internal composition of this artifact is where PACT delivers its most critical architectural value. The token does not merely identify a user; it tightly binds three independent identities into an immutable JSON Web Token (JWT): the verified merchant customer ID (sub), the calling agent platform's verified public thumbprint (azp or client_id), and an explicit array of permitted scopes (scp), such as orders:read or orders:cancel.

stateDiagram-v2
    [*] --> Discovery: Fetch A2A Agent Card
    Discovery --> UnauthenticatedInteraction: Public Endpoints (Guest Query)
    UnauthenticatedInteraction --> ConsentInitiation: Protected Scope Demanded
    ConsentInitiation --> ScopedActiveExecution: RFC 8628 Consent Granted
    
    state ScopedActiveExecution {
        [*] --> InboundRequest
        InboundRequest --> GatewayValidation: Verify Caller JWT + Scope Claims
        GatewayValidation --> UpstreamExecution: Scope Authorized
        GatewayValidation --> Blocked: Scope Mismatch
    }

    ScopedActiveExecution --> TokenExpiration: TTL Elapsed
    ScopedActiveExecution --> StepUpAuthRequirement: High-Impact Mutation Demanded
    ScopedActiveExecution --> DistributedRevocation: User Revokes Delegation

    TokenExpiration --> ConsentInitiation: Re-authenticate
    StepUpAuthRequirement --> ConsentInitiation: Step-Up Consent Challenge
    DistributedRevocation --> [*]

The core architectural failure I repeatedly guard against in multi-agent topologies is prompt-level authorization. Relying on an upstream or business-facing LLM to read its system prompt, check whether the caller is "allowed" to cancel an order, and choose whether to call the tool is a fatal design defect. Models are probabilistic reasoning engines, not authorization enforcement points.

If you do not enforce scopes deterministically at the API gateway or reverse proxy boundary, you open the system directly to the classic confused deputy problem. Consider a scenario where an end user delegates orders:read to their personal assistant to track a delivery. If that assistant processes an untrusted third-party payload—such as an adversarial indirect prompt injection embedded within an order delivery note or merchant review—the model can be manipulated into issuing an unexpected cancelOrder tool call.

If authorization is handled via system prompt instructions, the model may rationalize the action or succumb to jailbreaks, dispatching the destructive mutation. With PACT's gateway-level token validation, the inbound HTTP request is intercepted by the reverse proxy before it ever hits the model runtime or application backend. The proxy validates the asymmetric signature, decodes the scp claim, detects that orders:cancel is absent from the issued token, and terminates the request with a deterministic 403 Forbidden. The downstream model never receives the payload, cutting off prompt injection at the transport perimeter.

Protocol Topography: Comparing PACT with MCP, Raw A2A, and Sierra's Personal Agent Protocol

Navigating the emergent standards landscape requires drawing strict architectural distinctions between agent-to-environment interfaces and true agent-to-agent delegation handshakes. Many engineers ask whether tools like Anthropic’s Model Context Protocol (MCP) make protocols like PACT redundant. They do not; they solve entirely different planes of the stack.

Integration Paradigm	Identity Verification	Consent UX Friction	Scope Granularity	Prompt Injection Resilience
Credential Scraping	Zero caller provenance; impersonates user session	Low initial setup; breaks intermittently on MFA	Coarse (all-or-nothing account access)	Vulnerable; compromised browser executes all user actions
Static API Keys	Identifies developer key owner, not dynamic agent	High developer burden; unviable for consumers	Static broad scopes; rarely granular	Poor; leaked or tricked keys execute full permissions
Remote MCP (OAuth Code Flow)	Client-to-server TLS/OAuth bearer tokens	Standard redirect browser flow; awkward in headless runtimes	Tool-level schemas; coarse authorization	Gateway-dependent; MCP servers rarely validate calling agent platform
Sierra & Meta's PAP	Platform-level agent identity and federation	Multi-stage: guest transition to authenticated OAuth	Dynamic transaction and commerce scopes	Strong gateway policy, but broad lifecycle scope
PACT (Decagon & Instinct)	Asymmetric JWKS platform verification per request	Out-of-band RFC 8628 Device Flow with direct merchant URI	Explicit, fine-grained operation claims (orders:read)	High; gateway rejects unauthorized tool mutations deterministically

MCP is fundamentally an Agent-to-Environment (A2E) protocol. It standardizes how a single host runtime discovers and calls local tools or remote context servers over structured JSON-RPC. MCP servers generally expect to be invoked within the trusted operational boundary of a single caller; they do not establish multi-party trust where an external agent negotiates on behalf of a third-party human.

By contrast, PACT builds on the Agent2Agent (A2A) discovery baseline to solve the Agent-to-Agent (A2A) authorization problem. Where raw A2A standardizes Agent Cards—describing who an agent is and what transport protocols it supports—it leaves delegated consent unresolved. PACT supplies the missing authorization machinery by introducing the RFC 8628 device grant.

This brings PACT into direct alignment with the broader Personal Agent Protocol (PAP) working group spearheaded by Sierra, Meta, Stripe, and Shopify. While PAP defines the end-to-end commerce lifecycle—spanning unauthenticated guest queries (such as product discovery) through to transactional checkout—PACT acts as a purpose-built consent and trust engine. As personal runtimes evolve, an architecture I analyzed when dissecting nanoMuse and cross-device agent runtimes, PACT provides the exact cryptographic primitive needed to hand off authority across untrusted organizational borders.

Production Edge Cases: JWKS Churn, Clock Drift, and Distributed Revocation Gaps

Moving PACT from specification to high-throughput production exposes three hard systems-engineering failure modes that protocol diagrams usually gloss over.

The first bottleneck is public key resolution and JWKS caching. When a personal agent connects to a business endpoint, the business must verify the caller's JWT against the platform's published JWKS. Doing this synchronously introduces a blocking outbound HTTP round-trip on cold starts. In low-latency streaming environments, that latency penalty is unacceptable, and it creates a direct denial-of-service vector against the personal agent’s key server.

However, aggressive local caching introduces an equally dangerous failure mode: key rotation failure. If a personal agent platform rotates its signing keys due to suspected compromise, a business service caching JWKS with static long TTLs will reject valid inbound tokens with 401 Unauthorized until the cache clears. I handle this by implementing a stale-while-revalidate caching strategy combined with opportunistic key pre-fetching triggered only when an unrecognised Key ID (kid) is encountered, wrapped in strict per-origin rate limiting.

The second operational hazard is clock skew across distributed systems. PACT relies on strict temporal claims (iat, nbf, and exp) across three decentralized operational nodes: the personal platform, the business gateway, and external identity providers. If clock drift between these independently managed Kubernetes clusters drifts by even two seconds, tokens will be rejected before their effective activation or fail validation mid-conversation. Production verifiers must enforce a deterministic clock-skew tolerance window (typically 30 to 60 seconds) on time-based claims rather than relying on standard runtime defaults.

Finally, stateless delegation tokens create a distributed revocation gap. If an end user visits their merchant account settings and clicks "Revoke Agent Access," an issued delegation JWT remains structurally valid at the API gateway until its expiration timestamp elapses. In high-stakes enterprise setups, waiting out a 15-minute token TTL after an account compromise is unacceptable.

Solving this without converting the gateway back into a high-latency synchronous bottleneck requires maintaining a distributed, low-latency token revocation registry—such as Redis-backed Bloom filters or real-time revocation lists synchronized via internal pub/sub. Every gateway node checks token identifiers (jti) against this local memory structure, ensuring that user revocation is respected instantly without sacrificing sub-millisecond edge enforcement.

Blueprint Architectures: Concrete Implementations for Engineering Teams Adopting PACT

For engineering teams operationalizing PACT across their infrastructure, moving from protocol diagrams to production requires addressing three mechanical bottlenecks: managing blocking conversational loops during out-of-band authorization, deterministically gating tool calls before model invocation, and closing the distributed revocation gap.

To resolve the friction of waiting on human credentials without stalling the runtime, teams building consumer-facing assistants should implement an Asynchronous Webhook Consent Bridge for Conversational Runtimes. Instead of burning compute and context window timeouts by running an HTTP polling loop inside an active model session, this pattern deploys a suspended-turn execution manager. An auxiliary polling worker handles RFC 8628 /token calls in the background, persisting the pending device_code and execution frame inside a Redis state store. The user's active conversational turn is immediately parked. Once the user completes out-of-band merchant authentication, an internal event triggers a Server-Sent Events (SSE) notification stream that rehydrates the agent's execution context, injecting the newly minted delegation token and resuming generation cleanly. The critical operational failure mode to monitor here is state drift: if a user takes several minutes navigating complex MFA challenges or password resets on the merchant site, the resumed conversation may carry an obsolete turn state or reference invalidated external resources if the harness fails to verify context freshness upon rehydration.

On the provider side, service desks and merchant endpoints must ensure that ambient agent permissions never leak into internal models. Teams should deploy a Deterministic Scope-Enforcing Gateway for Business Agent Tools. Implemented as an API reverse proxy interceptor using Envoy or OpenResty filters, this layer intercepts incoming PACT delegation tokens before tool payloads reach the reasoning pipeline. The proxy validates the token's asymmetric signature against its local JWKS cache, decodes the scp claim, and checks the requested action against an OpenAPI schema mapping table that explicitly pairs operational endpoints with required permissions. If an agent attempts to invoke a cancellation tool without orders:cancel, the gateway rejects the request with a deterministic 403 Forbidden at the perimeter. When engineering this boundary, watch out for semantic impedance mismatches: discrepancies between natural-language tool descriptions published in public A2A Agent Cards and the precise URL routes mapped at the gateway will trigger false-positive permission rejections, breaking otherwise valid conversational negotiations.

Finally, enterprise compliance teams handling sensitive transactional workflows need a Low-Latency Token Revocation and Audit Broker. This module bridges the stateless performance of JWTs with immediate revocation enforcement. By wiring an Identity Provider (IdP) webhook listener directly to a shared Redis Bloom filter, the broker captures user-initiated revocation events and indexes revoked token identifiers (jti) with sub-millisecond edge lookups. Simultaneously, the broker streams cryptographic proof records—pairing the agent platform thumbprint, verified subject ID, and execution payload—into an immutable audit logging pipeline. The primary architectural risk with this configuration is cross-region replication lag: in multi-region active-active deployments, replication delays across geographically distributed Redis instances can expose a transient execution window where a revoked agent token remains temporarily actionable before the filter synchronizes.

The Road Ahead for Agentic Interoperability: Governance, Federation, and Network Adoption

For PACT to transition from an emerging startup standard into the default authorization backbone for agentic commerce, the ecosystem must resolve deep structural tensions around governance, transport mechanics, and platform incentives.

The most pressing unresolved question is identity federation. PACT’s reliance on asymmetric JWKS platform verification solves cryptographic authenticity, but it completely sidesteps trust governance. A merchant gateway can verify that an inbound token was genuinely signed by a specific runtime, but it has no protocol-native mechanism to evaluate whether that runtime enforces prompt safety, isolates tenant memory, or respects data residency. Without a centralized trust registry or standardized credential federation, enterprise security teams will inevitably fall back on static, defensive allowlists. This dynamic threatens to concentrate agentic interoperability among a handful of well-capitalized platforms, shutting out self-hosted or niche personal assistants that lack pre-negotiated bilateral agreements with major merchant gateways.

At the transport layer, PACT must also mature beyond RFC 8628 polling. Polling an HTTP token endpoint was designed for low-concurrency consumer devices like smart TVs and CLI tools; running millions of concurrent polling loops across distributed microservices introduces needless network overhead, gateway contention, and edge latency. Production agent ecosystems need standardized, bidirectional event callbacks—pushing authorization confirmations directly to the caller via webhooks or persistent streaming channels. As I noted when analyzing MCP Events in ChatGPT and event-triggered agent runtimes, event-driven primitives naturally align with asynchronous agent execution, allowing runtimes to suspend and resume without spinning on external endpoints.

Finally, the protocol’s long-term trajectory hinges on enterprise platform adoption. Incumbent customer service giants like Salesforce and Zendesk benefit from proprietary platform moats, funneling ecosystem interactions through walled-garden partner directories and native workflow runtimes. However, as consumer agent adoption accelerates across operating systems and hardware runtimes, pressure from merchants demanding frictionless consumer handoffs will mount. If the Personal Agent Protocol working group successfully aligns merchant aggregators like Shopify and Stripe around these trust primitives, receiving business platforms will be forced to treat open delegation protocols as an operational requirement rather than an optional integration. PACT provides the necessary authorization blueprint; whether it becomes an industry standard depends entirely on the ecosystem's willingness to build open federation over proprietary lock-in.

Resources

• GitHub - openpactprotocol/openpactprotocol: PACT is an open protocol for personal agents to interact with businesses’ agents under explicit, verifiable user permissions. · GitHub