Programmatic access

Programmatic access is for software that runs without a browser or should not depend on a person signing in each time. In the With portal, you manage two separate choices:

• Who is acting: your account, an agent, or an automation.
• How it signs in: an access key or a public key whose private half stays with you.

Neither choice grants permission inside an application. The application still decides which sign-in methods it accepts and what the signed-in actor may do.

Decide whether you need a programmatic credential

flowchart TD
    Start[Software needs to sign in] --> Browser{Can a user approve the sign-in<br/>in a browser at runtime?}
    Browser -->|Yes| Device[Prefer Device Authorization]
    Browser -->|No| Actor{Does it need its own identity<br/>and independent lifecycle?}
    Actor -->|No| Account[Use the account as the principal]
    Actor -->|Yes| Behavior{How does it work?}
    Behavior -->|Chooses its next step from context| Agent[Create an agent]
    Behavior -->|Runs a defined flow on a schedule or event| Automation[Create an automation]
    Account --> Credential{Choose a credential}
    Agent --> Credential
    Automation --> Credential
    Credential -->|Simpler setup| AccessKey[Access key]
    Credential -->|Keep the private key local| PublicKey[Public-key sign-in]

Device Authorization is usually a better fit for a CLI or desktop tool launched by a person. It avoids keeping a long-lived programmatic credential. Unattended services, agents, and automations are better candidates for an access key or public key.

Agent or automation

Choose	When it fits
Agent	Software that reads context, selects tools, or decides its next step dynamically.
Automation	A defined workflow triggered by a schedule, webhook, or other known event.

Both belong to your account and use the same credential types. Keeping them separate makes ownership and lifecycle easier to understand: suspending a deployment automation does not affect your personal account or an unrelated agent.

Interactive demo

Explore Agent and Automation identities. Pause one actor and observe the effect on the owner account and other actors. This local simulation does not perform real sign-ins or change your account.

Access key or public key

Choose	What to expect
Access key	Quick to create and easy to integrate. The secret is shown once and must be stored safely.
Public key	The private key stays with you. Best when your environment already manages keys and signing.

Choose between an access key and public-key sign-in based on what the application supports, how you store credentials, and whether your software can sign requests.

Routine checks

• Use names that identify the job and where it runs, such as “Release assistant” or “Nightly backup.”
• Give each service its own credential instead of sharing one across environments.
• Revoke credentials you no longer use. Suspend the agent or automation when the shutdown is temporary.
• Review Session security regularly and confirm that the applications and actors are expected.