Cryptographic Actors
What this screen is for
A cryptographic actor is the identity that calls the platform on behalf of an application: an internal service, a batch job, an integration channel or a third party. Authorization decisions, audit events and rate limits are anchored on the actor. This screen lists your tenant's actors and is where you give each one a way to authenticate and the operations it may request.
What must exist first
This screen is for tenants that compose authorization by hand. It is not offered to SIMPLE tenants: a SIMPLE tenant uses Internal Use Cases, which compose the actor, its credential and its grants for it.
Before you work here:
- An application. Every actor belongs to one, and creating an application already creates its Default Cryptographic Actor.
- The permission to list actors, which is what shows this screen. Creating and deleting actors, reading, issuing, rotating and revoking credentials, reading and changing roles, and reading or binding federated identities are each a further permission. A tab you are not permitted to read is disabled.
Decisions you make here
Creating an actor
With the permission to create actors, New Actor opens a wizard. You choose the Application the actor belongs to, its type (Internal, Third-Party or Partner), its name, display name, description and purpose, and an optional validity window.
The actor is saved as soon as that first step is complete. The wizard then offers its first credential and its roles, and you may skip either. An actor cannot operate until it has a way to authenticate, which is a credential or a bound external identity, and at least one role. Its detail says so, and offers the missing steps, until both exist.
The same first-credential step is offered by the Cryptographic Exchange wizard, both for an actor you create inside it and for one you select there, so an actor reached that way does not need a separate visit to this screen to become able to authenticate. Nothing issues a credential on its own: a credential exists only where someone asked for one, here or there.
Opening an actor
Selecting an actor opens its detail in a panel beside the list, with the tabs Info, Credentials, Roles, Federated identities and Activity, in that order. A tab you are not permitted to read is disabled.
Info shows the actor's record: its identifier, application, type, status, whether it is the Default Actor, its display name, description and purpose, its validity window, when it was created (Created At) and when it was last changed (Updated).
Issuing and rotating credentials
On the actor's Credentials tab, Issue Credential offers two modes:
- Add, with the permission to issue credentials: a new credential beside the active ones, which keep working.
- Rotate, with the permission to rotate credentials: a new credential, while the active ones move to
ROTATING_OUT, keep authenticating for the Grace window (hours) you set, and carry a revoke timestamp at which a scheduled job revokes them. The default is 24 hours and the maximum 720.
So a rotation does not invalidate the previous credential immediately unless you ask it to: by default it schedules the revocation a day out. A grace window of 0 is the only immediate case, and then the previous credentials are revoked in the same transaction and every workload still presenting one stops authenticating at once.
When you add a credential you choose its kind, and a rotation keeps the kind it replaces:
- Shared secret: the platform generates the secret, shows it once and keeps only a hash of it. Store it before you close the dialog; if it is lost, rotate to obtain a new one.
- Registered key pair: the workload keeps its private key and signs an assertion with it. You paste only the public key as a JWK, so no secret exists for anyone to leak.
A credential can also carry a validity window. Left blank, it is valid from now with no expiry.
A disabled actor can never authenticate again, so issuing or rotating a credential for it, or binding a federated identity to it, is refused and nothing is written. Revoking its credentials and removing its bindings stay available.
Revoking a credential
With the permission to revoke credentials, revoking a credential is permanent. A process authenticating with it is denied on its next request.
Assigning roles
With the permission to read roles, the Roles tab shows the API permissions the actor holds and where each one comes from: assigned here by hand, or conferred by one of its active capability grants. With the permission to assign or unassign roles, Manage lets you tick roles, and Save replaces the hand-assigned set with exactly what is ticked. A grant-conferred name cannot be saved as a hand-assigned one: submitting it is refused and the refusal names it. An actor that an internal use case owns acts only for that use case, so Save is refused for it and the refusal names the use case.
An actor needs an API permission for the kind of operation and a capability grant for the key. A grant supplies both for the operations it names, for exactly as long as it is active, and nothing is written when it does — so withdrawing the grant withdraws the permission with it, with no clean-up step. Neither takes effect the instant you click: a token already issued lives up to 900 seconds, and the grant cache up to 300 seconds beyond that.
Binding a federated identity
On the Federated identities tab, Bind an external identity lets a subject vouched for by a trusted issuer authenticate as this actor, with no secret held here. It needs the permission to write workload identities, a tenant entitled to workload identity federation, and the issuer declared in your tenant's Settings. The tab says which of these is missing.
A binding conveys identity only: roles and grants still decide what the actor may do. Removing a binding is permanent.
Deleting an actor
With the permission to delete actors, Delete Actor removes an actor once you type its name. It is refused while active credentials, capability grants or cryptographic exchanges still reference the actor, so revoke those first. A Default Actor cannot be deleted on its own; it is disabled when its application is deleted.
Reviewing activity
The Activity tab shows the operations the actor ran and the changes made to it, under All, Administration and Usage. Credential issuance and rotation are recorded under each credential and are not listed there, and the tab says so. Reading operations and reading changes are separate audit permissions: when one is refused or fails, the tab says which and still shows the other.
Each kind states how many of its entries are loaded out of how many it holds, and Load more reads the next ones until the tab says that kind's history is complete. On All, the merged list goes back only as far as both kinds are loaded, and the tab states that date. A next page that fails is stated with Retry and keeps what is loaded; a refused one says so. View in Audit Log opens the Audit Log narrowed to this actor over the last 365 days.
How it relates to other screens
Every actor belongs to an application, and the application column of the list opens it:
This screen holds the one detail of an actor. A grant's actor on the capability grants screen, and an actor listed under Used by in a constraint policy, open it here:
Which keys an actor's operations may use is decided by capability grants, and exchange contexts scope those grants to a business relationship. A STANDARD tenant composes both on their own screens. Because audit events are anchored on the actor, the audit trail attributes every operation to the actor that performed it.