---
title: Programmatic access
description: Choose an identity and credential for command-line tools, services,
  agents, and automations.
editUrl: true
head: []
template: doc
sidebar:
  order: 1
  hidden: false
  attrs: {}
pagefind: true
draft: false
---

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

```mermaid
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](/en-us/programmatic-access/agents/) | Software that reads context, selects tools, or decides its next step dynamically. |
| [Automation](/en-us/programmatic-access/automations/) | 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.

:::tip[Interactive demo]
[Explore Agent and Automation identities](https://theater.sudomimus.com/workload-identity/). 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](/en-us/programmatic-access/access-keys/) | Quick to create and easy to integrate. The secret is shown once and must be stored safely. |
| [Public key](/en-us/programmatic-access/public-keys/) | 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](/en-us/with-portal/session-security/) regularly and confirm that the applications and actors are expected.