Extending UCP to Support PII

A Tokenized Approach to Sensitive Data in Agentic Commerce and Services

The Universal Commerce Protocol (UCP) introduced a durable pattern for agentic commerce: an AI agent can orchestrate a structured checkout flow while payment credentials remain outside the model context, represented only by opaque, tokenized instruments issued by a trusted payment handler. UCP also reduces "N×N" bespoke integrations through standardized capability discovery and negotiation.

This paper proposes extending that same pattern to Personally Identifiable Information (PII) including names, addresses, dates of birth, income and employment details, and other sensitive user data required to complete real-world workflows. The objective is simple: enable agents to complete high-friction tasks that require PII without ever exposing raw PII to the model layer.

This matters most for eCommerce and services platforms (for example, point-of-sale, invoicing, booking, commerce, and embedded-finance platforms). Many of the highest-value workflows with end-to-end processes that involve transaction of sensitive data, including HIPAA or other PII data, are not possible today without a secure way to handle this data. Without a standardized tokenized mechanism, platforms face an unacceptable choice: pass raw PII through an LLM context (risk and compliance exposure) or keep the user in repetitive manual loops (abandonment and lost revenue).

Our proposal is conservative and UCP-native: PII stays in a separate trust boundary (a PII vault or credential provider), the agent receives only token references (PII instruments), and service platforms resolve those tokens server-side under strict scope checks. UCP's capability negotiation ensures the extension is additive and non-breaking.

We demonstrate the extension via a reference implementation for agent-driven loan application flow. Currently, the process for applying for and comparing rates from multiple loan providers is a repetitive process. While loan aggregators exist, they often prioritize the underwriters that provide the best economic incentives for the aggregating platform rather than the end customer. Given that most personal loans underwrite using substantially the same set information, we see this as a great opportunity for agentic disruption. TransUnion reports $276B in unsecured personal loan balances in Q4 2025, held across 26.4M consumers, with average debt per borrower of $11,699. Even a 10 bp improvement in interest rate applied across $276B outstanding implies roughly $276M/year in interest cost savings (back-of-the-envelope) for the consumer.

Extending UCP to Support PII

What is the problem we are trying to solve

If we want agents to handle the menial parts of our lives, we need to empower them to take actions on our behalf. Sometimes, this includes dealing with sensitive information that we don't want the model to use outside the exact context we prescribe.

1) The agentic "last mile" breaks on sensitive data

Agents are increasingly capable at planning and orchestrating multi-step action such as search, compare, fill forms, submit requests. However, agents often stall at the point where real workflows require sensitive inputs: identity verification (DOB, address history), underwriting (income, employment), regulated onboarding (KYC/AML), healthcare intake, and other services workflows.

2) The risk is architectural, not just operational

If raw PII is present in the model context, it can leak through prompt injection, accidental logging (traces, retries, analytics), conversation retention, or misrouted tool calls. Policies and redaction help, but the safer architecture is to ensure the agent never receives raw PII in the first place.

3) Existing approaches don't scale across the ecosystem

Without a common protocol, the ecosystem drifts into bespoke "PII vault APIs" per platform and provider, repeated user form entry, inconsistent consent semantics, and uneven security posture and auditability. UCP was created to reduce the "N×N integration bottleneck" through standardized negotiation and primitives; PII is the next bottleneck to solve in the same way.

Proposed Solution

We propose extending the data model used to handle payment information within UCP to handle additional types of sensitive information. UCP already has a proven architecture for payment credentials: the agent orchestrates, the user authorizes, a handler issues tokens, and the business backend completes the transaction. We extend this model for PII by introducing parallel primitives that mirror the payment pattern.

Design principles

  • Zero raw PII in the model layer. Agents only see opaque tokens and minimal routing metadata.
  • User-controlled, explicit consent at field-level and recipient-level (who gets what, for what purpose).
  • Capability negotiation and schema composition: if unsupported, nothing changes; if supported, the schema composes via extensions.
  • Auditable and enforceable policy: token issuance and resolution are scoped, time-bounded, and logged.

Proposed primitives

  • PIIHandler (analogous to PaymentHandler): a trusted credential provider that collects/stores PII and mints tokens.
  • PIIInstrument (analogous to PaymentInstrument): an object carrying an opaque token credential plus scope metadata (fields, recipient).
  • PIIConsent: a formal consent record created by the UI layer and submitted to the vault for token minting and audit.

UCP-native transport semantics

UCP's A2A binding specifies that payment credentials are submitted as a structured DataPart under the attribute name a2a.ucp.checkout.payment_data. We extend this symmetry with a2a.ucp.checkout.pii_data, carrying one or more PIIInstrument objects (tokens only). Vertical-specific non-PII payloads (for example, loan amount or term preferences) are carried separately (for example, a2a.ucp.checkout.loan_application). This makes the extension easy to implement for teams already familiar with UCP checkout flows.

Profile and capability integration (non-breaking)

UCP uses a server-selects architecture and negotiates capabilities from the intersection of platform and business profiles published at /.well-known/ucp. We introduce a vertical capability extension (for example, com.viaschema.lending) that extends dev.ucp.shopping.checkout. This aligns with UCP's reverse-domain governance model and extension mechanism.

Benefits for platforms (e.g., Square) that adopt this extension

Adoption decisions are cross-functional. Successful adoption requires a story for Product, Engineering, Security, Legal, and the GM.

  • Business upside (GM + Product): enables agents to complete high-friction steps (intake, verification, financing), not just discovery; reduces form repetition and abandonment; unlocks monetization (embedded financing, onboarding services).
  • Risk reduction (Security + Legal): raw PII stays out of LLM context; token scope and audit logs provide enforceable controls and forensic clarity.
  • Low integration cost (Engineering): additive via capability negotiation; reuses UCP patterns (handlers, instruments, DataParts).
  • Distribution alignment: UCP is positioned as an open standard for agentic commerce across major agent surfaces.
  • Product fit: many services platforms already offer financing and onboarding workflows, which benefit directly from tokenized PII exchange.

Sample Implementation

Shopping for a loan

Loan comparison is a representative "PII-first" workflow: it involves multiple recipients (many lenders), repeated form entry today, sensitive underwriting inputs, and strict consent and audit requirements.

End-to-end flow (5 phases)

Phase 1 — Discovery: The agent searches lenders by loan type; no PII is involved.

Phase 2 — Checkout initialization: The agent starts the lending flow. The checkout is extended with PII handlers, eligible lenders, required PII fields, and status.

Phase 3 — PII collection + consent (UI ↔ vault, not LLM): The UI collects missing fields and captures explicit consent for fields and recipients; the vault mints platform-scoped tokens.

Phase 4 — Token-based submission: The agent submits only PII tokens (PII instruments) plus non-PII application fields to request offers.

Phase 5 — Comparison: Lenders return offers; the UI sorts and presents offers, with next-step URLs for completion.

Why this proves platform readiness

  • Agents can orchestrate a full workflow requiring PII without raw PII exposure.
  • Consent is explicit, field-scoped, and recipient-scoped, enabling enforceable policy.
  • Multi-recipient tokenization works (one token per platform_id), enabling safe comparisons across many providers.

Technical Considerations

Security

Security objective: ensure raw PII does not enter the model context and cannot be extracted by the agent, even under adversarial prompting.

Threat model and mitigations (representative)

  • Prompt injection / exfiltration: agent only receives opaque tokens; raw PII is never in-context.
  • Token replay: time-to-live (TTL) plus recommended one-time-use tokens or nonce binding for high-risk flows.
  • Token theft (client or transit): recipient/audience scoping plus authenticated token resolution (mTLS/OAuth) and short TTL.
  • Confused deputy / wrong recipient resolution: vault enforces platform_id match; tokens minted per platform.
  • Over-collection: field-level consent and standardized minimum field sets by use case.

Recommended production controls (beyond the mock)

  • Resolve tokens only from authenticated services (no browser resolution).
  • Emit audit logs for token issuance and every resolution event.
  • Support key rotation and configurable TTL/usage policies.
  • Implement data residency controls for regulated markets.

Privacy

Privacy objective: users control what is shared, with whom, and for what purpose; sharing is reversible and traceable.

  • Explicit consent objects with purpose, field list, recipients, and timestamp.
  • Purpose limitation: tokens should bind to a declared purpose (e.g., "loan comparison").
  • Data minimization: share only required fields, not everything stored.
  • Revocation and retention: users can revoke active consents and request deletion in production deployments.

Extensibility

UCP's extensibility model is built around reverse-domain names and extension schemas. This extension scales across verticals via composable field sets (lending, insurance, healthcare, onboarding), multiple PII handlers per business, and non-breaking evolution using optional fields and new extension capabilities consistent with UCP's compatibility approach.

Further possible investments

  • Production PII vault: SOC 2 controls, encryption and key rotation, configurable TTL and one-time tokens, and robust audit pipelines.
  • Consent management UX: dashboards for disclosures, revocation, export and deletion workflows.
  • Selective disclosure and attestations: share facts (e.g., "over 18") without sharing raw attributes.
  • Standardized field sets per vertical to reduce ambiguity and over-collection.
  • Conformance suite and interoperability testing (capability negotiation, token scope, A2A DataPart compliance).
  • Governance path: iterate under com.viaschema.* and propose an upstream dev.ucp.* extension once semantics stabilize.

Appendix A — Reference Implementation Highlights (selected excerpts)

The excerpts below illustrate the concrete mechanics behind the proposal. They are provided for implementer clarity and to demonstrate that the extension follows UCP's established patterns (handlers, instruments, negotiated schema composition).

A1) New A2A keys for PII and lending (constants)

# a2a/business_agent/src/business_agent/constants.py
UCP_LENDING_EXTENSION = "com.viaschema.lending"

UCP_CHECKOUT_KEY = "a2a.ucp.checkout"
UCP_PAYMENT_DATA_KEY = "a2a.ucp.checkout.payment_data"
UCP_RISK_SIGNALS_KEY = "a2a.ucp.checkout.risk_signals"

# Lending / PII data keys
ADK_PII_STATE = "__pii_data__"
UCP_PII_DATA_KEY = "a2a.ucp.checkout.pii_data"
UCP_PII_COLLECTION_KEY = "a2a.ucp.checkout.pii_collection"
UCP_LOAN_APPLICATION_KEY = "a2a.ucp.checkout.loan_application"

A2) Merchant profile declares capability extension and PII handlers

// a2a/business_agent/src/business_agent/data/ucp.json
{
  "ucp": {
    "capabilities": {
      "dev.ucp.shopping": [
        {
          "name": "com.viaschema.lending",
          "version": "2026-01-11",
          "spec": "https://viaschema.com/specs/lending",
          "schema": "https://viaschema.com/schemas/lending/lending.json",
          "extends": "dev.ucp.shopping.checkout"
        }
      ]
    }
  },
  "pii": {
    "handlers": [{
      "id": "example_pii_provider",
      "name": "example.pii.provider",
      "version": "2026-01-11",
      "spec": "https://pii.provider.example/specs/handlers/pii",
      "config_schema": "https://pii.provider.example/specs/handlers/config.json",
      "supported_loan_types": ["personal", "car"],
      "config": { "platform_id": "superstore_lending" }
    }]
  }
}

A3) Capability negotiation composes a lending checkout type (non-breaking)

# a2a/business_agent/src/business_agent/helpers/type_generator.py
if UCP_LENDING_EXTENSION in active_capability_names:
    selected_base_models.append(LendingCheckout)

A4) Formal consent and token instruments

# a2a/business_agent/src/business_agent/models/lending_types.py
class PIIConsent(BaseModel):
    pii_method_id: str
    handler_id: str
    fields_consented: list[str]
    loan_type: str
    platform_ids: list[str]
    consented_at: str

class PIIInstrument(BaseModel):
    id: str
    handler_id: str
    handler_name: str
    credential: PIICredential  # token only
    fields_stored: list[str] = []
    loan_type: str = "all"
    platform_id: str | None = None

A5) Vault issues platform-scoped, field-scoped tokens with TTL

# a2a/business_agent/src/business_agent/pii_provider.py
TOKEN_TTL_SECONDS = 3600  # 1 hour

def issue_token(self, user_email, platform_id="_default", fields=None) -> str:
    token = f"pii_token_{uuid.uuid4()}"
    allowed = frozenset(fields) if fields else frozenset(self.get_stored_fields(user_email))
    self._tokens[token] = TokenEntry(user_email, platform_id, time.time(), allowed)
    return token

def resolve_token(self, token: str, platform_id: str) -> dict | None:
    entry = self._tokens.get(token)
    if entry is None:
        return None
    if entry.platform_id != platform_id:
        return None
    if time.time() - entry.created_at > TOKEN_TTL_SECONDS:
        return None
    all_pii = self._stored_pii.get(entry.email)
    return {k: v for k, v in all_pii.items() if k in entry.allowed_fields}

A6) The A2A executor ingests PII tokens as structured DataParts

# a2a/business_agent/src/business_agent/agent_executor.py
pii_keys = [UCP_PII_DATA_KEY, UCP_PII_COLLECTION_KEY, UCP_LOAN_APPLICATION_KEY]

for key in pii_keys:
    if key in data_part:
        value = data_part.pop(key)
        if key == UCP_PII_DATA_KEY:
            pii_payload[key] = PIIInstrument.model_validate(value)
        else:
            pii_payload[key] = value

A7) Frontend builds consent and requests tokens from the vault

// a2a/chat-client/App.tsx
const consent: PIIConsent = {
  pii_method_id: selectedMethodId,
  handler_id: "example_pii_provider",
  fields_consented: lending?.required_pii_fields || [],
  loan_type: lending?.loan_type || "personal",
  platform_ids: lenders.map((l) => l.platform_id),
  consented_at: new Date().toISOString(),
};

const { instruments } = await piiProvider.current.submitConsent(user_email, consent);