An identity for Claude that a bank issues, a customer binds, and a federation can check.
The Federated Agent Connector gives Claude a hardware-bound identity from the customer's own bank, a mandate the customer approves with a passkey, and standing in the bank's OpenID Federation. A partner that has never met the agent can decide - from the federation alone - who it acts for, what it is for, and why it is asking.
Declares its mission: balances, transactions and partner offers - and says it is for account management and personalised benefits.
Vouches in its own words - It cannot move money
- and caps what the agent may claim, whatever the agent wrote.
Limits every agent below the bank to the purposes this trust framework recognises.
The one set of keys every member pins out of band. Nothing else is taken on trust.
Four moments, and the customer is in each one that matters
-
Enrol
The customer signs in to their bank with a passkey. The connector makes its keys in hardware, and the sign-in commits to them. The bank attests the connector's key and makes it a member of the bank's federation.
-
Give a mandate
Claude asks for a mandate, and every entry says what, where and why. Before the customer sees a consent screen, the bank's policy service checks it against the agent's mission and the partner's rules.
-
Act
Every token is bound to the connector's hardware key and names the customer as the subject and the agent as the actor. A partner's enforcement point, configured by the federation, asks the policy services before it answers.
-
Withdraw
The bank withdraws its Trust Mark or revokes the agent. Partners refuse on the next call, and the bank's own authorisation server refuses the agent's next request.
Trust that travels with the agent, and limits that travel with it too
Hardware-bound, customer-bound
The agent's keys live in the Mac's Secure Enclave or on a YubiKey. The customer's passkey sign-in commits to those exact keys, so the bank knows which device, and which person, it is dealing with.
Delegation, never impersonation
Every token names the customer as the subject and the agent as the actor. The bank, the partner and the audit trail can all see who acted, for whom.
Mission and purpose as federation data
The bank vouches for what the agent is for and caps what it may claim. Each mandate states its purpose in DPV terms, and partners say which purposes they will serve.
Policy the federation configures
A partner's enforcement point learns its policy services, the Trust Marks it must require and the purposes it may accept by resolving itself through the federation. There is no static configuration to drift.
A policy service that checks for itself
The policy service resolves the agent's chain, mission and Trust Mark with its own pinned keys. It refuses an enforcement point whose configuration no longer matches the federation's.
Revocation that reaches everywhere
Withdraw the Trust Mark and partners refuse. Revoke the agent and its chain stops resolving - and the bank's authorisation server stops authenticating it too.
A token says who acts for whom. This says what the agent is for.
Three questions, answered by three different parties, all carried through the federation. A request goes ahead only when the action sits inside all three and the stated purpose sits inside the agent's purposes and the partner's.
| Question | Who answers | Where it lives |
|---|---|---|
| Mission | The bank that onboarded the agent | The agent's Entity Configuration, capped by the bank's statement about it |
| Purpose | The customer, approving a mandate | Each authorisation detail in the grant, as a DPV purpose |
| Acceptance | The partner's superior in the federation | The partner's own metadata, capped by the anchor's policy |
A partner's decision, as its enforcement point receives it
permit- The agent's chain runs agent → bank → anchor
- The enforcement point forwarded what the federation resolves
- The token's client is the software the federation names
- The agent holds the Trust Mark the partner requires, and it is active
- The partner offers the action
- The action is in the agent's mission
- The customer granted the action
- The grant's purpose is within the agent's purposes
- The grant's purpose is one the partner accepts
Three keys in hardware, never cross-used
The Secure Enclave keeps the agent working behind a locked screen while still asking for Touch ID when it authenticates. On a YubiKey, the authentication key wants a touch every time.
| Key | Signs | Secure Enclave | YubiKey |
|---|---|---|---|
| federation | The agent's own Entity Configuration | No prompt; usable after first unlock | PIV slot 82, PIN once |
| instance | Every client-authentication proof; the bank's attestation names it | Touch ID, only while unlocked | PIV slot 83, PIN once, touch every time |
| DPoP | Proofs binding every token to the device | No prompt; usable after first unlock | PIV slot 84, PIN once |
Built from open standards, end to end
- OpenID Federation 1.0OpenID
- Attestation-based client authenticationIETF draft
- FAPI 2.0OpenID
- Pushed authorisation requestsRFC 9126
- Rich authorisation requestsRFC 9396
- DPoPRFC 9449
- Token exchange and actRFC 8693
- Resource indicatorsRFC 8707
- Protected resource metadataRFC 9728
- AuthZENOpenID
- Data Privacy VocabularyW3C CG · 2.3
- WebAuthn and passkeysW3C
A reference implementation, proven end to end
It runs against a local bank - PingFederate 13.1 with the pf-agentic-identity modules, a go-oidfed Trust Anchor, and a partner that trusts nothing but the anchor's keys. An automated suite drives the connector exactly as Claude does.
- provenEnrolment, mandates, partner calls, mission and purpose checks, and revocation - with software keys and with Secure Enclave keys.
- in progressYubiKey PIV: the helper and the bank's attestation check are built and tested; the hardware run is next.
- in progressPasskeys at PingOne, in place of the local identity provider that stands in for it today.
- known limitApple does not offer App Attest to macOS apps, so the bank records Secure Enclave keys as self-asserted. A YubiKey's attestation is the option the bank can verify.
The code is open
The connector and its key helpers, the policy service, the partner, the PingFederate configuration as code, and an end-to-end suite you can run against your own local bank. Apache-2.0.
Or try the live demo first - the same connector, run against PingFederate, a Trust Anchor, a partner and a policy decision point, with you as the customer.