Entry is one decision, and what the operator may do inside is a second decision against the party's own roles.
Delegated Authority lets a signed-in operator work inside another party's context, which the Console calls Working as. A party is a participant other than the operator's own, an organisation or an account. Entering its context grants no role: the party's own roles decide what the operator may then do.
A delegated operation carries the operator's name in the platform trail. The ledger names the party's account as sender.
Organisation entry uses existing on-chain role grants. Account entry follows from a wallet the user already controls.
One person, many entities
Delegated Authority lets one named person operate for more than one legal entity without any of them sharing a login. An operations lead who administers three issuing entities works under their own account throughout, and every instruction they send for an entity stays attached to their name.
The usual alternative is a shared service account per entity, and it removes attribution. An auditor asking who moved a position gets an account name rather than a person, and one leaver means rotating a credential the whole desk knew. A regulator reviewing that movement needs a named individual on the platform side. The on-chain write still has to settle from the entity's own account.
Stepping into an entity's context changes what an operator can see and which account their instructions come from. It changes nothing about what that entity may do. The platform denies an instruction the entity's own roles forbid, whether or not an operator stands in its context. That separation lets an institution widen who may operate an entity without reopening what the entity may do.
Granting entry also grants authority. An operator who can enter the organisation's context sends instructions from the organisation's wallet, so they can do whatever that wallet's roles allow. Organisation identity manager, the role that lets an operator in and not the platform's Identity manager role, also lets them add or remove keys on the organisation's own on-chain identity and issue claims from it. Permission manager opens the same door and can also grant every other system role. Grant Organisation identity manager when the operator's job is entity administration and organisation-identity changes from them are acceptable. Reserve Permission manager for operators who need that broader scope too.
No separate delegation list exists to maintain. Entitlement comes from grants that already exist, chiefly a Permission manager or Organisation identity manager role the entity has already granted to the operator in its own system access manager on the ledger. Revoke that role and the ability to act for the entity goes with it once the platform has indexed the revoke.
One control marks, enters, and leaves a context
Delegated Authority appears in the Console as Working as. While you work in another party's context, a violet “Working as” bar opens every page with that party's name and Return to yourself, and the account menu button at the top right turns violet and reads “Working as” followed by the party's name. On the participants pages, the Working now badge uses the same violet. The Working as submenu leaves out a multisig wallet you sign for. That wallet opens as its own account under Shared accounts, with an Approvals tab, and its page offers Work as this participant.
The My participants guide walks the control end to end: opening it, reading a row's kind and role, choosing a party, and returning to yourself.
A party you cannot operate right now still appears, disabled, with the reason on its row: no smart wallet on the ledger network you have selected, or no wallet the organisation can drive. Creating a party provisions its wallet, so a row stalled partway through that setup shows the wallet missing, not a fault in the switcher. Finish that setup or wait for it to finish.
Switching clears work the browser was holding, including a pending deployment and an unfinished instrument draft, so switch before you start rather than during. The network you selected survives.
Switching to the same party again never unblocks an operation. When the platform declines one, changing context does not change the answer: look to the party's own role, or, for a multi-signature account, to its signer set and its threshold.
Two decisions, two accounts
The first decision asks whether this operator may work inside this party's context. The second asks whether the account that executes holds the role the operation requires. Widening the first never widens the second.
The first decision reads authority that already exists rather than a delegation table. For an organisation, the operator's own account must hold Organisation identity manager or Permission manager in that organisation's system access manager. Organisation identity manager is not the platform's Identity manager role, which manages the shared identity registry. The platform reads the role from its record of the organisation's system access manager on the ledger network the request names, so a grant or a revoke counts once the platform has indexed it. Entitlement is therefore per network:
Network A
The organisation runs a system here, and the operator's account holds an entitling role in it. Entry into the organisation's context is allowed on this network.
Network B
The same organisation, a different network. Either it runs no system here, or the operator holds no role in the one it runs. Entry is blocked on this network, and the role held on network A means nothing here.
A party that is an account rather than an organisation works differently. The platform admits the user's own person account when this organisation can drive its wallet, and any account that a wallet under the user's control signs for, such as a multisig in which that wallet holds a signer seat. No separate grant exists: removing the seat removes the entitlement. The platform rejects every other kind of party.
The second decision belongs to the account that executes. The platform resolves the party's own account and sends the instruction from it, so the role checks that decide the operation run against that account on the ledger. The operator's own credential still unlocks the submission. Before the instruction queues, the platform asks the operator for the second factor enrolled on their own account, a code or a personal identification number, and checks it against their enrolment rather than the party's.
Refusals are uniform. A context the operator may not enter, a party inside an organisation they do not belong to, and a party that does not exist all get the same response: a read runs in the operator's default context, their saved Working as choice or else their own, and a write is refused.
The context lives on one request header
Delegated Authority reaches the Platform API as one request header. Send the party's participant identifier in X-Participant and the request runs in that party's context. Omitting the header uses the session's current participant. Whichever participant the platform admits, by header or by session, every read and role check scoped to the caller's wallets uses that participant's wallets only: holdings, events, asset search, transaction status and the transaction list with ownership=caller. The routes on one multisig wallet (its details, signers, controllers, gas status, approvals and signer changes) also count the caller's own signing keys, because a signer seat belongs to the person. So do the multisig approvals in the actions list of a request that works as that multisig wallet. The list of multisig wallets does not. A request that acts as no one else reads the caller's own participant. A read that names a party the platform refuses runs in the caller's default context and returns X-Participant-Dropped. Send an explicit participant identifier when a request must use a specific authorised context. Concurrent requests can name different participants.
An explicit header selects the participant for one request, so concurrent requests can name different participants, and no header means the session participant.
Build the switcher from the assumable participants endpoint rather than from your own model of who may act for whom. The API explorer documents its request and response shape under the Participants tag. That endpoint returns exactly the set the entry check would allow on the selected network, and its identifier for each party is the value to send in the header. Each entry also lists the party's kind, the qualifying role for an organisation, and an availability flag whose reason tells you why the caller cannot use that party yet.
A read that names a party the caller may not enter runs in the caller's own context and carries the X-Participant-Dropped response header, so check that header before you treat the data as the party's. A read whose answer is the same for every participant, such as the public configuration, is served from the cache without the entry check and never carries the header. A write that names one returns DALP-0524 with the same header. Both answers are the same whether the party is one the caller may not enter or one that does not exist. That is deliberate: the response must not disclose which participants exist in this tenant or any other. It is therefore not evidence about existence, and retrying it changes nothing. Re-read the assumable list instead: revoking a role on the ledger drops a party from that list with no other signal.
The check runs before the platform queues any ledger operation, so a denied context leaves no partial submission to reconcile. A request that passes the check can still fail later, when the party's own roles are checked against its account on the ledger. The fix there is a role grant on the party's own account, not the operator's, since the operator already cleared the entry check.
Attribution needs both records
A delegated operation leaves two records, and attribution needs both. The platform's own trail names the person who acted, the participant they acted as, their platform and organisation role at that moment, the route they called and how it ended. Read role history for the on-chain role that let them in. The ledger names the party's account as the sender of the transaction and does not name the person. Sign-in events are recorded separately, and a sign-in can succeed without its audit entry, as the Audit Trail, the append-only log of platform activity, describes.
Entitlement is itself evidence. For an organisation, the operator's own role in that organisation's system access manager is the record of who could work for it. That role sits with the organisation's other grants and follows the same grant and revocation path. Answering who could act for an entity last quarter therefore means reading role history, not a delegation log.
Delegation stops at decisions that must name one individual. A support session is a session a platform administrator opens as a named user, and the platform records which administrator opened it. Inside one, the administrator can do what that user can do, except four things:
- Stand in as the second signature on a two-person sign-off, because then both signatures trace to one person.
- Turn on a published attestation the institution cannot later withdraw.
- Record a compliance rule that admits any contract. That decision needs a written rationale from anyone who makes it, and the platform refuses a support session even with the rationale, because the record has to name the person who decided.
- Accept the risk of a rule that excludes the holders of a claim they can remove themselves.
Each refusal names its reason rather than a generic permission error.
Frequently asked questions
Can I keep a different party's context open in a second browser tab?
No. The Console stores the active context once for the whole browser session, so every tab shares one context, and a switch in one tab reaches the others on their next navigation. Work that must run in two contexts at the same time belongs on the Platform API, where each request names its own context in its X-Participant header and two concurrent calls can differ.
Can I enter a multi-signature account's context?
Yes, when a wallet you control holds one of its signer seats. Its page under Shared accounts offers Work as this participant, and entering it never lowers its threshold: every operation it starts still waits for its signers' weight. You rarely need to enter it, though. The Working as submenu leaves multisig wallets out, and the wallet's Approvals tab lets each signer co-sign while acting as themselves.
Does acting for a party give me more permission than I have as myself?
It can. The instruction executes from the party's account, so you can do whatever that account's roles allow, including roles you do not hold yourself. Your entitlement lets you enter, and the party's roles authorise the operation.
What happens if my entitling role is revoked while I am working in a context?
Your next request no longer runs in that context. The entry check runs on every request rather than once when you switch, so the entitlement ends with the role as soon as the platform reads the revocation from the ledger. A read answers in your own context and carries the X-Participant-Dropped response header. The Console shows a toast and returns Working as to you. A write is refused with DALP-0524 and the same header. The Console holds it behind a dialog that offers to continue as yourself. Each refusal is recorded in the audit trail. The assumable list is cached in the browser for a few minutes, so it can keep showing the party briefly after the role is gone. The next request is the check that holds.
Does switching context let me approve my own work?
No. A two-person sign-off compares the people behind the two signatures, not the contexts they worked in, so a maker who re-enters as another party is still the same person, and the second signature does not count.
Can an integration using an API key act for a party?
Yes. Delegated Authority reads the session's user and participant identity, and an API-key session has both the same way a signed-in session does. A request authenticated with a key can therefore send X-Participant and run in a party's context, provided the key's underlying user holds the entitling role. The key decides who is calling. The context decides whose books the call works in.