Before
An agent that paid suppliers held a service account with standing payment authority. Nobody could say who owned it, what it was allowed to spend, or how to stop it without breaking the payment run.
Illustrative reference model
An agent without a governed identity is an ungoverned actor.
CBA will run thousands of agents across CommBank, Bankwest, ASB, CommSec and x15, built by internal teams, by software vendors and by customers, on authorization servers inherited from a decade of acquisitions. Today each one becomes a client record configured by hand, and nobody can say from one place who owns it, what it is allowed to do, or how to turn it off.
Beat one
The identity is the control point
An agent is not governed by the code path it happens to call. It is governed by an identity somebody approved, owns and can withdraw.
Beat two
Resolvable, rather than configured
Identity, capability envelope, certification status and lifecycle state are published once and resolved by every consumer at runtime. Approval publishes. Suspension withdraws. No consumer holds a stale copy it has to be told to purge.
Beat three
The trust layer is already in production
CBA is a ConnectID member and already consumes this stack in Australia today. The agentic layer is new. The trust layer underneath it is not.
Agent identity
Active
{
"sub": "https://agent-ap-orchestrator.demo.cba.raidiam.io",
"name": "Accounts Payable Orchestrator",
"owner": "Commonwealth Bank of Australia",
"manufacturer": "CBA Agent Provider",
"capability_role": "cba.agentic.ap.orchestrator",
"may_request": ["supplier_payment", "supplier_invoice", "accounts_read", "accounts_write", "payment_initiation"],
"lifecycle": "active"
}
What every platform makes of it, on its next resolve
NetBank Identity Platform
admits
CommBiz Identity Platform
admits
Institutional Banking and Markets Identity Platform
admits
Bankwest Identity Platform
admits
ASB FastNet Identity Platform
admits
CommSec Identity Platform
admits
CBA Workforce Identity Platform
admits
Modelled from the estate. The live resolve is in the universe view.
The problemTC-01 · TC-02 · TC-06
One estate, many places to configure an agent by hand
The estate below is modelled, and the shape of it is the point. A bank of this size does not have one authorization server to add an agent to. It has several, inherited for reasons that were good at the time, and each one is a separate place for an agent record to be created, forgotten and left running.
7authorization servers, each with its own way of authenticating
18distinct authentication methods across them
7customer brands across 5 legal entities
6divisions that own identities
6capability roles, which are the envelope an agent may ask inside
2of the modelled agents are built outside CBA entirely
After
The customer approves one envelope: supplier payments, 50,000 AUD, thirty days, with a single payment limit. The orchestrator delegates a narrower envelope to one sub agent per invoice, so a sub agent can settle its own invoice and nothing else. The invoice above the single payment limit is not refused and is not quietly paid; it goes to a second human over CIBA. That same invoice would also take the run past the envelope balance, so two guardrails fire on one item and the customer has to extend the envelope as well as approve. Delegation only ever narrows, and the whole chain stops the moment the authority withdraws the agent identity.
The estateillustrative reference model
Every platform here stands in for one you already run
None of these authorization servers is a Raidiam product and none is offered as one. Each is a reference implementation deployed so the federation has something real to resolve. In the Formal Proof of Concept they are your Ping and Entra estate, and ID Partners owns that integration.
Reference implementation
NetBank Identity Platform
Stands in for the retail enterprise authorization server.
The shared enterprise platform. It authenticates the largest customer population, so the venture brands were told to reuse it rather than build their own.
CommBank app approval · NetCode one time code · password plus device binding
Reference implementation
CommBiz Identity Platform
Stands in for the business banking authorization server.
A segment specific platform inherited from the business banking stack. Business customers authorise payments on a hardware token and expect dual authorisation, so it was never folded into retail. It is also where the accounts payable agents authenticate, which is why it carries the token exchange and client attestation grants.
hardware token · CommBiz mobile approval · dual authorisation for payments
Reference implementation
Institutional Banking and Markets Identity Platform
Stands in for the institutional authorization server.
A segment specific platform from the institutional stack. Its users are corporates and market counterparties authenticated on certificates, on a release cycle nobody wanted to couple to retail.
client certificate · named user token · entitlement review on renewal
Reference implementation
Bankwest Identity Platform
Stands in for the Bankwest brand authorization server.
A brand platform kept intact so the brand kept its own customer experience. Migrating it was always the next programme and never this year’s.
Bankwest app approval · SMS one time code
Reference implementation
ASB FastNet Identity Platform
Stands in for the ASB authorization server.
A separately run subsidiary platform in another jurisdiction. Local regulation, local operations and a local vendor relationship mean it is governed by the group but is not operated by it.
FastNet NetCode · ASB app approval
Reference implementation
CommSec Identity Platform
Stands in for the broking authorization server.
A trading platform with its own session, step up and market data entitlement rules. Its identity model was built around trading accounts rather than banking customers.
trading password plus one time code · adviser delegated access
Reference implementation
CBA Workforce Identity Platform
Stands in for Microsoft Entra ID.
The workforce platform. Staff and internal automation authenticate here, not on any customer platform, and internal agents inherit their owning team from it.
workforce single sign on · phishing resistant passkey · privileged access approval
One anchor, and a role namespace that says which question a grant answers
The model names CBA Group Authority, CBA Australia Authority, ASB New Zealand Authority, CBA Agentic Authority, and every entity in the estate resolves to the anchor. What a consumer can observe is the role namespace carried in the trust mark type. cba.accredited. says the bank has assessed a party and will let it act for a customer at all. cba.agentic. says what it may then ask for. The approved envelope still decides what it actually gets. Three different questions, and the namespace is the part that is visible on the wire.
The estate models four authorities because that is the intended operating model, and the separation of accreditation from capability is a real architectural distinction. This deployment has one authority, so two trust marks issued under it cannot be told apart by their issuer, because their issuer is the same. What IS observable is the role namespace, which appears in the trust mark type: cba.accredited.* means the bank has assessed a party and will let it act at all, cba.agentic.* means what it may then ask for. Read the authority assignment below as the target operating model, not as something a consumer can verify today.
Cross recognition, not subordination
ConnectID. Consumer identity, cross recognised as a peer federation. CBA is a genuine member, which is why the trust layer in this demo is production technology rather than a mock.
A peer federation has its own trust anchor. CBA is a member of this one, which is why the trust layer under this demonstration is production technology rather than a mock.
The control planeTC-02 · TC-04 · TC-05 · TC-27
Approval publishes. Suspension withdraws.
Raidiam Connect is the Trust Controller. There is no separate governance layer built on top of it, because the thing that holds the identity, the keys, the roles and the lifecycle state is the thing that should publish and withdraw them.
Approve
The software statement goes live with its authority claims active. The entity resolves through the federation, its trust marks retrieve without a credential, and its capability role becomes metadata policy every consumer applies.
Suspend
Claims are set inactive and the marks stop issuing. The next resolve fails closed. Nothing has to be told to forget anything, because nothing was holding a copy.
Withdraw
The entity no longer resolves at all. The decision history behind all three is the platform change log, which is versioned already and is not a report somebody assembles afterwards.
Three propagation pathstimed on screen in scene 06
How fast a suspension actually reaches a running system
The acceptance criteria ask for timing and for tolerance of stale metadata, so the demonstration races three paths against a stopwatch rather than asserting a number. The slowest path is the one that bounds the exposure, so it is the one worth measuring.
Resolution fails closed
The authority claim goes inactive, the trust mark is withdrawn, and the next resolve at any consumer refuses.
A security event is pushed
Subscribed resource servers are told, over the shared signals framework, without polling for it.
A status list flips
A resource server that subscribes to nothing still refuses the token on next presentation.
The capability envelopeTC-27, built
What an agent may ask for is governed apart from what it is given
A capability role is federation metadata policy, not an OAuth scope and not runtime client configuration. Roles union across an identity, they are versioned by the platform, and changing one changes what every consumer will admit without the agent identity being touched.
cba.agentic.ap.orchestrator
Holds the supplier payment umbrella a business customer approved, and delegates narrower authority to one sub agent per invoice. It is ELIGIBLE for accounts_write and still cannot obtain it, because that type sits outside the delegated envelope. Eligibility and envelope are two different gates, and this role is where that is visible.
may move money
cba.agentic.invoice.settler
Settles exactly one invoice, inside the amount and the window the orchestrator delegated. It can initiate the payment for that invoice and can never widen what it was given.
may move money
cba.agentic.servicing.assistant
Answers retail customer servicing questions from account information. It cannot move money, which is what the read only guardrail proves on screen.
read only
cba.agentic.workforce.assistant
An internal operations agent that reconciles invoices against settled payments for a staff owner.
read only
cba.agentic.partner.assistant
An agent built by an external software vendor, entitled to read a business customer’s invoices and nothing else.
read only
cba.agentic.settlement.bureau
An accredited external payments bureau that settles individual supplier invoices for a business customer. The single payment limit and the cumulative envelope bind it exactly as they bind an agent the bank built itself.
may move money
The crossingruns live in the agentic lab
Why a federation beats an integration, on one screen
This is the most CBA shaped problem in the estate. A staff owned agent lives on the workforce platform. The invoices it has to read live behind business banking. The two platforms have no integration with each other, and nobody wants to build one.
Before
Internal automation ran under a shared staff account with a password in a vault, inheriting whatever that person could reach. Reaching a system on another platform meant a second credential on that platform, issued by a different team, and a point to point integration between the two that somebody had to own.
After
The agent authenticates once on the workforce platform, which stands in for the enterprise directory, and exchanges that token at business banking for one scoped to the invoice register. Business banking holds no record of this agent and shares no secret with the workforce platform: it resolves the workforce platform through the federation at the moment of the request and issues on that basis. Adding another platform adds no integration. The exchanged token is narrower than the one presented, so crossing a boundary attenuates authority rather than widening it, and it can never initiate a payment.
Authenticates at
CBA Workforce Identity Platform
held: accounts_read, supplier_invoice
Exchanges at
CommBiz Identity Platform
issued: supplier_invoice
No record, no shared secret
Business banking holds no client record for this agent and shares nothing with the workforce platform. It resolves that platform through the federation at the moment of the request.
Crossing narrows, never widens
The exchanged token carries less than the one presented. Delegation attenuates across a platform boundary exactly as it does inside one, and this agent can never initiate a payment.
Adding a platform adds no integration
The eighth platform costs what the seventh cost, which is nothing, because the trust decision is a resolution rather than a configuration held between a pair.
This flow is in the estate model and runs live. It is not one of the eleven numbered scenes, because no objective in the tracker points at it yet.
The demonstration11 scenes · about 71 minutes
Eleven scenes, each answering a numbered objective
Every scene runs live against the deployed stack and is recorded so it can be watched without a presenter. Where a recording does not exist yet, the scene says so.
Scene 01
Scene 02
Scene 03
Scene 04
Scene 05
Scene 06
Scene 07
Scene 08
Scene 09
Scene 10
Scene 11
A manifest becomes an identity
An agent identity manifest is committed and merged. The pipeline drives the Trust Controller to create the software statement, assign its capability roles and activate its authority claims. A second manifest is rejected on policy and nothing is created.
Walking the control plane
The agent identity record in the Trust Controller: its lifecycle state, its capability roles, its keys and its change history. The live entity configuration is fetched before an edit and again after it.
A trust check before access
The accounts payable agent resolves what the Payments API requires, obtains a sender constrained token and is admitted. A second agent without the capability role is refused, and the refusal states which check failed.
An agent presents where it has no record
An agent built by an external software vendor authenticates at a platform that has never seen it. The platform resolves it through the federation, builds a local client representation from the resolved metadata and issues a token.
Five refusals, five different reasons
No eligibility, an envelope widened, a read only agent attempting a payment, a cumulative budget exceeded, and a payment to the wrong counterparty. Each refusal renders the rule it broke.
Suspension, timed on three paths
The agent is suspended in the Trust Controller. Three propagation paths race with a stopwatch on screen: the authority claim goes inactive and the next resolve fails closed, a security event is pushed to subscribed resource servers, and the token status list flips so a non subscribing service still refuses on next presentation.
One correlation id, end to end
A single correlation id followed from the committed manifest, through the Trust Controller change record, into token issuance and out to the resource server decision log, filtered live.
Arbitrary evidence against an identity
Owner, environment, version, repository link, image digest and a software bill of materials reference recorded against a software statement, then read back through the API.
A signing key the platform never holds
A public key is uploaded whose private half stays in the enterprise key store. The Trust Controller derives the key identifier from the key itself, the entity stamps the same identifier on its signed configuration, and both sides agree without either being told the other value.
Changing what an agent may ask for
A capability role is changed. A downstream consumer sees the new envelope on its next resolve, with the agent identity untouched and no scope changed anywhere. The change history is shown alongside.
Binding a running instance
The agent provider attests an instance. The instance authenticates with a client attestation grant and is bound to the approved agent identity. A second instance without an attestation is refused.
Beyond the asknot one of the 28
The mandate an agent carries with it
Nothing in this section was asked for. It is here because the question that follows a governed agent identity is what happens when the agent has to prove its authority to somebody who is not on your federation, and the answer already exists in the stack you are being shown.
A grant, or a credential
Every scenario in the demonstration runs one of two ways. Either the customer approves the envelope in the moment, on the platform they already authenticate at, or the agent holds that approval as a verifiable credential it carries and presents. The governance is the same either way, and the second is what works when the counterparty is not yours.
Only the claims the counterparty needs
A mandate presented selectively discloses the amount, the window and the counterparty constraint, and nothing about the customer beyond them. The supplier learns that the payment is authorised. It does not learn who the customer banks with or what else they approved.
The same withdrawal path
A credential is not a licence that outlives the identity behind it. Suspending the agent revokes the mandate through the same status mechanism the tokens use, which is why the revocation scene times three paths rather than two.
What sits behind it
Credential issuance, selective disclosure, status lists, security event publication and post quantum key profiles are all capability of the platform you are evaluating. They are shown here because they are real, and they are separately licensable. Commercial questions route to ID Partners.
Run it yourselfdeployed services
Nothing here is a slide of something that runs elsewhere
16 deployed services, and the scenes execute against them. Open any of them. Treatment is marked on every row, because what a component is matters more than what it does, and seven of these are not ours.
The control plane
Where an agent identity is approved, published and withdrawn, and the two views over it.
Raidiam Connect
Raidiam product
Raidiam product
The Trust Controller itself. Agent identities, capability roles, keys and lifecycle state.
web.directory.cba.raidiam.io
Universe view
Raidiam product
Raidiam product
The whole estate as one federation, with live trust chain resolution on any node.
universe.demo.cba.raidiam.io
Ops console
Raidiam product
Raidiam product
The operations view over the estate: authorization servers, protected APIs and flow runs.
ops.demo.cba.raidiam.ioReference authorization servers
Seven platforms, none of them a Raidiam product. In the Formal Proof of Concept these are your Ping and Entra estate.
NetBank Identity Platform
Reference implementation
Reference implementation
Stands in for the retail enterprise authorization server. CommBank app approval, NetCode one time code, password plus device binding.
netbank.demo.cba.raidiam.io
CommBiz Identity Platform
Reference implementation
Reference implementation
Stands in for the business banking authorization server. hardware token, CommBiz mobile approval, dual authorisation for payments.
commbiz.demo.cba.raidiam.io
Institutional Banking and Markets Identity Platform
Reference implementation
Reference implementation
Stands in for the institutional authorization server. client certificate, named user token, entitlement review on renewal.
ibm.demo.cba.raidiam.io
Bankwest Identity Platform
Reference implementation
Reference implementation
Stands in for the Bankwest brand authorization server. Bankwest app approval, SMS one time code.
bankwest.demo.cba.raidiam.io
ASB FastNet Identity Platform
Reference implementation
Reference implementation
Stands in for the ASB authorization server. FastNet NetCode, ASB app approval.
asb.demo.cba.raidiam.io
CommSec Identity Platform
Reference implementation
Reference implementation
Stands in for the broking authorization server. trading password plus one time code, adviser delegated access.
commsec.demo.cba.raidiam.io
CBA Workforce Identity Platform
Reference implementation
Reference implementation
Stands in for Microsoft Entra ID. workforce single sign on, phishing resistant passkey, privileged access approval.
workforce.demo.cba.raidiam.ioProtected APIs and the lab that calls them
The surfaces an agent has to get past, and the scenarios that try.
Agentic lab
CBA side illustration
CBA side illustration
The accounts payable scenarios: envelopes, sub agents, step up and refusals, run live.
agents.demo.cba.raidiam.io
Payments API
CBA side illustration
CBA side illustration
A protected payment surface that re derives trust before it honours a token.
rs-payments.demo.cba.raidiam.io
Accounts API
CBA side illustration
CBA side illustration
A protected account information surface, read only by construction.
rs-accounts.demo.cba.raidiam.io
Supplier and invoice API
CBA side illustration
CBA side illustration
The invoice register the accounts payable agents read from.
rs-supplier.demo.cba.raidiam.ioManufacturer and signals
Where an instance is attested, and where a suspension arrives without being asked for.
Certificates were still being issued across the estate when this page was written, so a link may not answer yet. Hostnames are final and never change: they are baked into directory records and trust chains.
CoverageTC-01 to TC-28
The tracker, exactly as it stands
18 of 28 objectives carry a linked artefact today and 10 do not. That page is generated from the tracker rather than written, so it goes backwards as readily as forwards. An honest tracker is worth more to you than a flattering one, and it is the only kind you can check.
7not started
3building
3built
15evidenced