Abstract

AI agents now act with real credentials: OAuth tokens held by connectors, API keys in coding pipelines, the signed-in sessions of phone assistants, cloud service accounts, passkeys and hardware-protected signing keys. A valid credential proves that the caller can authenticate. It does not prove that the specific action it is about to perform is the one the user approved. One prompt-injected web page, poisoned memory entry or malicious tool result is enough to make a fully authenticated agent send data to the wrong recipient, write to the wrong tenant or sign the wrong transaction.

Hiding the secret is not enough either. An agent that cannot read a non-exportable key can still ask the custodian to sign anything. Privacy also fails quietly: many small, individually permitted releases, summaries or embeddings can together reveal what no single release would. And credentials that rotate or are re-scoped while work is pending can silently widen or extend authority.

This disclosure describes an architecture in which the agent never holds the key and never decides alone what a credential is used for:

  • Non-effective by default. Every credential-dependent or data-releasing operation starts as a non-effective Candidate Act.
  • Broker check. A protected credential broker or signing custodian reconstructs the actual outgoing request: method, final destination after redirects, tenant, recipient, payload digest and resource version. It inserts the secret or produces a signature only if the request matches a current source grant, the current credential generation and protected single-use state.
  • Destination check. An independent destination-side Finality Sink then verifies the actual resource mutation.
  • Cumulative disclosure ledger. A recipient-scoped ledger with provenance lineage atomically reserves exposure for each release. It treats summaries, transformations and embeddings as disclosures of their sources, and refuses releases of unknown provenance.
  • Rotation fencing. Credential rotation is a protected generation change that fences stale acts and never inherits broader scope.
  • Memory provenance. Agent memory and retrieval carry ingest provenance and re-check authority at use time, so retrieved text is treated as data, not permission.
  • Separate records. Credential use, request acceptance, resource commit and data disclosure are kept as distinct, journalled propositions, with crash-safe, non-replayable consumption.

The disclosure includes:

  • key points for examiners, with search terms;
  • architecture and decision-gate drawings for each source unit;
  • reference schemas and pseudocode;
  • twelve implementation variations: iOS and Android brokers, MCP token vaults, KMS/HSM signing policy, passkey transaction binding, password autofill, enterprise DLP, CI/CD secrets, RAG gates, open-banking consent, the EU Digital Identity Wallet and messaging gateways;
  • a fourteen-threat model and thirty-two proposed validation tests;
  • IETF and EU AI Act mappings.

Industry relevance (AI-generated): the patterns apply to publicly described product lines, including:

  • Apple iOS, Keychain, Secure Enclave, App Intents and Siri;
  • Google Android Keystore, StrongBox and Gemini;
  • Samsung Bixby;
  • Microsoft Windows, Azure and Copilot;
  • Amazon Alexa and AWS identity and key services;
  • OpenAI agents and Codex;
  • Anthropic Claude and the Model Context Protocol;
  • Meta Muse/Sentinel;
  • NVIDIA BlueField and OpenShell;
  • Qualcomm Snapdragon secure execution;
  • Huawei mobile and telecom platforms;
  • Arm TrustZone;
  • passkeys and WebAuthn, and password managers;
  • open banking, including India’s Account Aggregator framework;
  • the EU Digital Identity Wallet.

Names identify integration environments only. No vulnerability, deficiency, implementation or infringement is alleged, and no endorsement is implied. This material is AI-generated and must be cross-checked against the original PCT filings and primary sources before drawing any conclusion.

This technical disclosure is based on the Mothership application PCT/IB2026/055615, filed 4 June 2026 and publicly disclosed 16 July 2026 (WO 2026/150382). That application claims priority from PCT/IB2026/053385, filed 7 April 2026 and publicly disclosed 4 June 2026 (WO 2026/115520). The source text is drawn from global pages 1–14, 787–859, 1898–2018 and 2567–2825 of that filing, as published in the 3,567-page specification on Zenodo (https://zenodo.org/records/23657985). It is expanded here from Internet-Draft draft-das-agent-credential-privacy-00, dated 26 October 2026 (Part 9 of a 12-part series). Diagrams, schemas, implementation variations, threat classifications and proposed tests are newly authored explanations; they are not claimed as filed content or experimental results. Related family applications can be cross-checked on WIPO PATENTSCOPE. Licensed under CC BY-NC 4.0. The author is open to acquihire or strategic collaboration.

Keywords

AI agent credential security; operation-bound credential use; credential broker; secret-use gate; OAuth token misuse; MCP connector security; API key exfiltration; non-exportable key misuse; HSM signing policy; passkeys; WebAuthn; DPoP; token exchange; credential rotation; generation fencing; cumulative privacy leakage; per-recipient disclosure budget; derived-information leakage; data provenance; agent memory poisoning; RAG security; vector database; iOS Keychain; Secure Enclave; Android Keystore; StrongBox; prompt injection; data loss prevention; EU AI Act; GDPR; execution finality; Finality Sink.

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Download

Share

COinS