Give a scheduled job its own identity

A nightly backup, release pipeline, or scheduled synchronization should not sign in as the person who configured it. Sudomimus gives a fixed workflow an Automation identity owned by an account. The automation has its own name, credentials, and sign-in history. You can suspend or revoke it without changing your personal sign-in.

See Agents and automation for the product overview.

Use an Agent instead when software reads context and chooses its own tools or next steps. Neither identity grants business permissions inside your application. Your application still decides what the job may do after it signs in.

1. Create one identity per job and environment

In the With portal, open Programmatic access → Automations and select Create. Use a name such as “Production nightly backup.” Record the trigger, runtime location, and responsible team in its description. Create a separate automation for staging or another pipeline.

The automation belongs to your account; it is not a second user account. Its credentials and sessions can be managed independently.

2. Choose and scope a credential

For the quickest setup, create an AccessKey for that automation and the target application. Store the secret immediately; the portal shows it only during creation or exact retry. Use a secret manager or protected runtime environment, never a repository or job definition.

If the runtime already has reliable Ed25519 key storage and signing support, register a public key instead. Only the public key is sent to Sudomimus. Scope a public key to the intended application or sector; its coverage cannot be edited later.

Keep production and staging credentials separate. Credential coverage limits where the job can authenticate. It does not grant rights to data or operations inside those applications.

3. Admit the automation in the target application

The application must explicitly allow the automation’s exact credential type in Layer 1. An Account AccessKey rule does not also admit an Automation AccessKey.

Also configure a Layer 2 realize rule that admits the owning account and a Layer 3 DIRECT_ISSUE return rule. Activate the application. These allowlists default to deny; the credential alone is insufficient.

4. Exchange the credential for a session

For an AccessKey, the job calls the Native direct-issue endpoint from a protected server runtime. The example uses environment variables so the secret does not appear in source code:

1
const response = await fetch(
2
    "https://native-api.sudomimus.com/direct-issue/access-key",
3
    {
4
        method: "POST",
5
        headers: { "Content-Type": "application/json" },
6
        body: JSON.stringify({
7
            applicationAnchor: process.env.SUDOMIMUS_APPLICATION_ANCHOR,
8
            accessKeyIdentifier: process.env.SUDOMIMUS_ACCESS_KEY_ID,
9
            accessKeySecret: process.env.SUDOMIMUS_ACCESS_KEY_SECRET,
10
        }),
11
    },
12
);
13

14
if (!response.ok) {
15
    throw new Error(`Automation sign-in failed (${response.status})`);
16
}
17

18
const { accessToken, refreshToken } = await response.json();

Validate the returned tokens and protect the refresh token according to the Native and Session guides. Do not print credentials or tokens in job logs. If a required claim or consent is missing, Native can return a browser Errand instead of tokens; the job must report that human action is required, not silently retry forever.

An Automation access token identifies the owner through its sector-scoped sub and carries a separate actor subject in act.sub. The application must validate the token type and decide the job’s business permissions itself.

5. Rotate and retire the job

Create a replacement credential, update the runtime, and verify a successful sign-in before revoking the old credential. Suspend the automation during an investigation. Before resuming, check whether its scheduler will replay old work. Revoke the automation when it is permanently retired; that action cannot be undone.

For the portal workflow and lifecycle controls, see Manage automations. For a job that has a human operator present at each login, compare device authorization before issuing a long-lived secret.